Re: import.meta and TC39 process as a whole

[Matthew Phillips]

whatwg/loader was too big of a spec. It was floated around in various forms
for at least 5 years. Despite the very hard work of its champions it didn't
garner enough implementer support. I think history has proven now that
incremental improvements are more likely to succeed, so I'm happy to see
import() and import.meta be able to go through the process at a relatively
swift pace.

On Thu, Aug 3, 2017 at 4:43 PM, Caridy Patiño  wrote:

> Dmitrii, as stated by the champion of import.meta in the issue, issues/2
> is one step of the process, in which we ask other members of the committee
> to review the spec text before it can be presented for stage 3. But you
> should be able to open other issues in that repo to voice your concerns
> about that proposal. Additionally, we have other channels, like this one,
> or via other members who can voice your concerns in upcoming meetings.
>
> As for the particular feature that you’re referencing, I suggest you to
> look at previous discussions about `import`, and why it is different (a
> hint: it is different because like super, it needs some contextual
> information). As one of the champions of the whatwg loader, I can tell you
> that we spent many hours trying to figure the best course of actions based
> on the initial loader spec, and we believe `import` is the right thing to
> do. import.meta is just a progression of that decision.
>
> /caridy
>
> On Aug 3, 2017, at 4:10 PM, Dmitrii Dimandt  wrote:
>
> Can anyone enlighten me as to how any input on features that are rushed
> into the standard works?
>
> What is the purpose of hosting TC39 on GitHub if no input is expected from
> anybody but TC39 members?
>
> Prime example: https://github.com/tc39/proposal-import-meta/issues/2
>
> Somehow it’s already in stage 2. Which means: The committee expects to
> devote time to examining the problem space, solutions and cross-cutting
> concerns
>
> Only reviews from committee members are expected, all other comments are
> locked out. If this makes it to stage 3 (and it will), it means: The
> committee expects the feature to be developed and eventually included in
> the standard
>
> So what’s the point of the whole process? Just shove whatever features you
> want/need onto the language and be done with it.
>
> Regarding import.meta. Instead of properly speccing out and designing a
> Loader (https://whatwg.github.io/loader/), the import keyword was turned
> into a not-really-a-keyword-not-really-a-function abomination. It quickly
> reached stage 3. Any and all concerns by people who discovered this and
> voiced their concerns were dismissed with no argument, and dynamic import
> is now everywhere.
>
> Now, since there has been no proper design of the feature, a `meta
> property` is just tacked onto the already confusing mess that is `import`.
> Expect it to reach stage 3 within a week or so, and then we are stuck with
> it forever.
>
> So, the question: why does TC39 even bother with the pretence of being
> transparent, o doing proper design on the language features etc.?
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
Bitovi
Development | Design | Training | Open Source
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: An update on Object.observe

[Matthew Phillips]

> Over three years ago, Rafael Weinstein, Erik Arvidsson, and I set out to
> design and implement what we believed to be the primitive underlying the
> data-binding system of MDV ("model-driven views"). We prototyped an
> implementation in a branch of V8, then got agreement from the V8 team to
> build a real version upstream, while pushing Object.observe ("O.o") as a
> part of the upcoming ES7 standard and working with the Polymer team to
> build their data-binding system on top of O.o.
>
> Three years later, the world has changed in a variety of ways. While other
> data-binding frameworks (such as Ember and Angular) showed interest, it was
> difficult to see how they could evolve their existing model to match that
> of O.o. Polymer rewrote from the ground up for its 1.0 release, and in that
> rebuilding did not utilize O.o. And React's processing model, which tries
> to avoid the mutable state inherent in data-binding systems, has become
> quite popular on the web.
>
> After much discussion with the parties involved, I plan to withdraw the
> Object.observe proposal from TC39 (where it currently sits at stage 2 in
> the ES spec process), and hope to remove support from V8 by the end of the
> year (the feature is used on 0.0169% of Chrome pageviews, according to
> chromestatus.com).
>
> For developers who have been experimenting with O.o and are seeking a
> transition path, consider using a polyfill such as
> https://github.com/MaxArt2501/object-observe or a wrapper library like
> https://github.com/polymer/observe-js.
>
> - Adam
>

What is Polymer using in place of Object.observe?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Alternative to Promise

[Matthew Phillips]

On Thu, Oct 01, 2015 at 01:57:01PM +0800, Yad Smood wrote:
> To be frankly, I can't read your doc in just 5min, it's a little obscure to
> me. Please don't stick on performance or internal complexity, it's not the
> bottleneck. 

Performance could be a bottle neck in some situations. I'm particularly
worried about what the performance implications will be on the Loader
spec with it's heavy use of promises. With that spec there will be a
minimum of (I think?) 5 Promises created for every module, and perhaps
many more if custom loaders are used. When you do the math that's going
to wind up being a lot of Promises, which always have to go on a task
queue, to a load non-trivial sized applications and the performance
might be much worse than a non-async continuation passing API.

I'd like to see this data before I conclude Promises solve all of our
continuation needs.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: The WAIT for export and import

[Matthew Phillips]

How can user agents implement import/export without the loader spec?

On Fri, May 1, 2015 at 8:07 AM, Florent FAYOLLE florent.fayoll...@gmail.com
 wrote:

 Not sure that's the right place to talk about that (es-discuss is about
 the specification itself). Probably you should rather CC yourself on this
 bug:
 https://bugzilla.mozilla.org/show_bug.cgi?id=es6

 And especially on this one:
 https://bugzilla.mozilla.org/show_bug.cgi?id=568953

 BTW, someone looks interested in working on this ;). See:
 https://bugzilla.mozilla.org/show_bug.cgi?id=568953#c127

 Florent


 Le 01/05/2015 02:35, L2L 2L a écrit :

 When is the estimated time of implantation on import and  vice versa.

 I know this make no sense to talk on, but I can't wait for the feature so
 I can use it in Firefox scratchpad!

 Require is nice, but it's not native!

 L4L
 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss


 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss




