Going to post something up on the issue soon, if I get around to it – my time being a scarce resource. Just wanted to dump some links on you guys, as a sign WebGraphics isn’t quite dead yet.

Pure documentation

Proposed ECMAScript 4th Edition – Language Overview (PDF)

NOTE: This is NOT the draft of the specification. It’s just a document detailing the changes ES4 is making from ES3.

ECMAScript 4th Edition Grammar (PDF)

This is the ES4 grammar as it looks today – not everything is set in stone yet, I think.

JScript deviations from ES3 (PDF)

A document produced by Pratap Lakshman, JScript team, Microsoft. It details all documented deviations JScript does from ES3, together with some info on what the scripting engines in other browsers do. I’m a little disappointed that the comparison uses Opera 9.0 instead of Opera 9.50, since the Linear B engine used in 9.24 and earlier has been replaced by the Futhark engine in 9.50. However, I haven’t checked how many actual differences can be found for these examples using Opera 9.50.

JScript Conditional Compilation (PDF)

A document produced by Pratap Lakshman, JScript team, Microsoft. It details JScript style conditional compilation. (For the sake of developerkind, let’s not implement this in other engines… Sure, it’s not a bad idea, except for the fact that there’s scripts out there that equate @cc_on with Internet Explorer.)

Opinions, arguments, rebuttals, accusations

ECMAScript 3 and beyond

By Pratap Lakshman, JScript team, Microsoft. A rather uninteresting post by itself, advocating making ECMAScript (all browser implementations) more interoperable. I just hope Microsoft acts on this, because most of the time they are the one out of four that behave nonsensically. Also, for most of these the only code that relies on the JScript bugs is the workarounds we have for this problem, notably in library writing. Some of the comments might be of interest, too.

Bug Fixes in JavaScript 2

By John Resign, of jQuery fame. This summarises the few compatibility related changes that ES4 actually does to ES3. Proposed changes that were deemed to hurt too much currently live code have already been killed. And that, my friends, is not entirely good news. Some of those bugs being squashed would have made the language better. Still, compatibility with ES3 code live today is of paramount importance, especially for minority browsers such as Opera and Mozilla.

What I think about ES4.

By Chris Wilson, Platform Architect of the Internet Explorer Platform team at Microsoft. He argues about what should be important in developing the next generation of ECMAScript. One think he’s arguing for is to evolve ECMAScript in place. I’d argue that what ES4 as it looks right now does is just this. TG1 has done very little in the manner of changes that affect compatibility. In other words, an ES4 engine can run ES3 with little or no changes. Can an ES3 engine be modified to run ES4 code, in other words, can a present engine be expanded to encompass the new concepts? Well, depending on decisions made in the architectural design of the engine it may be more or less hard, so it’s hard to say. I think he’s wrong when he claims ES4 is a “different-in-character-language” from ES3 – I don’t think an ES4 engine has to make more than a minimal amount of implementation choices that would decrease the performance compared to a modern well-tuned ES3 engine. As for the ScreamingMonkey argument, it’s not much different from what Microsoft themselves do already with VBScript and JScript. On the other hand ScreamingMonkey IS a worse choice than Microsoft producing one engine that can run all script, ES4+E4X, ES4, ES3+E4X, ES3, ES3+CC in the same runtime.

However, ScreamingMonkey is under way. Say Adobe decides on distributing it with Flash, and install it so that it takes over all ECMAScript handling – now Microsoft would find themselves in the unpleasant position of not owning (in the “having control over” sense) the major script engine on their browser platform. Tell me Chris, is that a situation you’d like to find yourself in?

ECMAScript 4, the fourth system syndrome

By Gabriele Renzi. An argument about ES4 being a rewrite of a small clean system into a huge complex leviathan. I don’t quite agree, because I think things fall into necessary “bucket categories”. The type system, for instance. It’s better to add all of the type system together, even that includes many concepts, than to add just a few typing concepts, then some more, etc. The benefit is that you get a system that is well put together and doesn’t feel as much of a kludge as if you added one aspect of the type system, then grafted another aspect onto that, and so on. Another bucket category is the cleaning-up-the-shared-global-namespace-mess bucket consisting of block scoping constructs, namespaces, program units and packages. All of these systems have as one of their primary purpose to keep the global namespace from being contaminated too much, and also for making code more local and safer from other, malicious code.

Another point I would argue against is that ES3 is successful because it’s a simple language. In fact, I think the biggest single factor, probably the only really relevant factor, is that Netscape had a monopoly and supported only JavaScript. VBScript failed to replace it because it didn’t run on Netscape. So when IE did get monopoly, the language choice was already made. It’s a victory of being the first and virtually only contestant to the game. Now making itself as a language outside of the Browser, notably in Flash, that is due to a certain elegance factor.

JavaScript 2: Everything but the Kitchen Sink

By Bob Myers. Brendan Eich’s replies in the comments should be read by anyone wanting to argue either side of the complexity issue.

TAE: Day 3 – Ajax Futures Q and A

By Kris Gray. A transcript, contains some comments but Douglas Crockford that I’d like to argue with. First of all, adding types isn’t for the web specifically. It’s for making it easier to reason about code, to verify what you program, and for giving better performance at a lower price for the precompiled uses (Flash, JScript.NET, widgets, the application scene). And yes, while eval and with are big performance hits for all code (can be optimised away if you can stand having a more complex compiler, which the web frankly cannot due to responsivity problems) they cannot be removed in ES4 for compatibility reasons, and at least eval serve a function that can’t really be replaced, at least not without adding a macro system. Oh, and to expand on Douglas’s positing of two camps, “Adobe, Mozilla, Yahoo and Microsoft. The first to support it, the later two oppose it.”, that is simply not the way it looked. The voting was, as has been explained on the mailing list, eight persons from four companies (Adobe, Opera, Mozilla, MBedThis) and two universities (UC Santa Cruz, Northeastern University) in favour and three persons from two companies (Microsoft, Yahoo!) against. As I understand it, Opera in particular have had much to do with how the language looks, pushing for constructing the additional features in such a way that it can be compiled with very small compilers on low processing power devices with minimal space and time consumption.

ECMAScript4, the Language of the Web

By Robert Sayre. An answer to a particular claim by Douglas Crockford in the transcript linked above.

ECMAScript 4 overview paper

By Chris Double. A thread on Lambda the Ultimate with interesting and for some aspects very illuminating comments. Give it a read.

Nabble – Mozilla – ECMAScript 4 discussion

An archive of the es4-discuss mailing list. Look particularly at the threads Fwd: [TLUG]: ECMAScript (“Javascript”) Version 4 – FALSE ALARM by Scott Elcomb, and Re: Es4-discuss Digest, Vol 8, Issue 44 by Douglas Crockford

Es4-discuss — Discussion of ECMAScript 4

The mailing list itself, for those of you that want to subscribe. The archives are kept by month, so I find the Nabble archives easier to navigate as discussions can cross the month borders, for linking to non-list-members.

Posted in Javascript |

You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.