Hacker News Reader

Comment by azakai | Hacker News Reader

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.

View on HN

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

Reply on news.ycombinator.com