WebKit, Mozilla & IE: Please Support the Dart VM

For the past week I've been experimenting with writing a Flex/WPF/Swing-like widget framework on top of HTML5 using Dart. Dart is what I've always wanted for client-side web programming. Its a class-based optionally typed programming language that is, in the words of Dart team member Lars Bak, "high performance, structured yet flexible, familiar and natural." Anyone who knows C++, C# or Java can look at Dart code and immediately understand what is going on. Here are some examples and a comparison to JavaScript.

For projects such as widget libraries, inheritance and other modern language features are extremely useful. APIs are also much easier to decompose into a nicely organized class hierarchy. I can't picture working on this project without the benefit of a modern class based language.

Dart can be run directly on a Dart VM (coming soon in Chrome) or translated to Javascript for browsers that don't have native support. Obviously the Dart VM approach has much better performance characteristics. Because of differences in the languages designs, Dart VMs will always be faster than Javascript VMs. Amusingly, the high performance Javascript VMs do backflips to make Javascript behave like a class based language.

Its unfortunate that the WebKit, IE and Mozilla teams currently don't intend to incorporate the Dart VM. From Wikipedia:

As of January 2012, Microsoft Internet Explorer, Mozilla Firefox, and Apple Safari do not have plans to implement support for Dart. Microsoft's JavaScript team has stated in Nov. 2011 that, "Some examples, like Dart, portend that JavaScript has fundamental flaws and to support these scenarios requires a 'clean break' from JavaScript in both syntax and runtime. We disagree with this point of view." Apple engineer Oliver Hunt, working on the WebKit project (which powers both Safari and Google's own Chrome browser) has stated, "Adding an additional web facing language (that isn't standardized) doesn't seem beneficial to the project, if anything it seems harmful (cf. VBScript in IE)." Mozilla's Brendan Eich, who developed the JavaScript language, has stated, "I guarantee you that Apple and Microsoft (and Opera and Mozilla, but the first two are enough) will never embed the Dart VM. Full article

I sincerely hope the WebKit, IE & Mozilla teams rethink this position. Native Dart support on all major browsers would make the web a better place for coders. Hunt and Eich clearly think Dart is a political move for Google, but I don't see any evidence of that. Google has pushed Javascript to its limits. Google Apps is a tour de force of Javascript programming, as is Google+. They know better than anyone that there are inherent limitations to its performance and ability to be easily tooled for large-scale projects. Anyone who has worked on a large component library knows exactly what I am talking about.

Dart can probably survive as a great platform for Chrome and a workable platform for the other browsers (via Javascript as an intermediate language), but wouldn't it be nice to have a language on par with Java and C# that runs lightning fast on all clients? If you agree, join me in writing the developers of these browsers.

I don't think having multiple options for programming the browser is going to slow anything down. UNIX is the original polyglot programming environment, and the various options have helped that ecosystem grow. If anything, we need to speed up.

Regardless, compiling to performant and modern JavaScript has always been a first class goal of Dart.

I'm probably being a little hard on JavaScript. If I'm writing a UI framework or something like Google Apps, Dart makes things much more manageable. That being said, JavaScript is perfectly well suited for many tasks. I like the direction of ECMAScript 6 aside from its omission of classes. Even Brendan Eich, JavaScript's inventor, believes classes should be added.

There are libraries to help you write large scale applications like ember.js or sencha. You can cherry pick libraries like backbone, underscore, require.js and jqueryUI to roll out your own solution which works well for me.

I'm probably being a little hard on JavaScript. If I'm writing a UI framework or something like Google Apps, Dart makes things much more manageable. That being said, JavaScript is perfectly well suited for many tasks. I like the direction of ECMAScript 6 aside from its omission of classes. Even Brendan Eich, JavaScript's inventor, believes classes should be added.

I’m afraid that classes are on their way out of ES6. This seems a shame, and avoidable... I agree with Erik Arvidsson that “[b]y not providing [class] syntax we are continuing to encourage a million incompatible ‘class’ libraries.” Post on brendaneich.com

Javascript translation is a stopgap measure for Chrome and a fallback for browsers that don't have a Dart VM.

Ahh, that makes sense. Okay, in that case, it's really a case beyond a simple language bias against JavaScript and I can see a better case for it.

True, but they are hacks. Its possible to do your gardening with a fork, but I don't recommend it :-) All these concepts are first order language features in Dart that are baked into the language and the runtime environment. JavaScript libraries are poor substitutes for highly optimized features that are native to the platform.

Yup, I can't really argue this and you are right in that Javascript does have a lot of issues which are related to the language itself. ECMAScript version 6 (Harmony) has a lot of heavy syntax changes and brings lots of features but I guess this isn't enough for Google.

I'm not really against Dart itself but more concerned that if all the browsers decided to adopt this, you now have two languages to deal with and this is just going to slow things down.

@Scott I'm always happy to hear opposing views. Try Dart for a week and see if you feel the same way. The difference is night and day.

Kind of an off topic but in regards to the point about performance, I also don't see the case for Dart performing better than Javascript since it compiles to JavaScript anyway

Javascript translation is a stopgap measure for Chrome and a fallback for browsers that don't have a Dart VM. In the next version of Chrome Dart will run directly on a highly optimized virtual machine rather than using Javascript as an intermediate language. Dart was designed for better performance. Its not a fair battle because Javascript is 17 years old. It was invented before the advent of modern virtual machine architectures and, as such, some of the language design decisions make it very difficult to optimize.

Dart is a excellent partner for HTML5. Its adoption is orthogonal to concerns about standardization of HTML5 audio and video. Resig is a smart guy, but he is dead wrong on this issue. The DOM does need fixing but that has nothing to do with Dart versus Javascript. They are absolutely unrelated.

The Darthelloworld example that compiles to something like 20,000 lines of code is often brought up as an example.

The author of this post apparently wasn't aware of the --optimize flag to dartc which would have removed all the unneeded library code. Additionally, this only relates to Dart when it is translated to Javascript as opposed to running directly on a Dart VM.

Today there are ways to get private variables, classes, inheritance, modularity and dependency management in JavaScript...

True, but they are hacks. Its possible to do your gardening with a fork, but I don't recommend it :-) All these concepts are first order language features in Dart that are baked into the language and the runtime environment. JavaScript libraries are poor substitutes for highly optimized features that are native to the platform.

I'm 100% with Google in this battle. JavaScript can (and should) be improved, but its inherent limitations prevent it from ever being as fast or as well suited to programming in the large as Dart. That doesn't mean Google will win. Betamax was a better technology than VHS, but that didn't save it from extinction. Even if Google loses, I want to help them fight for a better web.

Dan, respectfully, I'm sort of leaning towards supporting browser vendors to sticking with JavaScript. And I admittedly, say this without even trying Dart yet :)

At this point, trying to add another language seems like it could fragment the browser efforts when maybe vendors should focus their energy on more important issues like resolving the broken state of the HTML5 Audio API and implementing awesome feature like webrtc so that we can start using them today and move the web forward. As John Resig (creator of jQuery) tweeted in response to Dart, "Why is Google putting time and effort into changing JavaScript when the DOM is what needs fixing?".

Yes there are many issues with Javascript but it is improving with newer versions. Today there are ways to get private variables, classes, inheritance, modularity and dependency management in JavaScript and hopefully more will come. I think many programmers also get confused because JavaScript is as Doug stated, List with clothing of C and there are many patterns and libraries that you can use today to help with large scale app development.

I'm interested in checking out Dart but I would much rather see implementation of html5 features be a higher priority across the browsers.

Kind of an off topic but in regards to the point about performance, I also don't see the case for Dart performing better than Javascript since it compiles to JavaScript anyways. Perhaps someone can shed some light on this matter.The Darthelloworld example that compiles to something like 20,000 lines of code is often brought up as an example.