Re: TC39 vs "the community"

[John Barton]

On Fri, Jun 20, 2014 at 2:03 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> I am trying to stay outside this discussion as much as I can but there is
> a specific sentence that I'd like to understand:
>
>
> On Fri, Jun 20, 2014 at 8:39 AM, John Barton 
> wrote:
>
>>
>> The ES5-module using community tried, valiantly, to reach a compromise
>> module solution. They were not successful.
>>
>
> how 80K modules mentioned by Domenic, the concrete adoption of CommonJS or
> the usage of Browserify for most of the web, can be defined exactly a
> failure?
>

Individually both node modules and amd modules are a huge success. I was
only referring to the unsuccessful effort at convergence.


>
> I am not sure ES6 modules have been overlooked since the beginning but I
> believe that the rest of "the real-world" in production out there will keep
> doing just fine with current inline or AMD based `require("module")` logic.
>
> A new ES6 syntax, unfortunately unable to be brought over a UML (Unified
> Module Loader) as it has done before, will also take much longer to became
> a de-facto standard as `require` has become these days.
>
> Here probably the "community" sentiment Domenic mentioned, everyone I know
> somehow applauded fat arrow, nobody I know reacted differently from
> "WTF?!?" about ES6 modules.
>

> That being said, as complex and powerful APIs can be wrapped and brought
> to simpler libraries, maybe we actually will keep using `require` but with
> `import ES6 from "module"` behind the scene so everyone might win?
>

To the best of my knowledge, nothing in ES6 prevents you from continuing to
use `require()`.  If you think require() is the perfect module system, then
use it.   I think the ES6 module system is better and I plan to use it. If
we ever stop talking about it and ship it.

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

Re: TC39 vs "the community"

[John Barton]

On Fri, Jun 20, 2014 at 6:42 AM, Domenic Denicola <
dome...@domenicdenicola.com> wrote:

> > Can you develop these particular accusations?
> > Why would TC39 have priorities that don't align with the needs of
> developers? especially on modules which are clearly one of the most awaited
> feature as far as developers are concerned?
>
> TC39 has a lot of constituents who use their experience with other
> languages to develop the shape of features, instead of building on
> community-developed solutions to the problems the community sees as worth
> solving. In modules this is particularly apparent. If you want a qualifier
> for "community," try "ES5-module using community."
>

The ES5-module using community tried, valiantly, to reach a compromise
module solution. They were not successful. Thus ES6 cannot build on their
solution. Their experience did however have a huge impact on the ES6 module
design.


>
> I wouldn't call these accusations, and in general I don't appreciate the
> uncharitable (perhaps even accusatory) tone of your message. Experience
> from other languages is valuable in evolving a language---of course! It
> would be silly to think otherwise. And often these working modes are not in
> conflict at all, allowing us to solve problems the community has run into
> by drawing upon our experience with other languages. But there is,
> especially in this case, a real conflict between the guidance from other
> languages and the guidance from "the ES5-module using community's"
> experience.
>

I started out with a similar opinion. Then I wrote some ES6 code.

What we need now is experience from using ES6-modules. We have plenty of
decent implementations. We've built nodejs and browser applications based
on ES6 modules. That experience shows that the ES6 solution is modestly
superior to any ES5 solution. Moreover the ES6 solution interoperates with
the main ES5 solutions.  Are there projects which attempted to use ES6
modules but where unable to succeed because of technical barriers?


>
> > Whatever they end up looking and behaving, ES6 modules will happen with
> "the community" or without it.
>
> They may "happen", in that engines may indeed implement the syntax once it
> settles, and browsers may indeed implement a loader once it's designed and
> specced. But whether they will be adopted by, say, Node.js (by supplying
> their own loader implementation), or the 80K packages on npm, or by the
> developers who are currently using AMD, or the developers who are currently
> just happy with 

Re: ModuleImport

[John Barton]

On Thu, Jun 19, 2014 at 10:48 AM, Axel Rauschmayer  wrote:

