Sorry, missed the Yoda misquote at the end, I must respond!
Yoda said "where you are" but you used "was". Possibly just a tense-typo, but it matters. Tracking where JS is is a part of the TC39 job, but only a part. It's easy to fall into a trap where we standardize only what developers can express given the language's current semantics and so miss the chance to extend those semantics.
But I'll take the tense-corrected bait: yes, I talk about the future. The past (including its most recent instantaneous sample known as "the present") is greedy. With no one to look ahead or synthesize ideas from compile-to-JS and other languages that win user support, JS will tend to stagnate, all else equal. Champions (not just me) must fight for a better future.
Stagnation on the web is a social ill. It costs developers tons of time. We know this not only from IE6, but from Android 2.x WebKit. Some not-disinterested parties might want to make use of a crisis of this sort, to force a "new JS" (Dart? remember WPF and WPF/E in the past) to be adopted for want of anything to relieve the stagnation.
Not me. The cost is too high, the lessons learned in JS will be half- or three-quarters-lost, and too much code and developer brainprint will be thrown away. I'm reminded of the XML Utopia that was planned in w3.org to save us from bad old HTML, before a few of us called b.s. and started the whatwg.org to do HTML5.
The web is an evolving system, JS is part of the web standards and must evolve too. Skate where the puck will be. Or to wannabe Yoda on ice: where the puck will be, you must skate!
> The web is an evolving system, JS is part of the web standards and must evolve too.
I don't see too many language gizmos in the presentation which reflect the requirements of web standards. Most of them are extensions to a language which desperately needs modification more than extension at this time. Evolution in a language is a matter of where you spend your development resources. &rest-args, weak maps, modules, and so on would be nice to have. But I would gladly sacrifice them to the gods to get rid of JS's global variable issues. It seems to me that ES is mostly building more and more features on top of a foundation of sand rather than taking a breath and revisiting how to reinforce the foundation.
Apple did this recently. OS X 10.6 (Snow Leopard) was an entire release that consisted of almost nothing but cleaning house. Few new features, just heavily revised internals. It's probably the most important release Apple has done in a very long time.
Now one can make the argument that fundamental fixes to long-standing language flaws is a challenging thing to produce given the bulk of development work which relies on the old language. That's a different discussion and one worth having. But moving forward with gizmos simply for the "future"'s sake, without considering the current sad state of the language, is I think misguided. I would strongly urge the committee to take a step back and identify the top twenty most problematic features of the language, and how they might be able to develop a "strict" version of the language which fixes those features, yet retains interoperability with code files written in non-strict form. Then they can go back to adding new gizmos.
Ok, "was" -- but not "you", rather, "he" as in "where he was".
With "me" it's a question of "is". JS is used for purposes far beyond its original design limits. A victory condition and a call to evolution. ES6 is Ecma TC39's attempt to hit that target.
Yoda said "where you are" but you used "was". Possibly just a tense-typo, but it matters. Tracking where JS is is a part of the TC39 job, but only a part. It's easy to fall into a trap where we standardize only what developers can express given the language's current semantics and so miss the chance to extend those semantics.
But I'll take the tense-corrected bait: yes, I talk about the future. The past (including its most recent instantaneous sample known as "the present") is greedy. With no one to look ahead or synthesize ideas from compile-to-JS and other languages that win user support, JS will tend to stagnate, all else equal. Champions (not just me) must fight for a better future.
Stagnation on the web is a social ill. It costs developers tons of time. We know this not only from IE6, but from Android 2.x WebKit. Some not-disinterested parties might want to make use of a crisis of this sort, to force a "new JS" (Dart? remember WPF and WPF/E in the past) to be adopted for want of anything to relieve the stagnation.
Not me. The cost is too high, the lessons learned in JS will be half- or three-quarters-lost, and too much code and developer brainprint will be thrown away. I'm reminded of the XML Utopia that was planned in w3.org to save us from bad old HTML, before a few of us called b.s. and started the whatwg.org to do HTML5.
The web is an evolving system, JS is part of the web standards and must evolve too. Skate where the puck will be. Or to wannabe Yoda on ice: where the puck will be, you must skate!