I am an avid reader of the ES-Discuss mailing list and I have seen these "disenfranchised" developers this article is talking about, who blunder into the list with their fabulous ideas without lurking first, or searching the mailing list archives or bug databases, or the wiki. It's not hard at all to participate in the ES-Discuss mailing list. You just have to treat it with at least the same degree of respect you'd treat any other forum full of people smarter than you.
Now when I say that, I don't mean that just because they are smarter you have nothing to contribute, but you have to pick up your game a little bit and try not to be completely ignorant when you make a suggestion- since all that does is increase the noise level. But getting to that point is not the horrible insurmountable obstacle the article makes it out to be. It is not hard to not be ignorant.
I understand that you're worried. Trust me when I say that you have no need to be.
The folks on the ES6 committee have no interest in harming you. The statement you quote from the OP is unnecessarily inflammatory.
Back in those heady days in 1995, Eich could have taken the politically easy route and made Javascript nothing but a poor man's Java. Instead, he took the bold route and gave us a delightful little Schemelike. Do you really think he regrets that? Javascript was a success because of its dynamism and simplicity. Nobody's looking to tear that away, or foist OOP on you.
That said, Javascript, as a language, has a few deficiencies. I dare you to find someone who will argue otherwise. The people on the ES6 committee are there because they love Javascript, and want to give it some of the conveniences that have become mainstream in the past fifteen years. Rest parameters. Spreads. Default arguments. Proxies (which are really cool). Modules.
I encourage you to get involved with this project if you're still concerned. But keep in mind that language design is effing[1] hard. C++ and PHP serve as a testament to that fact.
> Javascript was a success because of its dynamism and simplicity.
Javascript was a success only because of its ubiquity, and by the time that happened, most implementations still couldn't even agree on fundamental properties of its implementation (is there really such a thing as a simple, while still practical programming language?).
It basically lived under a rock for the first 10 years of life, until rich web clients really started getting pushed, at which point it was the only even vaguely vendor-neutral plugin-free option around.
those people, who do they think they are? They think they created the language you love in the first place. Themselves. With their own hands. They're terribly sorry about function scope, var hoisting, and dynamic this binding, and ASI. These are obvious, horrible mistakes, that cause bugs. Changing an established language is a bit of a challenge though. These aren't outsiders who blundered in. They know what they are doing.
"If TC39 or anybody else has an idea for a language, that's great. Don't call it Javascript because we have Javascript, and something else is.. something else."
And since Firefox has already supported both var and let for several years now, and most Firefox chrome code uses let exclusively, this approach is pretty well proven in a large code base. As a Firefox developer, I now find it quite annoying to write for JS engines that support only var.
Most of the rant was idiotic, basically "leave js alone". Well keep programming without the new features if you want, its not like they will force you to use let and co.
And those tired "less is more" and "lets not add features lest we complicate the language" are inane...
As far as I can tell from looking through the strawmen, none of those are absolutely necessary and several would just get in the way.
The important stuff has already been added, modules, Object.is, and WeakMaps especially.
With that being said, the @jsfixed team must think something needs to be done, I just wish they had spent any amount of time in this blog post explaining what that is.
I can think of a few things. Today I was needing to get the base domain from a url string and spent entirely too much time writing a function to do it. I wound up using a library called URI.js. But it's insane to me that there isn't a native way to parse a url string in the browser.
It's a hard problem. The reason it is hard is that they have to balance runtime size against the potential value of an addition, against increasing the complexity of the language (Combinatorially- for every feature they have to examine in detail how it interacts with every other feature of the language, which is a lot of work), friendliness to noobs, friendliness to old javascript fans, friendliness to java ruby and python people who hate javascript, etc. etc. For this reason they have focused mainly on features that can't be added with a library for this edition.
How are you really going to make substantive improvements without breaking a lot of things, or basically making it into a different language? Seems like there is a limit to what you can do. Maybe they can add a few optional things, like require. (Fast forward to 2014: Oh, sorry, Internet Explorer doesn't support require, app won't run). Maybe all of these geniuses should stop and instead come up with a way to get rid of Microsoft or Internet Explorer. That's the real problem. Just kidding (sort of).
As long as CoffeeScript still works in the next major version of JavaScript, I will be fine.
By using a coffeescript approach of ES.next to ES.prev compilation. There are several such compilers already, including one from Google called Traceur, and the one as old as Javascript itself, Narcissus. They have been using Traceur and Narcissus for something like "reference" implementations of ES.next, to try out how features work before adding them permanently to the spec.
Sorry to sound like a negative Nancy but how will this prevent fragmentation of JS? I read the weblog, the ecmascript link and the Harmony requirements but nowhere does it say how to tell whether the runtime supports the JS/Next script or which of the big names has commited to following it.
Members of the TC39 committee include representatives from Apple, Google, Mozilla, and Microsoft. Javascript engines from these vendors will almost surely implement the standard. Firefox has prototypes for a few new things already.
Now when I say that, I don't mean that just because they are smarter you have nothing to contribute, but you have to pick up your game a little bit and try not to be completely ignorant when you make a suggestion- since all that does is increase the noise level. But getting to that point is not the horrible insurmountable obstacle the article makes it out to be. It is not hard to not be ignorant.