While TC-39 discusses all manner of quasi-foo-magic, we really still just need HTML escaping and the equivalent of String.format(). ::sigh::
ES.next Needs You!
The Web Dev Zone is brought to you in partnership with Mendix. Discover how IT departments looking for ways to keep up with demand for business apps has caused a new breed of developers to surface - the Rapid Application Developer.
the technical committee charged with creating ES.next (also known as ES
Harmony, and sometimes ES 6) has already tentatively approved a number
What I want from ES6: Remove constructors, remove ASI, remove ==, add async module API (not syntax). Add nothing more.
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 ES.next 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.
I really wish that tc39 would stop trying to turn js into perl or ruby.
starting to get the impression that ES-Harmony is IPv6
Proud to announce ES6 will have both function scoped 'var' and block scoped 'let'. At the same time. Because that's much less confusing.
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
We Need You!