So in a way I guess I should be interested in JS2. And to whatever extent JS2 is better than JS1, then the web benefits. I guess. I don't really know though, because I haven't even so much as glanced at a spec. People whose opinion I respect think it's an improvement, but like I said, I don't care. Why?
Because I think JS2 has something in common with XSLT: they're both painstakingly-crafted, elegant solutions to completely the wrong problem.
Why, exactly, are we betting the future of the web on just another programming language? If the past 40 years of computer science have taught us anything, it's that the industry never -- never -- agrees on a single programming language. ForTran, COBOL, C, Java... things change. So why does anyone think that this time around it's going to be any different?
This is the same issue I have with XSLT. The need there is for a standardized way to transform XML from one format to another -- okay, fine, that's definitely a real need. But what is XSLT, if not machine readable instructions for performing a specific task? And hey guess what -- we have lots of different things we can use to encode machine-readable instructions; we call them programming languages, and they have a rich and varied history. In the silly days of my professional youth, I once devised a system where you basically wrote little scripts in an XML syntax, and I got rightly bonked on the head for it. It's not any better an idea for XSLT, either.
That said, for what it is XSLT is pretty well done; it's just that it's a well-done solution to the wrong problem. XSLT is a tightly-coupled solution to the problem; a loose-coupled solution that focused on defining a sort of "CGI for XML transforms" would -- in my opinion -- have been a better idea. Specify the boundaries, and let existing languages do what they're good at.
The web works as a platform because it embodies an effective application model implemented via open standards. But it's getting long in the tooth, which is why we have at least 3 different platforms aiming to replace it: AIR, Silverlight, and JavaFX. Each of these is basically some permutation in the cartesian product of (Vector-renderer, DOM-renderer) * (custom VM, custom language). The thing is, the browser of today is itself one permutation, and JS2 boils down to yet another.
We've already proven the model, folks. We don't need to prove it all over again.
The browser isn't broken, and doesn't need to be "fixed", either by a proprietary platform, or by a shiny new language. Instead it needs to be extended, and functionality gaps need to be plugged. That's why I don't care about JS2: its fundamental message is "the Browser of Tomorrow is the Browser of Today, just with different syntax." This is spinning our wheels, and won't do anything to advance the web.
So what is the right solution? Well, in my opinion what we need is to formalize and standardize the DOM API, agree on a single vector model and API, and specify an intermediate compilation format. That is, specify the boundaries, and let existing languages do what they're good at.
With one of these approaches, the browser -- through incremental steps -- becomes just as "innovative" as SilvAIRLaslavaFX, while still based on the open standards that have worked so well so far. This is basically the same pragmatic gap-filling philosophy that Gears and HTML5 have, though taken a step farther.
The problem is that this is messy work, and it's far less sexy than designing your own language or busting out with your own runtime out of whole cloth. It feels less innovative, because it's less of a dramatic change. But as DOM, CSS, and XMLHTTPRequest have proven repeatedly, it's the modest, targeted innovations in the web that have caused the biggest revolutions.