Just waiting for "Works best on Chrome"
Silverlight and ActiveX have already shown the usefulness of proprietary enhancements.
No thanks.
Silverlight and ActiveX have already shown the usefulness of proprietary enhancements.
No thanks.
Browser vendors are free to integrate the VM into their products, and if they don't want to there is dart2js which is acceptable.
This isn't even close to the situation presented by Silverlight, ActiveX and I feel like you're being duplicitous by comparing them.
That's a tremendous amount of effort and it is likely to reduce the performance of JavaScript. Cross-language GC, in particular, is really hard. See Filip Pizlo's message to webkit-dev on this subject (citing two recent papers), which is part of the reason that Dart support was shot down when Google proposed adding it to WebKit: https://lists.webkit.org/pipermail/webkit-dev/2011-December/...
The Dart VM is nice but its primary purpose right now is running the Dart compiler and in Dartium which is only used by developers. (You can use it for other things but the ecosystem isn't there yet.)
This is a really good reason why dart2js exists and why so much effort has been expended in making it good.
However, I think that if Dart proves to be a compelling platform for developers I don't think it's out of the question for browser vendors to put some serious thought into integrating the Dart VM natively alongside JS.
After all, Google is going to be doing exactly that with Chrome/Chromium...
No they aren't. Integrating a Google-controlled VM into any software project (for example, Firefox) isn't trivial (you need lots of resources for it) nor is desirable (the technology is driven and controlled by Google).
Google being the ONLY committers don't exactly have a motivation to.
Dartium and dart2js already aren't quite in sync; numeric types work differently for example. But they're close enough that for most apps, you can develop in Dartium and deploy on dart2js and the language differences don't really bother you. The language differences between Dart-in-JavaScript and Dart-in-Dartium are a lot less than the differences between browsers that web developers deal with all the time.
So, yeah, Google has a motivation to keep it up to date.
And, then, sure, Dart2JS stops being important to Google because its unimportant to how Dart code performs on the web. But its unimportant to Google because its unimportant to anyone, since it won't matter to users, either.
We've seen that game before, played by microsoft.
Other browser vendors know this: Dart is never gonna fly outside of Google's walled garden.
Can't wait. I am already using Chrome, if it works best I'll like it even more.
> Silverlight and ActiveX have already shown the usefulness of proprietary enhancements.
So how do I compile Silverlight to .js again?
> No thanks.
Yes please!
Oh, and by the way, ActiveX would be awesome if it didn't have all the security flaws and was more portable. Too bad it didn't work.
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.
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
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.
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.
Which is... exactly the same situation JavaScript was in when Netscape introduced it.
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
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.
> 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.
(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.
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.
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?
However, I think it would be fun to explore that direction! I'd be happy to collaborate with Dart VM people on that.
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.
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.