And also: ”Developers using Dash tooling will be able to use a cross-compiler to target Javascript for browsers that do not support Dash natively.”

Not very different to having native support for e.g. CoffeScript in browser X and supporting other browsers via JS.

Of course the main issue is that this is yet another language. Since all browsers are essentially becoming poor man’s virtual machines, why not drop the pretense and adapt some kind of bytecode instead. There’s JVM/CLR/LLVM/NaCL — just pick one already! Alas, politics (Oracle/Microsoft/Apple/Google).

Well anyway, Dash is a very positive news nevertheless. The biggest issue with current cross-compilers (GWT, Pyjamas, Haxe etc.) is that they lack good tools to develop and debug. Having support for those natively, there’s hardly any reason to target JS directly anymore. And once Chromium has the infrastructure to support more than one language, it’s possible that the abstractions will be general enough to add support for other languages as well.

“Our approach is to make an absolutely fantastic VM/Language and development environment and build great apps that fully leverage it in order to help other browsers see the wisdom in following. Once Dash has had a chance to prove its stability and feasibility, we are committed to making Dash an open standard with involvement from the broader web community.”

Mainly browser-vendor politics - MS/Apple/Opera/Mozilla. A proper runtime would weaken their chokehold over the Web client. It's almost certainly not a coincidence that the one major browser vendor which does support a VM is the one which is mainly interested in the Web client as a platform for its applications. Of the other four, two have strong interests in holding back the Web as an alternative to OS-native applications, while the remaining two are more or less nothing without their position of power over Web standards.

I can't figure out what you're implying. Why would the two organizations that are "more or less nothing without their position of power over Web standards" be opposed to making the Web better able to compete with native apps? After all, if the Web loses to iOS and Android, then Opera and Mozilla become irrelevant.

The reason why Opera and Mozilla oppose bytecode standards is that they genuinely think they're a bad idea. I mean, we tried that once; it was called Java. It lost to JavaScript.

Java (in the browser) was a plugin that was mostly completely sandboxed from the real page DOM with its own entirely separate (and very poorly designed -- AWT was horrendous) attempt at a UI layer. That's the problem it had, not the fact that it was a byte-code based VM.

Make the byte-code VM a first class citizen and things are completely different.

Even having the option to load a single JVM instance and share it between different frames/pages/tabs would be a tremendous improvement over current situation. At the present, the best you could do is to fake it using inter-frame communication (and some heuristic to elect most-likely to live longest), which is only slightly less bad.

NaCl is LLVM, bby the way. Portable NaCl is really cool though - it's an intermediary LLVM bytecode that's cross platform.

The next version of NaCl, called PNaCl, will be LLVM. Right now it's all native code (x86, x64, or ARM).

Just wondering, how do you know it's going to be the next version?

It's already under development. Here's the (perhaps optimistic) roadmap: http://www.chromium.org/nativeclient/pnacl/release-roadmap

I'm not sure what you mean by Haxe debugging. That happens with whatever run time debugger you have for js, php, etc. As far as development goes, there's flashdevelop, an eclipse plugin, a few textmate bundles, a vim package, etc. http://haxe.org/com/ide

If you don't mind me asking, what part of debugging/development in haxe turned you off?

I’m not familiar with haXe all that well, just enough to include it in the list. However, in the end haXe is too, statically translated into Javascript. GWT has an excellent debugger as well, but there’s only so much you can do on that level of indirection.

"Just debug the machine-generated code instead" is not really an answer.

You can say whatever you want until you've squandered the public good will, and then the public will skeptically peruse even the most innocuous of words coming from your mouth.

People's skepticism of Microsoft is based on what they (MS) have done in the past.

Indeed. Especially worrying for me was this phrase which appeared a few times:

> Developers who can focus solely on Chrome can [..] Developers focusing on all browsers will have to [..]

This seems to imply that Chrome is the preferable target: If developers can focus soley on Chrome, they should. Or if they must target all browsers, which is less desirable in the viewpoint here, then there is some tier-two option.

Scary stuff for anyone who cares about the open web.

They mean that you can use Chromium as your primary target — your development stack — and their cross-compiler will take care of supporting legacy/incompatible targets. This is just like GWT does now and it seems the technology (apart from VM, grammar and debugger) will build on the existing codebase of GWT and the Closure compiler.

> What happened to JSPrime?

> The JSPrime effort was begun to unify and be a (single!) successor to GWT and Closure/JSCompiler, suitable for large-scale development inside and outside Google, including being amenable to IDE-like tools and static compiler optimizations. The JSPrime team is happily folding its efforts into Dash now that everyone agrees Dash will explicitly include the same goals.

