My JavaScript book is out! Don't miss the opportunity to upgrade your beginner or average dev skills.

Friday, January 23, 2015

JavaScript and the living ECMAScript Standard

ECMAScript 2015, aka ES6

For those who don't know yet, ECMAScript, also known as ES, is the specification that defines semantics, syntax, and behaviour of the JavaScript programming language.
The versioning of such specification has historically been represented by edition numbers: ES3, or 3rd edition, is the most used and compatible ECMAScript specification ever, making JavaScript virtually the most deployed programming language in the world, compatible and often mandatory on the Web, embedded or translated in IoT devices and developer boards, available on the server through various implementations and engines since 1999.
It has also been decided, when the current standard went out, that one of the prime-goals of the ES specification is to not break the Web, meaning being enriched in a backward compatibility way.

We are virtually in 2011 2009 under ES5.1 umbrella

The current "running" version of JavaScript is based on a modification of the original ES5 specification, called ES5.1.
ES 5.1 is dated 2011 but it's just a typo/fixing version of ES5 dated 2009.
It's the first specification that has been officially adopted in IE ditching the historically slightly different JScript engine used in IE8 and lower.

Despite it's been 6 years since it has been officially published, and considering that it took long time to be finalized since it came out after a "never made it" ES4 version, there are still few quirks in modern engines as you can see in this table. We are almost fully compatible cross platform with such specification dated 2009.
To give yourself a better idea on how long it takes to fully match a specification, regardless it's almost complete and out, just have a look at version 6 of the same table.

A confusing last minute naming change ... for good

As some sort of curse, the JavaScript name and everything around it has been confusing since the beginning of the time:
from The World's Most Misunderstood Programming Language by Douglas Crockford

JavaScript, aka Mocha, aka LiveScript, aka JScript, aka ECMAScript, is one of the world's most popular programming languages. ...

The Name
The Java- prefix suggests that JavaScript is somehow related to Java, that it is a subset or less capable version of Java. It seems that the name was intentionally selected to create confusion, and from confusion comes misunderstanding. JavaScript is not interpreted Java. Java is interpreted Java. JavaScript is a different language.

JavaScript has a syntactic similarity to Java, much as Java has to C. But it is no more a subset of Java than Java is a subset of C. It is better than Java in the applications that Java (fka Oak) was originally intended for.

JavaScript was not developed at Sun Microsystems, the home of Java. JavaScript was developed at Netscape. It was originally called LiveScript, but that name wasn't confusing enough.

The -Script suffix suggests that it is not a real programming language, that a scripting language is less than a programming language. But it is really a matter of specialization. Compared to C, JavaScript trades performance for expressive power and dynamism.
Now ... think about it ...
Once finally clarified for some, but not for everyone, what JavaScript is, It took years of community effort to explain what ECMAScript is about, and how to reference a specific version of it so that in 3 letters we can describe the past, ES3, the present, ES5, and the future, ES6.
People keep posting ES6 related things on the web! There are websites named after ES6, there are talks on YouTube, and in Dr. Axel Rauschmayer case, as well as other authors, there are books titles that would like to be as accurate as possible for credibility sake of the author, at least, and for converging within the community about a single name to specify a list of expected features.

This is not just me being a drama queen as someone might think or even laugh reading that Axel's question in es-discuss related thread, this is also a concern for libraries shelves or articles and blog posts that will be considered outdated before vendors will even be fully compatible with the mentioned year.
It will take years indeed before the ES6 table will become as green as the ES5 one, and it will take years to explain that to look at what the web called ES6 for 2 years has been renamed into ECMAScript 2015.

Apparently toward a year-based label naming convention anyway

So the reason behind this renaming is not to convince the rest of the world that in es-discuss they sell good stuff to smoke, rather to promote a faster rolling release cycles which is actually good since browsers implement whatever they want in the order they want anyway.
Chromium has already a presumably "ES7" Object.observe but still no bloody Proxy in its engine, so saying Chrome is targeting ES6 is basically telling a lie.
Going to a year-based naming convention might be more confusing for developers, they have to master features detections more and more moving forward with engines fragmentation based on rolling specifications anyway, but it could be good to define matching point for vendors and their engines.

What's the bummer

