I'll make this point as concisely as possible, since this conversation is
quite given to noise:

While others may disagree, I feel the source of contention/disunity on
modules is more fundamental than syntax or who's (not) listening to who.
 Specifically, ES6 modules are far less immune to platform nuances than
other features, like, say, fat-arrows.  That is, the merits of fat-arrows
are basically the same regardless of what platform you're on... but that
isn't (as) true of modules.  While there's certainly overlap in what Node
vs. Browser vs. PhoneGap (etc.) devs want out of a module loader, there are
necessarily divergences as well.

I say this hesitantly and with great respect for TC39 and its members...
but I have a hard time imagining a unified voice emerging on *anything* that's
situated this close to individual, disparate platform needs.



On Fri, Jun 20, 2014 at 11:39 AM, John Barton <johnjbarton at google.com>
wrote:

>
>
>
> On Fri, Jun 20, 2014 at 6:42 AM, Domenic Denicola <
> domenic at 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 <script> tags, is another question. Any claims
>> otherwise are tendentious speculation, to borrow a phrase.
>>
>
> Implementors and proponents of legacy systems always fight for their point
> of view. It's natural and valuable input. But at this point we are
> speculating about tendencies of developers, not arguing about technical
> feasibility.  Some node developers will never switch; some devs will always
> use script tags; some business apps will be written in COBOL.  It's ok.
>
> jjb
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140620/c9903137/attachment-0001.html>

I'll make this point as concisely as possible, since this conversation is
quite given to noise:

While others may disagree, I feel the source of contention/disunity on
modules is more fundamental than syntax or who's (not) listening to who.
 Specifically, ES6 modules are far less immune to platform nuances than
other features, like, say, fat-arrows.  That is, the merits of fat-arrows
are basically the same regardless of what platform you're on... but that
isn't (as) true of modules.  While there's certainly overlap in what Node
vs. Browser vs. PhoneGap (etc.) devs want out of a module loader, there are
necessarily divergences as well.

I say this hesitantly and with great respect for TC39 and its members...
but I have a hard time imagining a unified voice emerging on *anything* that's
situated this close to individual, disparate platform needs.