4 ms·

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 m

by azakai 13y ago

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 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.

mhd 13y ago
As an alternative, just working on/sponsoring/begging for an asm.js target might be enough to equalize performance.
- azakai 13y ago
  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.
  - mistercow 13y ago
    I think we can be fairly sure that targeting asm.js would degrade performance for a language like Dart.
    - azakai 13y ago
      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.
lttlrck 13y ago
It was the same story with javascript.
- azakai 13y ago
  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 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.
georgemcbay 13y ago
"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.
- azakai 13y ago
  That's correct, but see my response at https://news.ycombinator.com/item?id=6736764 https://news.ycombinator.com/item?id=6736764 - that was 18 years ago, the industry has changed a lot since then.
- cwp 13y ago
  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.
  - azakai 13y ago
    What specifically do you refer to?
  - ahoge 13y ago
    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_in_JavaScript/1.7 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_in_JavaScript/1.8 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.
    - azakai 13y ago
      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 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_function_syntax 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/ 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.
rdtsc 13y ago
> 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
- azakai 13y ago
  > 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.
  - 13y ago

by azakai 13y ago

mhd 13y ago

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

azakai 13y ago
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.
- mistercow 13y ago
  I think we can be fairly sure that targeting asm.js would degrade performance for a language like Dart.
  - azakai 13y ago
    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.

lttlrck 13y ago

It was the same story with javascript.

azakai 13y ago
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 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.

georgemcbay 13y ago

"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.

azakai 13y ago
That's correct, but see my response at https://news.ycombinator.com/item?id=6736764 https://news.ycombinator.com/item?id=6736764 - that was 18 years ago, the industry has changed a lot since then.
cwp 13y ago
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.
- azakai 13y ago
  What specifically do you refer to?
- ahoge 13y ago
  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_in_JavaScript/1.7 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_in_JavaScript/1.8 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.
  - azakai 13y ago
    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 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_function_syntax 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/ 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.

rdtsc 13y ago

> 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

azakai 13y ago
> 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.
- 13y ago