On Wednesday, May 23, 2012 at 10:08 PM, Domenic Denicola wrote: > 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.
I just used Traceur 2 days ago and wrote max/min style classes. > 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. > > There is a lot of support and interest for the mustache in TC39 > 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. > > I don't think this is a fair claim to make, considering Traceur had no real attention for quite some time and Erik Arvidsson really stepped it up to get a nice cross section of features prototyped in a short amount of time. I think what you meant to say was "thank you". > 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). Blaming TC39 for IE's slowness is about as appropriate as blaming me for the Boston molasses disaster. Some feedback about your feedback: I'm wondering if you have any thoughts about the actual minutes? Rick > > > -----Original Message----- > > From: es-discuss-boun...@mozilla.org [mailto:es-discuss- > > boun...@mozilla.org] On Behalf Of Brendan Eich > > Sent: Wednesday, May 23, 2012 22:20 > > To: Brandon Benvie > > Cc: es-discuss@mozilla.org 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 > > > 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 > >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
