The prototyping efforts are appreciated, but can rarely be used in a comfortable way. (Compared to, say, HTML5.) I've thought a lot about how to feasibly use Harmony features in real-world code, but have fallen down every time. Here are some of the stumbling blocks I've encountered: * Node.js with --harmony flag gets you collections, old proxies, and (significantly) block scoping. But Node does not make it easy to indicate "this file needs to be run with --harmony," or e.g. to require harmony-using files from non-harmony-using libraries. So this ends up being a nonstarter for library authors, leaving it only usable by application writers. Besides, the proxies are still old, which is really unfortunate. And the iteration rate is slowww: stuff like destructuring has been harmonized for a long time, but shows no sign of making it into V8.
* The same problems apply to desktop apps written with Chromium Embedded Framework. These will probably have more app code, but then if you want to factor any of it out into smaller redistributable modules, you limit your audience. * SpiderMonkey has a lot of stuff that we would love to use, and a fairly fast iteration time. (Direct proxies are almost landed, according to my bugmail!) The spec is tracked pretty well, too. But SpiderMonkey has very little uptake outside of Firefox, and most code written for Firefox must be web-compatible, so nobody except Firefox extension authors gets to use its many features. * Traceur seems to be coming along nicely, but its alignment with the spec leaves a lot to be desired. Destructuring just got fixed a few days ago, and they have a class syntax you have to avoid to write ES6-as-it-is--compatible code. They have features like private names that are not (really) in the spec yet, using speculative syntax (`new Name` was never harmonized, was it?). Monocle-mustache is in, somehow. Etc. It's ES6-like, but doesn't reflect TC39's actual progress, instead reflecting the Traceur team's interpretation of where TC39 might eventually, hopefully, end up. Subsetting might be a solution, assuming the semantics of the subsetted features are aligned with the spec, but determining that would require further investigation. * And of course there's the usual elephant in the room, viz. Internet Explorer. We (Barnes & Noble.com) reached out to Microsoft about including some basic, already-harmonized features in IE10 for use in writing desktop apps in HTML5/JS as per their new Windows Runtime framework. (This was desired since we are using some of them in our existing Chromium-based desktop app, namely block scoping and weak maps.) But even as a "first class partner" (or something), they were unable to grant us this request. The attitude that I personally inferred was that ES6 won't make it into IE before a finalized spec is available. This not only stalls web progress, but also that of anything that embeds Chakra (a fairly common operation on Windows, about to become much more common with Windows 8). > -----Original Message----- > From: [email protected] [mailto:es-discuss- > [email protected]] On Behalf Of Brendan Eich > Sent: Wednesday, May 23, 2012 22:20 > To: Brandon Benvie > Cc: [email protected] Steen > Subject: Re: minutes, TC39 meeting Tues 5/22/2012 > > Play fair now. SpiderMonkey in Firefox prototyped let, const, generators, > iterators (an earlier form), destructuring (close to final ES6), > comprehensions, generator expressions, and more recently proxies, weak > maps, maps, and sets. V8 joined in the proxies, weak maps, maps, and sets > fun. The for-of loop from ES6 is in SpiderMonkey now. Most significantly, > modules are under way in SpiderMonkey and V8. > > We prototype as we go. V8 has kept stuff under a flag and that's fair -- > we may do likewise, certainly with new stuff likely to change, in > SpiderMonkey. But saying nothing is coming out of TC39 is inaccurate. > > If you mean classes are not being prototyped because 'const class' or > equivalent is not part of the almost-at-consensus "maximally minimal > classes" strawman, you're right. If we must have a way to fix the > properties of a class instance as Waldemar wishes, then I predict classes > won't be in ES6 and it will be hard to justify prototyping less than the > full required (as yet unwritten) proposal that satisfies everyones' > wants. > > That is a shame, and a stain on TC39's escutcheon. But you should be > accurate about the many other things we have done, which are coming > along. > > /be > > Brandon Benvie wrote: > > The last discussion point there is really important I think. I get a > > strong sense of the general JS developer world feeling no connection > > at all to this process, and much can be put directly on the sheer > > timescale. We've seen 2 month browser version cycles come in force, > > the "living standard" that is HTML5 and the as of recent rapid > > movement of new APIs coming out to JS from not-TC39. People don't feel > > connected to the things in ES6 because they rightfully can't envision > > using them in an imaginable timeframe. > > _______________________________________________ > > es-discuss mailing list > > [email protected] > > https://mail.mozilla.org/listinfo/es-discuss > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
