Dart Lang 1.2 Released(dartlang.org)
dartlang.org
Dart Lang 1.2 Released
https://www.dartlang.org/
9 comments
Working on a project that I kind of want to use the same language for the frontend and the backend. There's, obviously, vanilla JS, maybe clojure and clojurescript, but Dart...
For some reason I never realized it could be used server side. Anyone have any practical experience with an app built entirely in Dart?
For some reason I never realized it could be used server side. Anyone have any practical experience with an app built entirely in Dart?
It works. There are a few people using it server side. There is a Heroku build pack. The HTTP server is a bit slow, sounds like this is being addressed, and shouldn't be a limiting factor. I wrote a postgresql driver, which works ok. More users, issues filed and patches are always welcome ;)
Now if meteorjs does Dart too... one language to rule them all
Politics aside, I find it interesting Dart isn't getting much traction at this point. It seems it should be in a similar position to Java during the first wave, but it clearly isn't.
By itself it's clearly not bad, it's just not better enough than what is there already to suffer the inter-ecosystem pain with native JS. Since it can't do anything JS can't the only selling point it really has is to build large JS systems in some other safer language, but we've been there before with GWT, and that didn't set the world on fire either.
By itself it's clearly not bad, it's just not better enough than what is there already to suffer the inter-ecosystem pain with native JS. Since it can't do anything JS can't the only selling point it really has is to build large JS systems in some other safer language, but we've been there before with GWT, and that didn't set the world on fire either.
Java (Vs. Visual C++) had the industry and Academia trying to break free from Microsoft's grip by going cross-platform and later in-browser.
Dart just doesn't have that kind of driving force going for it.
Dart just doesn't have that kind of driving force going for it.
True, I had missed that.
Maybe it's that environments mean much more than languages, and with Java the JVM was the killer thing which dragged the language with it. Spark might be that killer platform for Dart, but it strikes me as wishful thinking, especially with players like github coming into that side of the market.
Maybe it's that environments mean much more than languages, and with Java the JVM was the killer thing which dragged the language with it. Spark might be that killer platform for Dart, but it strikes me as wishful thinking, especially with players like github coming into that side of the market.
I think it's still early days. There are large projects underway in Dart, like Spark. Once an app that everyone is using is written in Dart, I think it will spur further adoption. With that said, there has been clear growth - as an outsider not on the team, to me that growth looks linear rather than exponential, but it's steady and clearly there. Of course inclusion in Chrome or Android will mean sudden exponential growth perhaps.
I've been working on a Dart project (http://frontiermap.s3-website-us-east-1.amazonaws.com/) with StageXL, a Dart transcription of ActionScript's library: http://www.stagexl.org/
I've been meaning to write a blog post on my experience with Dart and StageXL, but as far as the Dart part of things, a few misc. observations:
* Dart shows a lot of influence from Java, and obviously some tinges of JS. I don't really care, I wanted a productive web language with optional static types.
* It is a "boring" language in that it's not doing anything new or earth-shattering syntactically or conceptually. This ended up being a positive to me, in that I was able to ramp up extremely quickly. I'm a Pythonista by trade, I know enough JS/CoffeeScript to get by, and I've got a little bit of Java experience.
* Dart comes with so many tools, to the point where I'm not constantly trying to find and piece together core components like "module" imports, package managers, unit test frameworks, documentation generators, IDE. Not all of the tools are extremely polished at this point (their package browsing/searching site is incredibly basic), but there is a clear "way" to do most things. There's nothing stopping anyone from writing alternatives to the official stuff, either.
* The Dart->JS interop is OK for simple usage cases, but can get a bit complex for others. This is my only big hangup for non-hobby projects. This will improve with time, but it's very clunky for now.
* Types don't have to be specified, but I have tended to provide them for everything. I really like being able to do this, even coming from a Python background.
* The Dart IDE is surprisingly helpful. Debugging is decent, and they've stripped a ton of the bloat out from its Eclipse underpinnings. It does crash a bit on Arch Linux with the latest Oracle Java, though. That said, I hope they get in with the IDEA guys like they did for Android.
* My particular project uses WebGL, and I'm compiling to JS. I have yet to run into any complications with the conversion, and the generated JS has worked well on my two mid-range dev machines (Linux and Mac OS 10.9 on Chrome and Firefox).
* The error messages shown during interpretation/compiling are helpful most of the time, but can get a little more cryptic in certain cases (I've yet to find a pattern, but there probably is). I expect this to improve with time.
Overall, I have been very pleased with Dart, and like it (as a langauge) a lot better than CoffeeScript. Optional types has been my favorite feature, and I really like how "batteries included" Dart is. I'm a backend guy, so I don't have the drive or mental bandwidth to go looking at the various packaging/importing/testing/doc utils in JS land (although that is a perfectly viable approach if you have the time and experience).
The ecosystem obviously can't be compared to JS, since Dart is in its infancy. It'll be good enough for some usage cases, but you may find yourself re-inventing things for others (or shoe-horning things in via the JS interop). For hobby projects, Dart is going to get the nod over the alternatives (Typescript, CoffeeScript, pure JS) until it burns me.
I've been meaning to write a blog post on my experience with Dart and StageXL, but as far as the Dart part of things, a few misc. observations:
* Dart shows a lot of influence from Java, and obviously some tinges of JS. I don't really care, I wanted a productive web language with optional static types.
* It is a "boring" language in that it's not doing anything new or earth-shattering syntactically or conceptually. This ended up being a positive to me, in that I was able to ramp up extremely quickly. I'm a Pythonista by trade, I know enough JS/CoffeeScript to get by, and I've got a little bit of Java experience.
* Dart comes with so many tools, to the point where I'm not constantly trying to find and piece together core components like "module" imports, package managers, unit test frameworks, documentation generators, IDE. Not all of the tools are extremely polished at this point (their package browsing/searching site is incredibly basic), but there is a clear "way" to do most things. There's nothing stopping anyone from writing alternatives to the official stuff, either.
* The Dart->JS interop is OK for simple usage cases, but can get a bit complex for others. This is my only big hangup for non-hobby projects. This will improve with time, but it's very clunky for now.
* Types don't have to be specified, but I have tended to provide them for everything. I really like being able to do this, even coming from a Python background.
* The Dart IDE is surprisingly helpful. Debugging is decent, and they've stripped a ton of the bloat out from its Eclipse underpinnings. It does crash a bit on Arch Linux with the latest Oracle Java, though. That said, I hope they get in with the IDEA guys like they did for Android.
* My particular project uses WebGL, and I'm compiling to JS. I have yet to run into any complications with the conversion, and the generated JS has worked well on my two mid-range dev machines (Linux and Mac OS 10.9 on Chrome and Firefox).
* The error messages shown during interpretation/compiling are helpful most of the time, but can get a little more cryptic in certain cases (I've yet to find a pattern, but there probably is). I expect this to improve with time.
Overall, I have been very pleased with Dart, and like it (as a langauge) a lot better than CoffeeScript. Optional types has been my favorite feature, and I really like how "batteries included" Dart is. I'm a backend guy, so I don't have the drive or mental bandwidth to go looking at the various packaging/importing/testing/doc utils in JS land (although that is a perfectly viable approach if you have the time and experience).
The ecosystem obviously can't be compared to JS, since Dart is in its infancy. It'll be good enough for some usage cases, but you may find yourself re-inventing things for others (or shoe-horning things in via the JS interop). For hobby projects, Dart is going to get the nod over the alternatives (Typescript, CoffeeScript, pure JS) until it burns me.
Have you used typescript to compare? It adds optional types and class based OO and that's it. It's used for large chunks of Windows 8, eg, xbox music is 100Kloc of typescript.
I do like dart's clean DOM API though.
I do like dart's clean DOM API though.
I haven't, but if it has most of the things I mentioned as things I liked, it'd likely be a capable substitution (for me). Dart is good enough for me, though. I really like their approach as a whole.
To be honest, if XBox Music needs to be implemented in 100k lines of a very high level language there's something very wrong going on.
You clearly don't know how complicated a music player + music store + music library manager can get. There's a bunch of stuff going on there between music codecs, library management, streaming music downloads, pulling id3/etc tags down from db servers, copying music to mobile devices, managing playlists...
I've written game delivery systems which were smaller, like 1/20th of the size.
You aren't exactly going to be writing the CODECs and DRM for XBox Music in TypeScript are you?
You aren't exactly going to be writing the CODECs and DRM for XBox Music in TypeScript are you?
Using it successfully on large team. Works great and plays well with all the existing JS libraries.
Haxe has all your pros and more... Static typing with type inference, OO, good tooling, good libraries, has JS externs for most big libraries and easy JS interoperability, IDEs with good tools (including a fantastic VIM plugin called Vaxe), etc...
And of course Haxe also has its own platform, or can compile to native code... Just saying.
Of course Dart has Dartium, which could one day be the future...
And of course Haxe also has its own platform, or can compile to native code... Just saying.
Of course Dart has Dartium, which could one day be the future...
> Haxe has all your pros and more...
Once again, I don't care. The OP was about a Dart release, and I was sharing my experience with Dart. Haxe doesn't interest me in the least, it's something entirely different for my usage case.
Once again, I don't care. The OP was about a Dart release, and I was sharing my experience with Dart. Haxe doesn't interest me in the least, it's something entirely different for my usage case.
What if anything makes Dart better than say ES6 or ES7 or whatever version of JavaScript that adds optional types, generators, etc...
Dart is usable now. ES6 has long been delayed, and who knows when ES7 will be available for mass usage.
There are lots of intro pages out there to get you a little more familiar with it [0][1][2]. Dart as a language spec isn't all that deep, and it tries to keep things simple and easy to use. A lot of the power I feel like comes from the library and tools that come with the language.
[0] http://programming.oreilly.com/2013/05/dart-is-not-the-langu...
[1] https://www.dartlang.org/docs/dart-up-and-running/contents/c...
[2] http://en.wikipedia.org/wiki/Dart_(programming_language)
There are lots of intro pages out there to get you a little more familiar with it [0][1][2]. Dart as a language spec isn't all that deep, and it tries to keep things simple and easy to use. A lot of the power I feel like comes from the library and tools that come with the language.
[0] http://programming.oreilly.com/2013/05/dart-is-not-the-langu...
[1] https://www.dartlang.org/docs/dart-up-and-running/contents/c...
[2] http://en.wikipedia.org/wiki/Dart_(programming_language)
To add a few more useful links. Language spec[0][1] is available under a free license and they welcome input on it[2]. The 3 top starred bugs in their bugtracker are: enums, non-nullable types, and "await" support [3], though I don't expect non-nullable types to ever be added, but they like hearing what is important to programmers. If there is really a killer language feature that people want, starring it will increase it's chances of being considered.
[0] https://www.dartlang.org/docs/spec/latest/dart-language-spec...
[1] https://code.google.com/p/dart/source/browse/trunk/dart/docs...
[2] http://news.dartlang.org/2014/02/standardizing-dart-1st-ecma...
[3] https://code.google.com/p/dart/issues/list?can=2&q=&sort=-st...
[0] https://www.dartlang.org/docs/spec/latest/dart-language-spec...
[1] https://code.google.com/p/dart/source/browse/trunk/dart/docs...
[2] http://news.dartlang.org/2014/02/standardizing-dart-1st-ecma...
[3] https://code.google.com/p/dart/issues/list?can=2&q=&sort=-st...
I don't really care about ES6 or ES7. The point of my comment wasn't to compare anything. I (subjectively) liked working with Dart. I did like the "batteries included" approach of Dart vs JS, but that's not really a language think so much as it is an ecosystem/leadership difference.
The best bit about Dart is not new features, but many of the footguns that have been removed compared to JS.
Note: Dart doesn't have generators, and Ecmascript is not planning on adding optional types.
Note: Dart doesn't have generators, and Ecmascript is not planning on adding optional types.
The designers got to mostly start from scratch (some things are there for JS compatibility) not only at the language level, but importantly also at the VM level. It's already ~ 2X faster than V8 and they believe there is room for more performance gains. Then add in all of the nice language features beyond classes and types and you have something worthwhile.
[deleted]
GWT is still a very good alternative if you are a Java shop.
I'd love to see dart going mainstream, but nobody would integrate VM, except google.
It doesn't matter. It compiles to JS and you still get a better language in which to develop large apps. The generated JS is probably faster because of the static analysis.
Of course it does. Extra abstraction that may cause pain in fixing nasty production bugs, can't use goodies from Dart jak SIMP etc. Logically it doesn't matter, but empirically that doesn't happen.
Integrating to client side is also just half of the story. It can also be the new node.js which didn't have to integrate with anyone.
Is pub.dartlang.org Dart's "CPAN"?
I don't know Dart, but it looks as if you need a Google account to upload packages to that central package repo. Is that correct?
I don't know Dart, but it looks as if you need a Google account to upload packages to that central package repo. Is that correct?
Comparing TypeScript to Dart, one is clearly much better.
Would you like to share the answer with the rest of the class?
My comment was for the people that tried both, not bait for the people that know one and not the other.
It's "Dart" not "Dart lang" just like it's "Go" not "Golang". Let's keep SEO out of common language.
Dart: Google's ActiveX
Dart is nothing like ActiveX. But apparently it is "cool" to invoke ActiveX for any browser technology you don't like.
ActiveX was a way of loading untrusted binaries in-process with the browser and running them unsandboxed.
Does Dart run untrusted machine code unsandboxed? No.
If Dart is Google's ActiveX, then JavaScript is Netscape's ActiveX, Java is Sun's ActiveX and Emscripten is Mozilla's ActiveX. (Note: none of these is actually true)
Comparisons to Silverlight or Flash would also be inaccurate, since neither can compile to JavaScript and both are closed-source technologies that are not on any path to being standardized.
ActiveX was a way of loading untrusted binaries in-process with the browser and running them unsandboxed.
Does Dart run untrusted machine code unsandboxed? No.
If Dart is Google's ActiveX, then JavaScript is Netscape's ActiveX, Java is Sun's ActiveX and Emscripten is Mozilla's ActiveX. (Note: none of these is actually true)
Comparisons to Silverlight or Flash would also be inaccurate, since neither can compile to JavaScript and both are closed-source technologies that are not on any path to being standardized.
It's safe to defend Dart to the point that your Gmail will run faster in Chrome that has Dart VM. Then Firefox and IE might fall behind in performing for Google web apps and then you will see how Dart will hurt web ecosystem.
I'm just guessing. So far Dart2JS is pretty close to native Dart.
I'm just guessing. So far Dart2JS is pretty close to native Dart.
To me this is like saying: "it's safe to defend Servo up to the point that it's faster single-threaded browser engines. Then Chrome and IE might fall behind in performing for web apps and then you will see how Servo will hurt the web ecosystem."
To be honest, I hope that Servo out-performs the current browser engines, and the that other browsers feel pressure to follow suit, because it will push the web forward as a whole. It's like SpiderMonkey and V8 did with JS performance five years ago.
Now you will probably say "but Dart is a new content type," and I see where you are coming from. But to me it's no different than asm.js. asm.js a new content type also, it just happens to be very clever and outputs programs which are a Polyglot (http://en.wikipedia.org/wiki/Polyglot_(computing)) of the new asm.js content type and regular JS. It is very cool how they have done this, but it doesn't change the fact that asm.js, when processed by an asm.js-aware compiler, is a different content type than regular JS and is processed in a different way that is intended to be faster than plain JS.
So to me, a putting Dart source file right next to Dart2JS output on the open web is no different than asm.js, and I think both are equally valid approaches to moving the web forward.
To be honest, I hope that Servo out-performs the current browser engines, and the that other browsers feel pressure to follow suit, because it will push the web forward as a whole. It's like SpiderMonkey and V8 did with JS performance five years ago.
Now you will probably say "but Dart is a new content type," and I see where you are coming from. But to me it's no different than asm.js. asm.js a new content type also, it just happens to be very clever and outputs programs which are a Polyglot (http://en.wikipedia.org/wiki/Polyglot_(computing)) of the new asm.js content type and regular JS. It is very cool how they have done this, but it doesn't change the fact that asm.js, when processed by an asm.js-aware compiler, is a different content type than regular JS and is processed in a different way that is intended to be faster than plain JS.
So to me, a putting Dart source file right next to Dart2JS output on the open web is no different than asm.js, and I think both are equally valid approaches to moving the web forward.
> So to me, a putting Dart source file right next to Dart2JS output on the open web is no different than asm.js, and I think both are equally valid approaches to moving the web forward.
I think this is potentially interesting comparison. Yes, both Dart and asm.js are tools that are involved with both generating content and executing that content (unlike your first example with servo, which is apples-to-oranges for the reason you mentioned).
But there are big differences here. With asm.js, it was a specific goal to make optimizing the code in other browsers as simple as possible. That was one of the main reasons for actually defining asm.js, so there is a clear "contract" - "this is what compiled C++ code looks like, these patterns are easy to optimize in obvious ways." That avoids the risk of there being anything special about generating code using emscripten and executing it in Firefox: the generated code is asm.js with the "contract" just mentioned.
For Dart there isn't anything comparable. dart2js emits JavaScript code, which runs in all browsers, but there is no reason to think it's performance is or will stay similar to the Dart VM. Instead, the Dart strategy there seems to be more along the lines of "the Dart VM is open source, if you want comparable performance to Chrome you can adopt that codebase." There is merit to that approach - it's much better than if Dart were closed source - but it is quite different than the one in the previous paragraph.
The second major difference is that while both Dart and asm.js relate to both content creation and execution, one is made by Google, which owns several of the most important sites on the web, whereas the other is made by Mozilla which obviously is nowhere near anything of the sort and not even trying to be.
Why this last point matters is that if the VM eventually becomes much faster than the dart2js path, Google can essentially force other browsers' hands by adopting Dart on Google sites. Imagine if google.com, gmail, google docs etc. all run much faster on the VM than otherwise - other browsers would be forced to adopt the VM to stay relevant. This is huge leverage that Google has. You can't be a browser that people use if you are not competitive on Google-owned properties.
Going back to the previous point, should that happen, adopting the VM might be the only option - there is no way, unlike with asm.js, to get similar performance otherwise (in the asm.js case, the high performance is achieved with a small modification to an existing JS engine, which could be done on other engines as well - no one needs to adopt SpiderMonkey). So this is the potential bad scenario that could happen due to both of these issues.
Obviously there are similarities between Dart and asm.js too, as you mentioned. But I believe the two factors I described explain much of the concern some people have about what Google's plans with Dart are. It might all end up ok, but Google might also leverage its huge influence in multiple areas for what is best for Google, and not for the web as a whole. There is no such risk with asm.js.
I think this is potentially interesting comparison. Yes, both Dart and asm.js are tools that are involved with both generating content and executing that content (unlike your first example with servo, which is apples-to-oranges for the reason you mentioned).
But there are big differences here. With asm.js, it was a specific goal to make optimizing the code in other browsers as simple as possible. That was one of the main reasons for actually defining asm.js, so there is a clear "contract" - "this is what compiled C++ code looks like, these patterns are easy to optimize in obvious ways." That avoids the risk of there being anything special about generating code using emscripten and executing it in Firefox: the generated code is asm.js with the "contract" just mentioned.
For Dart there isn't anything comparable. dart2js emits JavaScript code, which runs in all browsers, but there is no reason to think it's performance is or will stay similar to the Dart VM. Instead, the Dart strategy there seems to be more along the lines of "the Dart VM is open source, if you want comparable performance to Chrome you can adopt that codebase." There is merit to that approach - it's much better than if Dart were closed source - but it is quite different than the one in the previous paragraph.
The second major difference is that while both Dart and asm.js relate to both content creation and execution, one is made by Google, which owns several of the most important sites on the web, whereas the other is made by Mozilla which obviously is nowhere near anything of the sort and not even trying to be.
Why this last point matters is that if the VM eventually becomes much faster than the dart2js path, Google can essentially force other browsers' hands by adopting Dart on Google sites. Imagine if google.com, gmail, google docs etc. all run much faster on the VM than otherwise - other browsers would be forced to adopt the VM to stay relevant. This is huge leverage that Google has. You can't be a browser that people use if you are not competitive on Google-owned properties.
Going back to the previous point, should that happen, adopting the VM might be the only option - there is no way, unlike with asm.js, to get similar performance otherwise (in the asm.js case, the high performance is achieved with a small modification to an existing JS engine, which could be done on other engines as well - no one needs to adopt SpiderMonkey). So this is the potential bad scenario that could happen due to both of these issues.
Obviously there are similarities between Dart and asm.js too, as you mentioned. But I believe the two factors I described explain much of the concern some people have about what Google's plans with Dart are. It might all end up ok, but Google might also leverage its huge influence in multiple areas for what is best for Google, and not for the web as a whole. There is no such risk with asm.js.
I see where you are coming from, and I think this was a very well-reasoned argument.
In my opinion though, your argument prioritizes browser vendors over users, and over the competitiveness of the web vs. competing technologies like native apps.
Let's take your scenario, where somehow the Dart VM become becomes noticeably faster than Dart2JS on Google properties, to the point that users notice and get a better experience by using a browser with the Dart VM embedded.
First of all I'd mention that there is a natural competitive pressure that keeps Gmail and other Google properties "honest" so-to-speak. Chrome is far from being the only web browser, and if Gmail is perceived as being slow compared to other webmail websites, Gmail will suffer accordingly. Gmail has no incentive to cripple the speed of JS-only browsers; it has the incentive to make its app as fast as it possibly can on all major browsers.
So if hypothetical future Dart-Gmail is noticeably faster than JS Gmail, then it is likely for some fundamental reason of Dart being more optimizable, and not because of any lack of effort to make the JS version fast.
At this point, where the Dart version is faster for purely technical reasons, you say that "adopting the VM might be the only option" for other browsers. I would say first of all that it seems that there are other options, like compiling Dart to asm.js in a very peripheral part of the browser so that you wouldn't have to change your core execution VM. Given that the Dart VM is open source, this would be adding a new backend to an existing compiler (sort of like you did with Emscripten and LLVM), and not an effort comparable to developing a new compiler from scratch. It's true that this would require you to adopt some third-party code, but it would keep the Dart VM out of your browser, if not the Dart compiler.
But suppose that even that wasn't acceptable or feasible. Now the question is, is it better for (some) users to get the advantage of technology that has demonstrated that it is inherently faster, at the cost of other vendors being pressured into adopting this (standardized) technology, or is it better for all users to be equally disadvantaged, to keep the browser playing field more level?
As you surely know, browsers aren't just competing against each other, they are competing against other app platforms like native apps. If the web stays a little slower but all browser vendors are more equal, then the whole web is falling behind compared to the other, far less open and level, app platforms.
Now all of this discussion is quite premature until/unless Dart is actually distributed as part of Chrome, and the Dart VM is actually found to be noticeably faster than regular JavaScript, and Google actually uses Dart on its big properties.
In my opinion though, your argument prioritizes browser vendors over users, and over the competitiveness of the web vs. competing technologies like native apps.
Let's take your scenario, where somehow the Dart VM become becomes noticeably faster than Dart2JS on Google properties, to the point that users notice and get a better experience by using a browser with the Dart VM embedded.
First of all I'd mention that there is a natural competitive pressure that keeps Gmail and other Google properties "honest" so-to-speak. Chrome is far from being the only web browser, and if Gmail is perceived as being slow compared to other webmail websites, Gmail will suffer accordingly. Gmail has no incentive to cripple the speed of JS-only browsers; it has the incentive to make its app as fast as it possibly can on all major browsers.
So if hypothetical future Dart-Gmail is noticeably faster than JS Gmail, then it is likely for some fundamental reason of Dart being more optimizable, and not because of any lack of effort to make the JS version fast.
At this point, where the Dart version is faster for purely technical reasons, you say that "adopting the VM might be the only option" for other browsers. I would say first of all that it seems that there are other options, like compiling Dart to asm.js in a very peripheral part of the browser so that you wouldn't have to change your core execution VM. Given that the Dart VM is open source, this would be adding a new backend to an existing compiler (sort of like you did with Emscripten and LLVM), and not an effort comparable to developing a new compiler from scratch. It's true that this would require you to adopt some third-party code, but it would keep the Dart VM out of your browser, if not the Dart compiler.
But suppose that even that wasn't acceptable or feasible. Now the question is, is it better for (some) users to get the advantage of technology that has demonstrated that it is inherently faster, at the cost of other vendors being pressured into adopting this (standardized) technology, or is it better for all users to be equally disadvantaged, to keep the browser playing field more level?
As you surely know, browsers aren't just competing against each other, they are competing against other app platforms like native apps. If the web stays a little slower but all browser vendors are more equal, then the whole web is falling behind compared to the other, far less open and level, app platforms.
Now all of this discussion is quite premature until/unless Dart is actually distributed as part of Chrome, and the Dart VM is actually found to be noticeably faster than regular JavaScript, and Google actually uses Dart on its big properties.
Well, the Dart VM is not like adding a backend to a compiler or VM - it is a complete VM in itself.
For example, it has its own concepts of references etc., which means that if you add the Dart VM alongside your JS VM, you need to be able to collect cycles spanning those two.
That is not a trivial thing to do, and in fact Google has been working for a while on the Oilpan project to make Chromium capable of collecting such cycles, that span C++, v8 and the Dart VM. It's a huge engineering effort. Gecko can currently collect cycles between C++ and JS, but extending that is not trivial, and I believe Safari cannot collect such cycles and instead by design avoids creating such cycles - but that would not be possible with the Dart VM.
It might not be practical for other browsers to adopt such a technology. So if Google sites force the Dart VM to be necessary to compete, that would basically mean that the other browsers cannot compete. Then there would be just Chrome, a single implementation of a web browser, dominating the market like IE used to.
It might be good for users to have a single browser for a while, single implementations can move faster without regard for standards or openness. But lack of standardization and openness also means it is a proprietary platform, of which we already have many.
For example, it has its own concepts of references etc., which means that if you add the Dart VM alongside your JS VM, you need to be able to collect cycles spanning those two.
That is not a trivial thing to do, and in fact Google has been working for a while on the Oilpan project to make Chromium capable of collecting such cycles, that span C++, v8 and the Dart VM. It's a huge engineering effort. Gecko can currently collect cycles between C++ and JS, but extending that is not trivial, and I believe Safari cannot collect such cycles and instead by design avoids creating such cycles - but that would not be possible with the Dart VM.
It might not be practical for other browsers to adopt such a technology. So if Google sites force the Dart VM to be necessary to compete, that would basically mean that the other browsers cannot compete. Then there would be just Chrome, a single implementation of a web browser, dominating the market like IE used to.
It might be good for users to have a single browser for a while, single implementations can move faster without regard for standards or openness. But lack of standardization and openness also means it is a proprietary platform, of which we already have many.
> Well, the Dart VM is not like adding a backend to a compiler or VM - it is a complete VM in itself.
My straw-man idea was not to add the Dart VM to the browser, it was to add a Dart-to-asm.js compiler to the browser, as an AOT compilation step. This would not involve integrating the VM at all.
> It might not be practical for other browsers to adopt such a technology.
Given that there are at least three completely independent and highly competitive JavaScript JIT-compiling VMs from a variety of different browser vendors, I find this unlikely.
I think we are four levels into hypotheticals here. If every technical advance was rejected due to something bad that might happen four steps down the road, nothing would ever improve.
We surely never would have gotten JavaScript. That could have gone badly in tons of different ways (especially since, as the first execution engine in a browser, there was no backward-compatibility strategy). Who would have believed in 1995 that 15 years later this technology would have gotten pushed so far, and that the competition would be so healthy?
> So if Google sites force the Dart VM to be necessary to compete, that would basically mean that the other browsers cannot compete. Then there would be just Chrome, a single implementation of a web browser, dominating the market like IE used to.
The entire web platform is standardized (including Dart, which is standards-track). I would challenge you to name a standardized technology with a market comparable to the web in which one vendor is so dominant that all of the other competitors are defeated and it becomes a monoculture, despite a large demand.
If anything, I think the prospect of a web that cannot keep up with other application technologies far more likely and troubling.
My straw-man idea was not to add the Dart VM to the browser, it was to add a Dart-to-asm.js compiler to the browser, as an AOT compilation step. This would not involve integrating the VM at all.
> It might not be practical for other browsers to adopt such a technology.
Given that there are at least three completely independent and highly competitive JavaScript JIT-compiling VMs from a variety of different browser vendors, I find this unlikely.
I think we are four levels into hypotheticals here. If every technical advance was rejected due to something bad that might happen four steps down the road, nothing would ever improve.
We surely never would have gotten JavaScript. That could have gone badly in tons of different ways (especially since, as the first execution engine in a browser, there was no backward-compatibility strategy). Who would have believed in 1995 that 15 years later this technology would have gotten pushed so far, and that the competition would be so healthy?
> So if Google sites force the Dart VM to be necessary to compete, that would basically mean that the other browsers cannot compete. Then there would be just Chrome, a single implementation of a web browser, dominating the market like IE used to.
The entire web platform is standardized (including Dart, which is standards-track). I would challenge you to name a standardized technology with a market comparable to the web in which one vendor is so dominant that all of the other competitors are defeated and it becomes a monoculture, despite a large demand.
If anything, I think the prospect of a web that cannot keep up with other application technologies far more likely and troubling.
> My straw-man idea was not to add the Dart VM to the browser, it was to add a Dart-to-asm.js compiler to the browser, as an AOT compilation step.
Oh ok, sorry for misunderstanding you.
That might work, but it is unclear it would be any faster than dart2js. Also, AOT is not likely to work in Dart which is optionally typed, unless a codebase is actually fully typed. Overall it seems an interesting experiment perhaps - I've suggested it myself - but an unlikely one.
> I would challenge you to name a standardized technology with a market comparable to the web in which one vendor is so dominant that all of the other competitors are defeated and it becomes a monoculture, despite a large demand.
Well, the web - back in the IE days.
Also to a lesser extent the smartphone mobile web which was a monoculture of WebKit (and to some degree still is today).
And the point is that standards become irrelevant when there is a monoculture. In theory windows supported various POSIX APIs, but in practice windows became a proprietary monoculture.
Oh ok, sorry for misunderstanding you.
That might work, but it is unclear it would be any faster than dart2js. Also, AOT is not likely to work in Dart which is optionally typed, unless a codebase is actually fully typed. Overall it seems an interesting experiment perhaps - I've suggested it myself - but an unlikely one.
> I would challenge you to name a standardized technology with a market comparable to the web in which one vendor is so dominant that all of the other competitors are defeated and it becomes a monoculture, despite a large demand.
Well, the web - back in the IE days.
Also to a lesser extent the smartphone mobile web which was a monoculture of WebKit (and to some degree still is today).
And the point is that standards become irrelevant when there is a monoculture. In theory windows supported various POSIX APIs, but in practice windows became a proprietary monoculture.
"if the VM eventually becomes much faster than the dart2js path, Google can essentially force other browsers' hands by adopting Dart on Google sites"
Or all of the browser vendors could sit down and design a new language based on the experience gained from implementing Dart. This new more easily optimizable language can become a new web standard. After all this is what happened with SPDY and HTTP2.0. This "new language" could also just be a new version of Javascript with a few backwards incompatible changes.
One interesting claim of the DartVM authors is that they have achieved a 10x start up gain over Javascript when using script snapshots. If this turns out to be true, it will add significant pressure for other vendors to implement a similar feature. The only way to get this to work in Javascript is to make backwards incompatible changes. For example only allowing a static top-level structure, as in Dart.
I see the competition from Dart as being good for end users, as it adds pressure on Javascript to evolve. It's also interesting to see the V8 team porting a number of Dart's optimisations to V8.
Or all of the browser vendors could sit down and design a new language based on the experience gained from implementing Dart. This new more easily optimizable language can become a new web standard. After all this is what happened with SPDY and HTTP2.0. This "new language" could also just be a new version of Javascript with a few backwards incompatible changes.
One interesting claim of the DartVM authors is that they have achieved a 10x start up gain over Javascript when using script snapshots. If this turns out to be true, it will add significant pressure for other vendors to implement a similar feature. The only way to get this to work in Javascript is to make backwards incompatible changes. For example only allowing a static top-level structure, as in Dart.
I see the competition from Dart as being good for end users, as it adds pressure on Javascript to evolve. It's also interesting to see the V8 team porting a number of Dart's optimisations to V8.
>
To me this is like saying: "it's safe to defend Servo up to the point that it's faster single-threaded browser engines. Then Chrome and IE might fall behind in performing for web apps and then you will see how Servo will hurt the web ecosystem."
We are not implementing anything in Servo that does not have cross-vendor support and is on standards track. That's not the same as Dart.
We are not implementing anything in Servo that does not have cross-vendor support and is on standards track. That's not the same as Dart.
I address this argument in the rest of my comment. Asm.js is not standards track as far as I know.
Actually let me post a thought experiment. Suppose that Dartium, instead of processing straight Dart source, processed a format that is like JS except that all the Dart is in JavaScript comments at the top of each Dart2JS-outputted function.
And suppose developers compiled their Dart to these JS-with-Dart-in-comments files, and distributed these on the web instead of Dart and JS as two separate files?
At that point, how is Dart different than asm.js?
Actually let me post a thought experiment. Suppose that Dartium, instead of processing straight Dart source, processed a format that is like JS except that all the Dart is in JavaScript comments at the top of each Dart2JS-outputted function.
And suppose developers compiled their Dart to these JS-with-Dart-in-comments files, and distributed these on the web instead of Dart and JS as two separate files?
At that point, how is Dart different than asm.js?
> At that point, how is Dart different than asm.js?
It's not guaranteed that the Dart VM and the dart2js-compiled code implement the same semantics. (And, in fact, they don't, by design—bignums operate differently in JS and the Dart VM, which could break sites in non-Chrome browsers.)
It's not guaranteed that the Dart VM and the dart2js-compiled code implement the same semantics. (And, in fact, they don't, by design—bignums operate differently in JS and the Dart VM, which could break sites in non-Chrome browsers.)
No one has a problem with Dart2JS. We welcome more language choice on the web. People have a problem with Dartium because it's an attempt by one company to bully the rest of the web into adopting their own proprietary technology.
It's no different than putting an asm.js processor into a JS engine. asm.js is equally "proprietary" (actually more so, it's not on any standards track), and if it's truly faster than plain JS, then it's equally "bullying."
(Note: I actually like asm.js a lot and don't think that healthy competition is "bullying").
(Note: I actually like asm.js a lot and don't think that healthy competition is "bullying").
Are you being serious? asm.js is basically a "best practices" guide for js vm authors. It's not required to run asm.js code, or even guaranteed to be faster; other js engines have optimized for asm.js code without treating "use asm" special.
Dartium requires the end developer distribute 2 payloads, one for Dartium browsers and 1 for JavaScript browsers.
Dartium requires the end developer distribute 2 payloads, one for Dartium browsers and 1 for JavaScript browsers.
> asm.js is basically a "best practices" guide for js vm authors.
No. It is a specifically designed subset of JS that also has extra annotations. If a block of code does not adhere to the rules, it is not asm.js and will be processed as regular JS. If it validates, it is processed by a different compiler pipeline and AOT compiled.
It is much more accurate to say that asm.js is a newly designed byte-code that very cleverly happens to use backward-compatible JS as its serialization.
Native Dart is also not guaranteed to be faster than Dart2JS.
> Dartium requires the end developer distribute 2 payloads, one for Dartium browsers and 1 for JavaScript browsers.
Ah but that is only extra work for the developer. Similar to compile-to-JS languages like TypeScript, CoffeeScript, Emscripten, etc. there is no problem with new technologies that impose extra work on the developer, because it is the developer's choice to use it or not, so the person making the decision is the one paying the extra administrative cost.
No. It is a specifically designed subset of JS that also has extra annotations. If a block of code does not adhere to the rules, it is not asm.js and will be processed as regular JS. If it validates, it is processed by a different compiler pipeline and AOT compiled.
It is much more accurate to say that asm.js is a newly designed byte-code that very cleverly happens to use backward-compatible JS as its serialization.
Native Dart is also not guaranteed to be faster than Dart2JS.
> Dartium requires the end developer distribute 2 payloads, one for Dartium browsers and 1 for JavaScript browsers.
Ah but that is only extra work for the developer. Similar to compile-to-JS languages like TypeScript, CoffeeScript, Emscripten, etc. there is no problem with new technologies that impose extra work on the developer, because it is the developer's choice to use it or not, so the person making the decision is the one paying the extra administrative cost.
It's extra work that a lot of developers aren't going to do. "Works in Chrome, closes ticket". Can't even get developers to use css prefixes properly.
Hence why I called Dartium bullying. It's an attempt to reinvent the web with Google in control. asm.js is just an attempt to make existing vm optimizations a little bit better (and again, others disagree that they are needed).
Hence why I called Dartium bullying. It's an attempt to reinvent the web with Google in control. asm.js is just an attempt to make existing vm optimizations a little bit better (and again, others disagree that they are needed).
Honestly, ActiveX/JApplet comparison seems pretty fair to me. I know you said Java, but still.
Java Applets run sandboxed. ActiveX did not. It's the difference between running an exe attached to an email and visiting a web page that runs JavaScript. Do these sound the same to you?
For more info see: http://sip.cs.princeton.edu/java-vs-activex.html
For more info see: http://sip.cs.princeton.edu/java-vs-activex.html
Sure there is a sandbox... but its a bit leaky
Dart is Google's JavaScript. JavaScript was developed exclusively by Netscape and forced upon the web because of their dominance. Everyone agrees in hindsight that it was bad to do it that way. And now today Google is attempting the same thing.
>Everyone agrees in hindsight that it was bad to do it that way.
I, for one, don't. Better Javascript, with all its warts, than the W3C taking 10 years to create some standard language that was a comitee monstrocity (as they used to do a lot, until HTML5).
I, for one, don't. Better Javascript, with all its warts, than the W3C taking 10 years to create some standard language that was a comitee monstrocity (as they used to do a lot, until HTML5).
> Dart is Google's JavaScript. JavaScript was developed exclusively by Netscape and forced upon the web because of their dominance. Everyone agrees in hindsight that it was bad to do it that way.
This is true only for very limited values of "everyone".
This is true only for very limited values of "everyone".
Dart can compile into javascript. It is nothing like ActiveX. ActiveX is basically running native code from the browser. How are you making this link?
Dart's original purpose was having its own VM run in the browser - search 'Dartium'.
Only when that idea failed to gain traction did they turn it into a compile-to-js language...
Only when that idea failed to gain traction did they turn it into a compile-to-js language...
Dart2js was there from the beginning and the project was always well stuffed. It was never an afterthought and some decisions in the Dart language were taken because of the constraints we have when compiling to JavaScript.
I'm not a big fan of Dart but IMHO a "leaked" internal memo on replacing JavaScript and an implementation as a browser embeddable VM which isn't used even in Chrome don't make it as evil as ActiveX.
Would ActiveX have been so bad if it was open source and not tied into the operating system?
...and sandboxed?
Dart is a fine language. The main thing is has going against it is the feature widely referred to as "Is Not JavaScript". Thus, the Dart-to-JavaScript compiler.
Dart is a fine language. The main thing is has going against it is the feature widely referred to as "Is Not JavaScript". Thus, the Dart-to-JavaScript compiler.
>Would ActiveX have been so bad if it was open source and not tied into the operating system?
This is my personal view and it may not be accurate: I don't think being open source or cross platform would have mattered to an average PC user back then. Windows held the dominance among PC users (>95%). It wasn't until the rise of firefox that people started noticing the benefits of open source and standards. ActiveX failed because it was way ahead of its time and that it wasn't sandboxed/virtualized making it a security blunder. The one click front door to your OS resulted in a flurry of exploits and viruses giving its bad rep as we know.
Dart is leading the same path but in a secure way. I think eventually we will end up there with Web Apps and its only a matter of who gets there first.
This is my personal view and it may not be accurate: I don't think being open source or cross platform would have mattered to an average PC user back then. Windows held the dominance among PC users (>95%). It wasn't until the rise of firefox that people started noticing the benefits of open source and standards. ActiveX failed because it was way ahead of its time and that it wasn't sandboxed/virtualized making it a security blunder. The one click front door to your OS resulted in a flurry of exploits and viruses giving its bad rep as we know.
Dart is leading the same path but in a secure way. I think eventually we will end up there with Web Apps and its only a matter of who gets there first.
Isn't that NaCl?
And release notes: https://groups.google.com/a/dartlang.org/forum/#!msg/announc...