TC39 vs "the community"
johnjbarton at google.com
Fri Jun 20 08:39:44 PDT 2014
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
> 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"
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss