7 ms·
> 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 t
by azakai 13y ago
> 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.
- haberman 13y agoI 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.