> On Jun 19, 2014, at 16:17 , John Barton  wrote:
>
> Sorry to be dense, but I would appreciate more elaboration of this
> sentence:
>
>
> On Thu, Jun 19, 2014 at 3:40 AM, Axel Rauschmayer 
> wrote:
>
>> This is a key sentence in David’s proposal: “ES6 favors the
>> single/default export style,
>>
>
> What is the "single/default" export style?  If I understand this claim, it
> says that a module will typically contain a single export statement, either
> named 'default' or not. Is there any evidence to support this? Everything
> I've seen contradicts this claim, assuming I understand it.
>
>
> The syntax is (
> https://people.mozilla.org/~jorendorff/es6-draft.html#sec-exports ):
>
> export default AssignmentExpression
>

Yes, but I was not clear: where is the evidence that ES6 favors this form
or single named export. My experience is opposite: the simple thing in ES6
is to export those things you want exported. If it's one thing, then one;
if it's 6 things then 6. One is not favored.


>
> and gives the sweetest syntax to importing the default. Importing named
>> exports can and even should be slightly less concise.”
>>
>
> Could you please give an example? In my experience, "export default" is
> rare or at least divisive since it seems stylistically incompatible with
> named exports.
>
>
> I’m surprised, too. But that seems to be the feedback from people working
> with large module-based client-side projects and from the Node.js
> community: single exports are most common.
>

I still don't get it. If you want one export, just export one thing. If you
want one big export object called _, then
  export var _ = {tons of stuffs}

One of the best references for devs to understand modules:
http://www.2ality.com/2013/07/es6-modules.html
says:
   The syntax for importing a default export is similar to normal
importing, but there are no braces

To me this is a bug not a feature; we should keep it simple and just have
one way to get one import from one export.

Just to make a connection to the topic, Dave's intro says:
   We've consistently seen confusion between the semantics of ModuleImport
and default export.

For me this confusion lands on default export equally as 'module` import.


I think in client-side projects, one class per module was reported as a
> frequent use case:
>
> ```js
> // MyClass.js
> export default class {
> ...
> };
>
> // main.js
> import MyClass from "MyClass";
> ```
>
> --
> Dr. Axel Rauschmayer
> a...@rauschma.de
> rauschma.de
>
>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ModuleImport

[John Barton]

Sorry to be dense, but I would appreciate more elaboration of this sentence:


On Thu, Jun 19, 2014 at 3:40 AM, Axel Rauschmayer  wrote:

> This is a key sentence in David’s proposal: “ES6 favors the single/default
> export style,
>

What is the "single/default" export style?  If I understand this claim, it
says that a module will typically contain a single export statement, either
named 'default' or not. Is there any evidence to support this? Everything
I've seen contradicts this claim, assuming I understand it.


> and gives the sweetest syntax to importing the default. Importing named
> exports can and even should be slightly less concise.”
>

Could you please give an example? In my experience, "export default" is
rare or at least divisive since it seems stylistically incompatible with
named exports.


>
>
> On Jun 19, 2014, at 12:31 , Michał Gołębiowski  wrote:
>
> Thanks, Dave, for bringing that up, it shows you're open for feedback.
> That said (bikeshed begins), what's wrong with:
> ```js
> import "fs" as fs;
> ```
> ? I feel that a lot of effort went in ES6 into reducing boilerplate via
> e.g. arrow functions, classes etc. but if you start with Node's require,
> this adds clutter. Compare these 3 forms of importing all the module
> "lodash" bindings to an object _:
> ```js
> var _ = require("lodash"); // Node
> import * as _ from "lodash"; // Dave's syntax
> import "lodash" as _;
> ```
>
>
> --
> Dr. Axel Rauschmayer
> a...@rauschma.de
> rauschma.de
>
>
>
>
> ___
> 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

Re: ES6 modules (sorry...)

[John Barton]

I guess there is no technical argument that will convince you. Thanks for
at least having the discussion, more than we got before.

jjb


On Mon, Jun 16, 2014 at 9:02 PM, caridy  wrote:

> John, there are a couple of solutions at hand that you can apply:
>
> 1. loader provides the right hooks for you to hint at loader what are the
> modules you need to need to load. which is literally 10 lines of code for
> an extension of the loader:
> https://github.com/systemjs/systemjs/blob/master/lib/extension-depCache.js
> 2. partial bundling, which Guy Bedford explained in details
>
> You really don't need bundling for the new modules and the new loader.
>
> /caridy
>
>
> On Jun 16, 2014, at 8:19 PM, John Lenz  wrote:
>
> You don't really want 300/3000/3 modules where you have to "load",
> "parse", then "request (dependencies)".  You really need your dependencies,
> pre-ordered and pre-loaded (that is bundled) if you want your "empty cache"
> clients to get a good experience.  SPYD is only one piece of a puzzle it
> isn't a silver bullet for solving module loading. If you want both to have
> an ideal experience you want bundles of modules and delta compression of
> your changes.  Unfortunately, there isn't a good delta compression solution
> yet but I have hopes that SDCH might be made more general and standard.
>
>
> On Mon, Jun 16, 2014 at 4:54 PM, John Barton 
> wrote:
>
>>
>>
>>
>> On Mon, Jun 16, 2014 at 4:49 PM, caridy  wrote:
>>
>>> > I thought SPDY was, to quote wikipedia, about: "reducing web page load
>>>> latency and improving web security"
>>>> > How does SPDY help when the issue is lots of small requests ping
>>>> ponging back and forth between client and server?
>>>>
>>>> SPDY multiplexes the requests across the same connection, which is
>>>> essentially a runtime bundling process at the browser level without the
>>>> hazards of doing it manually, and getting the benefit of the granular
>>>> caching at the browser level.
>>>>
>>>
>>> Just so I understand, if the dependency tree a depth of 20 and say 300
>>> modules how many round trips from client to server will you need using
>>> SPDY? The competition (ES5 prebuilt) uses one.
>>>
>>>
>>> One roundtrip, one cookie is sent, and 300 entries are added into cache.
>>> Imagine making a change in one of those 300 modules, today, with bundling,
>>> the ES5 prebuilt entry in cache gets stale, and you now have to loaded the
>>> whole thing, while using SPDY, only one entry gets stale, so, next time the
>>> user visits the app/page, only that piece will have to be loaded over the
>>> wire, the rest is just going to rely on the browser's cache. This is a
>>> killer feature, specially if you're doing continues deployment.
>>>
>>
>> I agree this does sound great, I just don't see how the browser can know
>> which 300 entries to request until it parses the first entry. If on the
>> other hand you mean the server parses the modules, then it sounds
>> equivalent to bundling.
>>
>>
>>>
>>>
>>>> > (Do we want to wait for SPDY in every browser before we use ES6
>>>> modules?)
>>>>
>>>> All major browsers (including safari) support SPDY today. But the point
>>>> is, we should not consider "bundling" as a prime use-case for modules,
>>>> because it is not going to be important at all.
>>>
>>>
>>>
>>>
>>>> If people want to do bundling, they will have plenty of options to do
>>>> so, even with the current module specs.
>>>>
>>>
>>> Could you enumerate these? I thought that there was no option, which is
>>> why we are asking.
>>>
>>>
>>> We have been working on transpilers to transform ES6 modules into
>>> dynamic modules that can in fact be used today, but also tomorrow, these
>>> dynamic modules (which are covered in the specs today under the loader
>>> section) can be bundle up. In other words, you can use the same tools that
>>> you use today, e.g.: browserify, and they will work just fine.
>>>
>>
>> Ok, you must mean "TC39 don't have any options, you're on your own".
>>
>>
>>>
>>> /caridy
>>>
>>
>>
>> ___
>> 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

Re: ES6 modules (sorry...)

[John Barton]

On Mon, Jun 16, 2014 at 4:49 PM, caridy  wrote:

> > I thought SPDY was, to quote wikipedia, about: "reducing web page load
>> latency and improving web security"
>> > How does SPDY help when the issue is lots of small requests ping
>> ponging back and forth between client and server?
>>
>> SPDY multiplexes the requests across the same connection, which is
>> essentially a runtime bundling process at the browser level without the
>> hazards of doing it manually, and getting the benefit of the granular
>> caching at the browser level.
>>
>
> Just so I understand, if the dependency tree a depth of 20 and say 300
> modules how many round trips from client to server will you need using
> SPDY? The competition (ES5 prebuilt) uses one.
>
>
> One roundtrip, one cookie is sent, and 300 entries are added into cache.
> Imagine making a change in one of those 300 modules, today, with bundling,
> the ES5 prebuilt entry in cache gets stale, and you now have to loaded the
> whole thing, while using SPDY, only one entry gets stale, so, next time the
> user visits the app/page, only that piece will have to be loaded over the
> wire, the rest is just going to rely on the browser's cache. This is a
> killer feature, specially if you're doing continues deployment.
>

I agree this does sound great, I just don't see how the browser can know
which 300 entries to request until it parses the first entry. If on the
other hand you mean the server parses the modules, then it sounds
equivalent to bundling.


>
>
>> > (Do we want to wait for SPDY in every browser before we use ES6
>> modules?)
>>
>> All major browsers (including safari) support SPDY today. But the point
>> is, we should not consider "bundling" as a prime use-case for modules,
>> because it is not going to be important at all.
>
>
>
>
>> If people want to do bundling, they will have plenty of options to do so,
>> even with the current module specs.
>>
>
> Could you enumerate these? I thought that there was no option, which is
> why we are asking.
>
>
> We have been working on transpilers to transform ES6 modules into dynamic
> modules that can in fact be used today, but also tomorrow, these dynamic
> modules (which are covered in the specs today under the loader section) can
> be bundle up. In other words, you can use the same tools that you use
> today, e.g.: browserify, and they will work just fine.
>

Ok, you must mean "TC39 don't have any options, you're on your own".


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

Re: ES6 modules (sorry...)

[John Barton]

On Mon, Jun 16, 2014 at 4:04 PM, caridy  wrote:

> > I thought SPDY was, to quote wikipedia, about: "reducing web page load
> latency and improving web security"
> > How does SPDY help when the issue is lots of small requests ping ponging
> back and forth between client and server?
>
> SPDY multiplexes the requests across the same connection, which is
> essentially a runtime bundling process at the browser level without the
> hazards of doing it manually, and getting the benefit of the granular
> caching at the browser level.
>

Just so I understand, if the dependency tree a depth of 20 and say 300
modules how many round trips from client to server will you need using
SPDY? The competition (ES5 prebuilt) uses one.


>
> > (Do we want to wait for SPDY in every browser before we use ES6 modules?)
>
> All major browsers (including safari) support SPDY today. But the point
> is, we should not consider "bundling" as a prime use-case for modules,
> because it is not going to be important at all.




> If people want to do bundling, they will have plenty of options to do so,
> even with the current module specs.
>

Could you enumerate these? I thought that there was no option, which is why
we are asking.


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

Re: ES6 modules (sorry...)

[John Barton]

On Mon, Jun 16, 2014 at 3:42 PM, caridy  wrote:

> On Jun 16, 2014, at 5:41 PM, Frankie Bagnardi 
> wrote:
>
> > The other big concern here is that in production, very few people are
> going to be loading every JavaScript file asynchronously.  If there's
> magic, there needs to be a reasonable way to handle bundling multiple ES6
> files together.
>
> This is completely off target IMO. We want to walk away from bundling, it
> is tedious, it is ugly, it slows down development, it makes debugging a
> pain, it makes bucketing almost impossible, it is just a pain in general.
> Instead, we want to rely on bundling at the lowest level (at the browser
> level), and that's what SPDY/HTTP2.0 brings to the table, and now that
> Apple is onboard, I don't see why we should consider bundling a relevant
> use-case.
>

I thought SPDY was, to quote wikipedia, about: "reducing web page
 load latency
 and improving web
security "
How does SPDY help when the issue is lots of small requests ping ponging
back and forth between client and server?

(Do we want to wait for SPDY in every browser before we use ES6 modules?)


>
> /caridy
> ___
> 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

Re: ES6 modules (sorry...)

[John Barton]

On Sun, Jun 15, 2014 at 8:32 PM, Axel Rauschmayer  wrote:

> I apologize for this email, but I still don’t understand the current
> module design.
> ...
> **Single-export modules.** Still missing is support for single-export
> modules, which could be added as follows (the keyword `default` instead of
> the asterisk works just as well, in my opinion).
>
> ```js
> // Module 'MyClass'
> export* class {
> };
>
> // Module 'client3'
> import* MyClass from 'MyClass';
> ```
>

Are these now part of the module design or are you advocating for change?
jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Rationale for dropping ModuleImport syntax?

[John Barton]

One unusual but interesting metric: try to find blog posts explaining
   module m from 'mymodule';
vs posts explaining import.   At least my attempts failed.

Basically authors who thought ES6 modules are worth explaining did not
think 'module' was worth explaining.

jjb


On Thu, Jun 12, 2014 at 2:18 PM, Brian Di Palma  wrote:

> On Thu, Jun 12, 2014 at 10:07 PM, Calvin Metcalf
>  wrote:
> > isn't the foot gun the difference between single and multiple exports,
> i.e.
>
> I thought it was imports that were being misused. People were writing
>
> module m from 'mymodule';
>
> m();
>
> So they treated `module` just like `import`. I'm not sure I see the
> logic in doing that.
> Did they not wonder why there were two ways to accomplish the exact same
> thing?
> As I said, I didn't find the reasoning compelling.
>
> > to import underscore you'd use
> >
> > module _ from 'underscore'
> >
> > because it is multiple methods on an object but for jquery you'd have to
> use
> >
> > import $ from 'jquery'
> >
> > because the root object is a function instead of an object
> >
> > On Thu, Jun 12, 2014 at 8:50 PM, Kevin Smith 
> wrote:
> >>
> >>>
> >>> I was more wondering if there was anything preventing a module import
> >>> statement from being added later, if it was found to be a requirement.
> >>> I can't see any reason why it couldn't, that would also allow time for
> >>> bikeshedding the syntax.
> >>
> >>
> >> It could be added later, but to turn the question around:  why should it
> >> be
> >> dropped?  It has been part of the design for a very long time, it's
> >> currently used by many people working in the ES6 space, and it meets a
> >> semantic need.
> >>
> >> If you want to drop a feature this late in the game, then you need to
> show
> >> that it's one of the following:
> >>
> >> 1. Buggy
> >> 2. A footgun
> >> 3. Not useful
> >> 4. Future-hostile
> >>
> >> I don't see that it meets any of those requirements, do you?
> >
> > I have no strong opinions either way. I don't feel it's any of those
> things.
> >
> > The argument that was given was that people were confused by it and
> > were using it like an `import` statement.
> > I said to Eric via Twitter that if people were building incorrect
> > compilers and modules then they will eventually learn the error of
> > their assumptions.
> >
> > To me the argument didn't seem that strong, the native implementations
> > will be correct and people will correct their broken code.
> >
> > I'm not supporting the removal. I simply don't think it's a catastrophe.
> >
> >>
> >> Kevin
> > ___
> > 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

Re: 5 June 2014 TC39 Meeting Notes

[John Barton]

On Thu, Jun 12, 2014 at 7:43 AM, Domenic Denicola <
dome...@domenicdenicola.com> wrote:

>   I like , simply as a better . Whether it's worth the
> cost is largely a matter of finding out what the cost is, from
> implementers. I don't recall reading any opinions from them on the matter.
>
>
>  Hixie has brought up some interesting points on the interaction of
>  and