-- 
Bitovi
Development | Design | Training | Open Source
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Are ES6 modules in browsers going to get loaded level-by-level?

[Matthew Phillips]

I think the issue of round-trips is a red-herring. I spent some effort
trying to optimize an es6 loader with caching in indexeddb and even that
did not help much.  I think what caridy said earlier is likely the biggest
issue, processing a large number of Promises.

On Thu, Apr 23, 2015 at 7:55 PM, John Barton johnjbar...@google.com wrote:

 Sorry, but what I read was not an explanation but rather a hope that
 HTTP/2 would magically solve this problem.  I'm all for HTTP/2 solving
 this. But so far I've not heard or read anything to back up the idea.

 Will HTTP/2 make multiple round trips, one for each level of the
 dependency tree, competitive with pre-bundling? If not, then we will have
 to send dependency info to the client or cache info to the server or
 bundle. Or there is some magic as yet unexplained?

 jjb

 On Thu, Apr 23, 2015 at 7:47 AM, Domenic Denicola d...@domenic.me wrote:

  Indeed, there is no built-in facility for bundling since as explained
 in this thread that will actually slow down your performance, and there’s
 no desire to include an antipattern in the language.



 *From:* es-discuss [mailto:es-discuss-boun...@mozilla.org] *On Behalf Of
 *Eric B
 *Sent:* Thursday, April 23, 2015 10:25
 *To:* Frankie Bagnardi; Matthew Phillips
 *Cc:* es-discuss
 *Subject:* Re: Re: Are ES6 modules in browsers going to get loaded
 level-by-level?



 So just to clarify, when browsers support es6 modules we will still need
 some extra library to bundle the modules?  This would mean es6 modules are
 only a syntactical addition and not something functional?



 On Thu, Apr 23, 2015 at 10:18 AM Frankie Bagnardi f.bagna...@gmail.com
 wrote:

  Matthew, there are already tools for es6 modules + bundling (e.g. babel
 + webpack), or converting es6 modules to AMD (e.g. babel
 https://babeljs.io/docs/usage/modules/).







 On Wed, Apr 22, 2015 at 7:10 PM, Matthew Phillips matt...@bitovi.com
 wrote:


  Can you clarify what you mean about bundling? Unless I've missed
 something, the ES6 module system does not have a story for bundling at all.
 Of course formats can be invented in userland but I'm not sure that they
 are any easier to implement than say AMD's.  I might have missed something
 though, looking forward to your reply.


 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss



 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss


 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss





-- 
Bitovi
Development | Design | Training | Open Source
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Are ES6 modules in browsers going to get loaded level-by-level?

[Matthew Phillips]

Can you clarify what you mean about bundling? Unless I've missed something,
the ES6 module system does not have a story for bundling at all. Of course
formats can be invented in userland but I'm not sure that they are any
easier to implement than say AMD's.  I might have missed something though,
looking forward to your reply.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss