After the discussion on the Seed proposal thread about what flavor of JavaScript should GNOME as a project use, I made a point of figuring out what’s the current status on the ECMAScript standarization saga.
This is old news by now, but some of you might not know that the ECMA committe responsible for JavaScript decided last year to pretty much do a full reset and try to move forward step by step instead of doing everything and the kitchen sink in one go; that is, instead of the ES4 revolution we would have the ES3.1 spring cleanup. Well, 9 months later and, ironies of life, the next standard will be called ES5 instead of ES3.1 (although it’s still an incremental improvement), and the final draft is already available (PDF).
So, what’s in it? These google slides do a pretty good job at introducing the changes, but I’ll try to do a warp-speed summary here:
- A new ‘strict mode’ to ease robust and defensive programming. You can look up the details in the slides, but a single feature would have been worth it for me back in my litl days: failed assignments throw an exception in strict mode.
- Function.prototype.bind to fix one of the first WTF moments one has when learning JavaScript: closures do not capture ‘this’.
- Higher order array methods: map, every, some, filter, reduce… all are there.
- Built-in JSON implementation.
- getter/setter properties, plus syntax for fine grained control of properties access.
From my limited experience with JavaScript I think this fixes some obvious issues in the language, while others are in the backburner for future revisions (lexical scope, const, destructuring assignment, …), so I’d say things are looking pretty good.
Of course, the bigger issue is: should we require the JavaScript in GNOME to follow ECMA standards (ES3 now, ES5 and following in the future) in order to be able to use any compliant implementation, or should module owners be allowed to use vendor-specific extensions if they think it’s in their benefit to do so? I guess that’s up for debate, but it seems to me that we live in too interesting times to paint ourselves in a corner with a given implementation at this point.
John just put up a nice post about this:
http://ejohn.org/blog/ecmascript-5-strict-mode-json-and-more/
That has a huge number of the specific language details.
I think allowing vendor-specific extensions would be a serious mistake, since I assume you don’t intend to make any long term guarantees about which javascript implementation (e.g from Mozilla, WebKit, or something else) you’re going to be using?
I disagree with Simon. Feature-testing thrives on the web, and I see no reason it can’t thrive in this environment as well. I’m less sure about the syntactic extensions, but I think it’s at least reasonable to allow const seeing as every engine out there (save for a certain elephant which doesn’t matter in the GNOME context) supports it. Also, as far as “lock-in” goes, assuming you follow certain best practices (use semicolons!) it wouldn’t be particularly difficult to desugar most syntactic extensions into ECMA-compatible code (and even if semicolons were omitted it still would be feasible to do so, just with more effort and probably with a hand-rolled parser).