On May 23, 2011, at 11:33 AM, Luke Hoban wrote: >>> there are lots of ES.next features that let us do something that we could >>> not do at all previously (weak tables and refs are a good example). >>> features that enable new kinds of applications we couldn't previous build. > > +1 on this point. There’s been a lot of discussion of syntactic sugar > recently, but much less discussion of the features that provide new > capabilities, or new opportunities for meaningful performance enhancements > that make new kinds of applications possible. Features like private names > as a library feature, String and Math enhancements, proxies, runtime > capabilities for module loading, typed arrays, and others are incremental > enabling value which unblocks or makes realistic things which aren’t > currently possible. These are also features that are more likely to be > implemented sooner, and which developers can adopt more quickly and smoothly > via feature-detection in 'text/javascript'.
We have almost all of these already on the wiki and most of them in for ES.next, or else on the agenda this week to get in. I write "almost" because it seems to me you've mentioned two things, one that is not enough, the other that doesn't work: 1. Runtime module loading from old code means new code in strings or loaded via XHR. First, we have Module Loaders, which can do that. Second, it is not enough to disparage modules in full including new syntax. So it should not be used to undermine new module syntax. 2. Private name APIs usable from application/javascript without opt into Harmony would not work correctly on old browsers. That seems like a fatal flaw. /be _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
