HTML5 Zone is brought to you in partnership with:

I'm a front-end engineer at Twitter (@angustweets) and a fanatical JavaScript enthusiast. My blog "JavaScript, JavaScript" can be found at I'm also a mentor at and have contributed to JSMag. Angus has posted 7 posts at DZone. You can read more from them at their website. View Full User Profile Needs You!

  • submit to reddit

The next JavaScript specification is moving towards completion. TC39, the technical committee charged with creating (also known as ES Harmony, and sometimes ES 6) has already tentatively approved a number of proposals and there are a bunch more straw men awaiting approval. TC39 includes some of the finest minds in JavaScript (not least, Brendan Eich himself) but as Jeremy Ashkenas famously cautioned “JavaScript is too important to be left to the experts”. They need our help.

The Problem


Nicholas C. Zakas @slicknet

While TC-39 discusses all manner of quasi-foo-magic, we really still just need HTML escaping and the equivalent of String.format(). ::sigh::

4 May 12

Some history. In order to foster consensus on the heels of the ambitious yet ultimately ill-fated ES 4, which was abandoned due to internal wrangling, ES 5 adopted a deliberately incremental and conservative approach, addressing immediate pain points without significantly restructuring the language. picks up many of the threads left over from ES 4, sometimes co-opting idioms and conventions from other languages in an attempt to address decade-old issues which, in truth, many productive JavaScript developers have long since overcome. There are some in the JavaScript development community who have severe misgivings over this approach, while others are generally happy but have the knowledge and experience to offer improvements. Unfortunately members of both groups are having a hard time being heard.

Christian Johansen @cjno

What I want from ES6: Remove constructors, remove ASI, remove ==, add async module API (not syntax). Add nothing more.

26 Apr 12

There is essentially one channel of input into the the TC39 group – the es-discuss mailing list. Unless you’re already a member of TC39, it’s a less than an ideal forum for change. Non-members can feel like outsiders, outflanked by TC39 gurus, who (understandably) would rather not revisit the scenes of their hard-fought consensus, so instead simply restate (often en masse) the opinions that got them there. Being a visitor to es-discuss is often frustrating; its untenable for an individual to claim to represent the perspective of the developer community, yet without the weight of the developer community, lone voices are easily dismissed. Many developers have told me they have given up on es-discuss, some have even stated that they hope will just go away. That’s too bad, it means our extraordinary community, the innovators and the creators, the doers and the fixers are (or feel they are) effectively excluded from the process whereby the next version of their language will be defined.

Oliver Hunt @ohunt

I really wish that tc39 would stop trying to turn js into perl or ruby.

8 May 11

Getting onto TC39 is tough, it takes plenty of time and money. In Brendan Eich’s words “It’s hard unless you are a non-profit”. The TC39 committee does a great job of poring over the academic nuances, and to their credit they’re also making huge efforts to make the language more accessible to those with little or no JavaScript experience. But the big disenfranchised white elephant in the room is us: experienced, capable JavaScript developers who love the language for what it already is: closures, first-class functions, a limited syntax which in turn provides an unlimited capacity for innovation. We know the quirks, we work with them every day and invariably we’ve learned how to use them to our advantage. In fact, love of the language is what appears to be missing from the current set of proposals. Classes in a dynamic language where mock classical inheritance is the third of fourth best form of re-use, hard lexical this binding which erodes the feasibility of call and apply and adds yet another rule of context assignment, block scoped let declarations that must co-exist with function scoped var declarations, incongruous const and static keywords, type guards. Which of these features have we, the developer community, been holding our breath in anticipation of? How is the addition of these features (when backwards compatibility more-or-less forces the retention of existing language features) going to simplify the language and keep it flexible?

Mikeal @mikeal

starting to get the impression that ES-Harmony is IPv6

22 Mar 12 feels like step one of a well-intentioned long term master plan – with the ultimate aim of weaning developers off of some of JavaScript’s most characteristic features: functional scoping, late this binding, prototype semantics, globally bound natives and the arguments object – to name a few. The scale of these proposals means browser adoption will inevitably be staggered and piecemeal, and of course legacy code must still work; so while new features are added, old ones cannot be removed. The short term looks like a confusing mess of new rules and semantics coexisting with old ones.

Famous JavaScripter @JSProfessor

Proud to announce ES6 will have both function scoped 'var' and block scoped 'let'. At the same time. Because that's much less confusing.

5 May 12

To be clear has good things too: the module loader proposal is huge (though we must ensure the API is concise enough to encourage adoption); weak maps and proxies seem like natural fits for the language and will have little or no impact on the legacy code base; and Object.extend (or a variant thereof) is long overdue. Still a large portion of the developer community remains gravely concerned by the sheer weight and complexity of new features, or worse still, they’ve become disinterested in the entire process. We’re too good to not have a say in the next JavaScript.

Angus Croll @angustweets

Now this?… I dispute the oft made assertion that adding more features does not take anything away from the language

Balázs Galambosi @galambalazs

@angustweets "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away."

27 May 11




JSFixed is an initiative created by Anton Kovalyov and myself. There are two goals

1) Provide the the TC39 committee with a much needed gauge of developer opinion.
2) Provide developer feedback directly to browser vendors.

As a first step we want to hear your opinions as we explore the best way to make this project effective. Should we develop and promote our own set of language proposals or should we focus on filtering and refining the existing TC39 work according to actual developer need? Do you want a different set of features than those advocated by TC39, or just fewer new features? To that end we want to encourage all interested developers to submit feedback via our github account. We’ll also be reaching out personally to interested developers via coffee, beer, IRC, IM and email.

Our intention is for the discussion process to be entirely open and documentation media to be freely editable, wiki-style. However, in order to avoid the endless back-and-forth and design-by-committee nature of the TC39 process, final proposals will likely be triaged and voted on by a team of 3-5 people (with full deference to the feedback of the community). We want to encourage a transparent and approachable documentation style with copious examples. Backus-Naur notation, while a necessary formality, should not be a pre-requisite to understanding a proposal.

We Need You!


The indifference of many developers towards the EcmaScript standard is understandable. They didn’t write it and it doesn’t represent their needs. This can change. We, all of us, can change it. By putting developers at the center of the design process we can remove the perceived barrier between TC39 and the larger JavaScript community, and by doing so breath fresh life and energy into future standards. Everyone who cares about JavaScript ought to have a stake in its future, everyone who cares about JavaScript needs to be heard – web developers, node developers, CoffeeScript developers, anyone whose productivity and creative output depends on JavaScript. The greater the participation, the easier it becomes for JSFixed to speak on behalf of JavaScript developers and the more JavaScript becomes representative of all those who use it.

It is our hope that by acting as a clear and vocal advocate for the developer community, JSFixed will have a positive impact on the TC39 process, and JavaScript.

JS Fixed @jsfixed

Join Us!

6 May 12

● Create an issue at github
● Follow us at @jsfixed

Published at DZone with permission of its author, Angus Croll. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)