Hacker News Reader

Comment by azakai | Hacker News Reader

There are at least two problems with adding the Dart VM:

1. Standards. The Dart VM is not part of any web standard, nor part of a spec that has interest from multiple vendors, so it should not be shipped in a standards-compliant browser. This is a matter of principle that most browsers agree on these days, see for example Google's Blink guidelines: http://www.chromium.org/blink#new-features

2. Effort. Adding a new VM into a browser is a huge amount of effort. The VM can't just be added even if it is open source (which it is) - it's very hard to integrate such a thing properly into a browser, technically speaking. Also aside from technical effort, there is also effort to start a new standards process for a new language.

View on HN

> 1. Standards. The Dart VM is not part of any web standard

I can see how many would see that as tail wagging the dog. But I see your point. And I agree it should be part of a standard. However I would imagine (and correct me if I am wrong) it is a lot easier to approve and go through the standard approval if there is already an implementation out there to look at. Standardizing on a hypothetical future feature via a large committee, doesn't work too well.

> 2. Effort.

Here, again, this is not a hypothetical, we haven't proven if it is possible we are just dreaming about adding a VM. Dartium works today. Presumably other would have a bit less work to do but it depends on how DOM interaction differs between them.

EDIT: 2nd part initially completely didn't make sense

> However I would imagine (and correct me if I am wrong) it is a lot easier to approve and go through the standard approval if there is already an implementation out there to look at.

I think you are correct. But that implementation does not need to be shipping on by default in a major browser like Chrome.

If Google would promote Dart mainly through dart2js, but not ship the Dart VM in Chrome, then I have no problem with that, and even the opposite - that would be quite cool, new languages are always nice to have. Then, if Dart catches on with developers in the industry, I think it would be very appropriate to discuss standardizing it. The momentum among developers, plus an existing VM that runs it even better, could be a compelling combination, and browser vendors could discuss that in a fair and open way.

But to ship the VM in Chrome far before any of that is a violation of the basic principles of the standards process. It sends the message that Google intends to use Chrome's huge and growing market share to force the market to do what it wants, instead of following the standards process. Perhaps that is not what Google intends, but that is how it can appear.

For that reason, I think that shipping the VM in Chrome is counterproductive if Google wants to standardize it, since it antagonizes all the rest of the industry.

> But it is also not vaporware.

Sorry if I wasn't clear, I never said anything to the contrary? Not sure what you are responding to here - the quote you refer to is about "Effort", where I talked about the effort for other browser vendors to adopt the Dart VM, not for Google. Clearly Google has a working VM today.

> But it is also not vaporware. Sorry if I wasn't clear,

Sorry for the confusion, I read that somehow as effect on Google's part to integrate the browser in Chrome in order to have an example of it running to speed up the approval process. I see how it was a total brain fart on my part. Disregard that one. I updated it with actually what I think I was saying.

"The Dart VM is not part of any web standard, nor part of a spec that has interest from multiple vendors"

Which is... exactly the same situation JavaScript was in when Netscape introduced it.

Which is exactly the same situation that Javascript is in now. The Javascript VM in Firefox has features that are not part of any web standard, nor part of a spec that has interest from multiple vendors.

Yea, Firefox 2.0+ is shipped with support for generators/iterators, array comprehension, let, and destructuring assignment:

https://developer.mozilla.org/en-US/docs/Web/JavaScript/New_...

Firefox 3.0+ added support for expression closures and generator expressions:

https://developer.mozilla.org/en-US/docs/Web/JavaScript/New_...

Firefox 22+ supports fat arrow functions. Just open the console and try it yourself:

  >>> let z = x => x * x;
  undefined
  >>> z(5);
  25
  >>> let y = (a, b) => a * b;
  undefined
  >>> y(2, 3)
  6

None of these features are standardized yet.

There is a spec and discussion in the standards bodies for all of those AFAIK. For example for let,

http://wiki.ecmascript.org/doku.php?id=harmony:let

Arrow functions are being standardized as well,

http://wiki.ecmascript.org/doku.php?id=harmony:arrow_functio...

and for generators, the standards discussion led to a change in the spec, with the new version replacing the old implementation in SpiderMonkey (v8 recently implemented the new one as well).

In general see

http://kangax.github.io/es5-compat-table/es6/

where it lists compatibility for various new JS features. As it says there, let is supported not just in Firefox but also IE11 and Chrome 30.

It is true that Firefox shipped some of these several years back. I am not sure of the best way to find out exactly what the standards-track status was at those times.

But in general: Talking about the far past is counterproductive. We can probably find stuff that wasn't done properly by any browser if we look back far enough. But in recent years, there is growing consensus on the importance of not shipping non-standard things. That is the important thing I think.