ES5 was the first attempt to improve JavaScript since 1999. 10 years later it came out nice, non breaking, and with tons of good new features most books and blog posts still don't fully know. ES6 race, together with the already widely discussed ES7 or however it will be called, is being a bit more anarchic.
JavaScript is probably the closest programming language to the utopia "write once, run everywhere". The amount of fragmentation that tripled with the Mobile Web era has never played a "fun to deal with" role for developers. They are sick of inconsistencies across platforms, they also are sick of engines stack in the past, as the io.js effort already demonstrated.
The community knows what it wants, and we are all thankful for the incredible effort TC39 and es-discuss ML is putting to keep developers updated, part of the specification, and informed of what's going on, but deciding that specs MUST roll out no matter what each year does not give me any more confidence I can actually use anything cross platform anymore.
Numeric edition of the specifications were probably not perfect, but as main milestones, as main deadline, these have done a pretty good job in describing expectations and set of features ... a year ? What a year would tell you, every year is just another year ... no milestone achieved, no idea how to measure compatibility, and not feeling like the following way to talk about features would be better than what we have now. Well, put in this way, at least now there will be less surprise whenever we'll find out that people started talking about ECMAScript in YYYY units.h3

... and the ISO Standard ...

As Allen pointed out in his comment there is also a document representing the third submission of the ECMAScript as ISO/IEC 16262 standard, marking the current standard known as 16262:2011 which is about ES 5.1.
For those thinking that it would then be that simple and fair to name JS same as C++ not only the current JS should be called JS11, just to create some extra branding confusion, but there are already versions of JS called js17 and js24, these are SpiderMonkey implementation of the JS engine, often used as utilities in Linux.
If ES6 will be proposed as ISO standard it will be known as the fourth submission for ECMA-262-6 document as standard ISO/IEC 16262 in 2015.
So what's the other problem with year-based release? Mostly this: And at this point, if ES7 or 7.1 will be submitted in 2017 then we'll already have confusion with JS17 as mentioned before but the good news is that at least, the official ISO standard could play the milestone role I'd like to refer when I am talking about features.
In that sense, in that case, I personally wouldn't mind calling it ES15, ES17, ES20, referring to the ISO standard.

5 comments:

  1. Originally I was feeling excited to let go of "ES6" and use this new year-based branding. Feels more current, feels like how browsers ship frequently. Certainly the frequent shipping is good for TC39 and the standard.

    While I'm not very concerned with the pain points brought up in your article, I mostly think the year of spec publish has a decent disconnect between when developers get to adopt it. C, C++, and Haskell have had revisions named by years but obviously they don't have the same distribution challenges as JavaScript.

    Chrome, the software project, just recently upgraded to C++11 and have been exploring the new language features to improve things. It has felt exciting, even as a bystander. Up till now, I hadn't known that C++11 actually was equivalent to C++2011, but honestly if it had been called that, my excitement and reaction would be feel like we're just overdue and it's someone's fault. I think there's value to feeling you're using the "latest and greatest."

    In that respect, major adoption of ES2015 (and beyond) will be trailing by 1-3 years, and thus, the branding kind of guarantees the product to feel stale when you are adding it to your codebase.

    ReplyDelete
  2. C++ doesn't have annual updates ... and C++11 is the equivalent of ES5 "transpiled" in the JS world.

    If it was clear since the beginning that year-name convention would have been "just because dates" I wouldn't have spent time explaining why I think it's wrong.

    The very specific intent of the year-name based labelling is in Allen post at the top of this one:

    We hope the year-based branding will catch on in prep for annual updates

    Having each year a new standard will result just in more confusion.

    Allen himself also stated in the ML the following indeed:

    it's going to be confusing around the time we get to 2025 (Edition 16??) and somebody needs to ask: why hasn't BMW implemented the geo location properties from ES13 yet? (or was it 14, no maybe ES12).


    It's already confusing to talk about ES2015 refering ES6 nd 2016 thinking about ES7 that will probably never even made for that year.

    ReplyDelete
  3. just to be clear, I wasn't saying we disagree, I was rather stating I aree with you and **also** there's much more behind. They want to catchup yearly, but practically noone will manage so we'll keep saying we are in de-facto ES2011 era for other years to come ... which indeed, doesn't feel right to me.

    ReplyDelete
  4. Just to further complicate things, you may not be aware that the ECMAScript standard is also published as an ISO standard with a different document and edition number. ES5.1 in addition to being published as ECMA-262-5.1 (and ECMA really would have preferred calling it ECMA-262-6, but we changed their mind) is also the "3rd edition" of ISO/IEC 16262 which they also call 16262:2011.

    Now you probably don't really care about any of this, but there are people in the world (including government bodies that do).

    Finally, ES5.1 added no new features to ES5, it simply incorporates some typo and technical bug fixes that were identified in preparing the ISO versions. see: http://www.ecma-international.org/ecma-262/5.1/#sec-F

    If you really want to accurately characterize the current era of ES in the manner you are doing it should be ES2009, not ES2011.

    ReplyDelete

Note: Only a member of this blog may post a comment.