Don't be ridiculous. The entire spec is to be open source. This is nothing like Internet Explorer. If Internet Explorer played this nice when it wanted to innovate (AJAX) from the beginning it would probably still be relevant. Is Mozilla the only corporation allowed to create new web features now?

This backwards compatible approach isn't exactly Google's idea and it's a good one. Having a backwards compatible, faster, and more sane web language is going to improve developing the open web. Why should anyone be scared?

This is exactly as open as Android. The language is developed entirely in secret, and code is dumped into a repository on the day of a big announcement. Google's preferred partners (in this case, Chrome) get to see the source before the public does.

Quibbling about whether this qualifies as "open" or not is arguing semantics, but I think recent history has shown that the Android model doesn't lead to the openness that its proponents had suggested it would.

I agree completely. The developing stuff in secret and play fast and loose with the definition of open source works fine with their own platform. The Web is everyone's platform. I find it a tad insulting to be blocked off of the process and then be told that the Elite Engineers of Google have solved this problem for us.

There doesn't have to be an exact parallel between this and ActiveX for this to be bad. Mozilla announced about a month ago that they would be developing a not-yet-cross-platform set of APIs called WebAPI. Except they invited any one to participate. I'm subscribed to their mailing list and actively participating. I can submit patches if I so choose. Dash sounds like an almost-finished product that the rest of the community has to either adopt or opt-out of.

This point might be valid in general, but it can't apply to programming languages. There is no way to do language design in a committee (one might have a shot at enhancing an existing language, but it's difficult).

There's a difference between (a) doing some language design work in private and (b) doing an entire language spec, as well as all the implementation, in secret, then one day shipping it to users and telling everyone else "here's how it is, now standardize this".

I'd also argue that languages on the Web should be held to a different standard than general-purpose languages, since there are five primary players and the Web as a whole will be worse off if some of the browsers refuse to implement what other browsers are pushing.

Just because it is open doesn't mean the other browsers will, or should, implement it. NaCl will never see the light of day in other browsers even though it is entirely open-source.

Until NaCl, Dash, and whatever other stuff they decide to shove into Chrome, makes it into a standards body and is recommended by WHATWG & W3C, it is an attack on the Open Web.

Don't put stuff in a browser that isn't web standards compliant, I thought we already learned that lesson?

How did we learn that lesson when Microsoft did exactly what you're describing when they created XHR, and now almost every website uses it? It took 6 years for it to become standard, and I almost doubt it would have if it wasn't already in every browser by the time it did. My personal opinion is that this type of behavior boosts competition and helps innovation. If it's something clearly useful others will implement it or become obsolete. Waiting for a committee to standardize a feature before implementing it sounds like it would slow the web down to a halt. Mind you I already consider it to be painfully slow just looking at how many years it took to get 20-30 new functions into JS runtimes.

I think it's more practical for browser vendors to develop ideas (in the open, not like Dash) and use vendor prefixes (-o, -moz, etc.) and then bring those ideas to the standards bodies. We've seen this a lot recently, particularly with mobile. meta viewport tag was not brought to standards bodies first, Apple developed it and everyone else adopted it. To my knowledge it's still not part of WHATWG, although I'm sure it eventually will be.

There are some examples that can convincingly target Chrome only, e.g. Chrome extensions

"cyclone of innovation"? Sigh.

But it seems like an attempt to supersede JS with something significantly better before JS becomes further entrenched as the dominant language for nearly everything (slight exaggeration of what lots of people are saying) is worthwhile.

I wonder what Google's internal prediction markets (if they still have those) says about chances of success.

Didn't you see Brad Abrams' name on that list? After all, the more things change...

And yeah, I agree: it felt exactly like reading an internal MS memo...but ballsier.

And Peter Hallam, original J#/C# compiler dev lead, IIRC.

It's like an ex-MSFT .NET party over there!

I did not know that. Hilarious :)

From the Executive Summary: "Push for Dash to become an open standard and be adopted by other browsers."

I think the "Don't be evil" factor is well represented on that sentence.

It's clear that adoption by other browsers is a prerequisite for really being able to use this, unless Chrome manages to corner the browser market.

It's clear that other browsers won't adopt something like this without an open standard.

So this is not "don't be evil" but simple pragmatics.

"Don't be evil" would involve doing something other than presenting a fait accompli to a standards body and asking for a rubberstamp.

> Lars has promised to “sweet talk” the other browser vendors

Sweet talking is no evil!

America fuck yeah! Literacy is for faggots!

Don't try to associate literacy with douchebaggery.