Unfortunately, though, this kind of goes against your argument which I understand to be "how dare Google release something that is not standards based". I agree principle with that, _but_ in this case a few posts did show example of technologies that all browser vendors introduces that were outside the spec.

> But in recent years, there is growing consensus on the importance of not shipping non-standard things.

Others might read that as no new and meaningful technologies will be seen implemented in the browsers soon. I can't think of too many thing designed and build by an intercompany commetee.

I don't follow, why does it go against that line of argument? If someone else did something bad in the past, it doesn't excuse doing something bad in the present.

(And as mentioned above, I'm not sure about those examples - while it's very possible some were released before being standardized, I didn't see a link showing that, and they are all being standardized now. Need more info.)

Fair point about the limits of things designed by committees. But it isn't always true, just mostly true ;) For example, WebGL was designed through a standards process, and it is great.

> If someone else did something bad in the past [...]

Earlier you mentioned "far past", but this stuff is fairly recent:

Firefox 2 - October 24, 2006

Firefox 3 - June 17, 2008

Firefox 22 - June 25, 2013

> while it's very possible some were released before being standardized

Nothing of this is in ES5.1.

> they are all being standardized now

Yes, just like Dart.

> For example, WebGL was designed through a standards process, and it is great.

No, that's not how it happened. [1]

Experiment by Mozilla - 2006

Implementations by Mozilla and Opera - 2007

WebGL Working Group - 2009

1.0 spec - 2011

And all of this is based on Canvas which is something Apple made up.

Anyhow, you seem to think that this kind of thing is a problem. It's not. This is how the web works. This is how progress is made.

[1] http://en.wikipedia.org/wiki/WebGL#History

I consider 2008 to be far past :)

Regarding Firefox 22, that is recent, but I don't see a link showing it shipped something nonstandard and that was not being standardized? In fact I showed a link for the standardization process for arrows? Revision history for that page seems to show that it predates Firefox 22.

> Nothing of this is in ES5.1.

They are in ES6, which is being standardized, has interest from multiple vendors, is heavily discussed by multiple vendors, and has implementations by multiple vendors.

I never said everyone should wait until a standard is 100% final. Just like the Blink principles say, it can be perfectly valid to ship something that is being standardized, so long as there is interest from multiple vendors and work on standardization.

The risk is of one vendor shipping something entirely unilaterally, with no respect for any standards process. That's not what happened with arrows.

> > they are all being standardized now

> Yes, just like Dart.

AFAIK no other vendor has expressed any interest in Dart. The opposite in fact, Apple opposed including bindings to WebKit that would allow additional languages to JS. Please correct me if I am wrong?

> Anyhow, you seem to think that this kind of thing is a problem. It's not. This is how the web works. This is how progress is made.

I disagree. Why then do you think Google wrote the Blink principles about avoiding shipping something before it is standardized or has multiple vendor interest? Why did Google stop shipping vendor-specific WebGL extensions? In both cases Google is showing what most vendors consider proper behavior today, and I think Google is doing the right thing. Do you think Google is wrong in both cases?

And Firefox actively _removes_ these features. For example, sharp variables were removed in Firefox 12, E4X was removed in Firefox 20.

What specifically do you refer to?

That's correct, but see my response at https://news.ycombinator.com/item?id=6736764 - that was 18 years ago, the industry has changed a lot since then.

As an alternative, just working on/sponsoring/begging for an asm.js target might be enough to equalize performance.

Not sure asm.js would make sense for something like Dart, since it is mainly intended for things like C and C++ (Dart is a dynamic language, and needs different forms of optimization).

However, I think it would be fun to explore that direction! I'd be happy to collaborate with Dart VM people on that.

I think we can be fairly sure that targeting asm.js would degrade performance for a language like Dart.

I suspect you might be right, but I am far from certain - can you elaborate?

My concerns are about things like PICs, but code generation is possible, so replacing functions to change PICs is one way to implement them. This is, I think, how the Graal project does JavaScript and Ruby, and they get very good performance.

It was the same story with javascript.

That's a fair point in that yes, JavaScript was nonstandard when it was first included in a web browser.

But it is an incorrect point in that the field has changed a lot, for the better - most or all browser vendors want to play nicely these days. Even Microsoft is supporting the standards process and implementing WebGL, for example. The principles guiding browser vendors are more like these which Google wrote for Blink:

http://www.chromium.org/blink#new-features

> In practice, we strive to ensure that the features we ship by default have open standards.

That was not the case 18 years ago, but thankfully it is today. 18 years ago it might have been common practice to just ship a new VM in a browser, but to do so today with no regards for the standards process would be unexpected and improper.

Reply on news.ycombinator.com