9 Dart Myths Debunked

I survived Addy Osmani's interview and lived to tell the tale. Watch the video below to see Dart myths debunked.

Myth 1: Dart is out to replace JavaScript

FALSE! Dart provides an option for non-endemic developers to help them be more productive building high-performance apps for the modern web. There are many skilled and productive JavaScript developers, but there are also many many developers familiar with Java, C#, C++, ActionScript, and more.

Those developers have certain expectations around their tools and language, and we aim to meet and exceed those expectations. We're building in classes, interfaces, optional static types, lexical scope, optional parameters, generics, and more into the languages. We're building an editor capable of refactoring, quick fixes, static analysis, debugging, and more.

Myth 2: It's either Dart OR JavaScript

FALSE! Both JavaScript and Dart are technologies that Google believes in and invests in. Google participates in TC39, the spec group for the future of JavaScript. They also continue their work on V8, the fast JavaScript engine. The Chrome engineers continue to work to push the web forward with new specs like Web Components. Meanwhile, the team that originally built V8 is now building Dart. We envision a day when Chrome has both V8 and Dart VM embedded inside.

Myth 3: Dart is only for Chrome

FALSE! Dart compiles to modern JavaScript, so it runs across modern browsers like IE9, Safari, Firefox, Opera, Chrome, and more. It's imperative that Dart continue to work in multiple browsers.

Myth 4: Dart requires me to write with classes, libraries, and more heavy weight concepts

FALSE! Dart scales from simple scripts with untyped functions all the way to 100k lines of code with all the bells and whistles. You can certain write code that never uses a class or library, but we think that once you grow the code, you'll be happy that more structure is available to you.

Here's an example of a small script:

shoutItOut(String msg) => print('${msg.toUpperCase()}!');

main() {
  shoutItOut("Dart is fun");

Myth 5: Dart cannot use JavaScript code

FALSE! Dart now has a synchronous JS-interop library. You can use Dart code to program with synchronous, stateful JavaScript APIs like Google Maps or Twitter API.

Here's an example of using Twitter API with Dart:

void main() {
  js.scoped(() {
    // Create a JavaScript function called display that forwards to the Dart
    // function.
    js.context.display = new js.Callback.once(display);

    // Inject a JSONP request to Twitter invoking the JavaScript display
    // function.
    document.body.nodes.add(new ScriptElement()..src =

// Display the JSON data on the web page.
// Note callbacks are automatically executed within a scope.
void display(var data) {
  var results = data.results;
  // The data and results objects are proxies to JavaScript object,
  // so we cannot iterate directly on them.
  for (var i = 0; i < results.length; ++i) {
    var result = results[i];
    var user = result.from_user_name;
    var time = result.created_at;
    var text = linkify(result.text);
    var div = new DivElement();
    div.innerHTML = '<div>From: $user</div><div>$text</div><p>';

Myth 6: Without jQuery support, Dart is useless

FALSE! Dart ships with an HTML library that cleans up the DOM and makes it feel like Dart. It's not quite as slick as jQuery, but it's getting close. Here's an example of using Dart to add an element to a web page:


void main() {
  var button = new ButtonElement();
  button.text = 'Click me';
  button.on.click.add((e) => window.alert('Clicked!!'));

Or if you like, use method cascades:


void main() {
  var button = new ButtonElement()
        ..text = 'Click me'
        ..on.click.add((e) => window.alert('Clicked!!'));


Myth 7: Dart's JavaScript output is way too big

FALSE! We're on our third generation Dart-to-JavaScript compiler, with significantly smaller output. For example, as of 2012-10-08, the size of a "hello world" app is 2350 bytes. Our dart2js program performs "tree shaking" to output the code that is actually used, ignoring library code that is never called. We expect continued improvements here.

Myth 8: Debugging Dart compiled to JavaScript is hard

FALSE! Thanks to Source Maps you can use Chrome's Developer Tools to debug the compiled JavaScript via the original Dart code. A source map file creates a mapping between the original source code (Dart) and the compiled output (JavaScript).

Here is an image that shows Dart code in the Developer Tools sources tab inside Chrome. There is no Dart VM here, just Source Maps. You can even set break points!

Myth 9: I'll get to use Web Components in maybe 4-5 years

FALSE! Because Dart compiles to JavaScript, we can compile Web Components built with Dart into code that works in today's modern browsers. The Dart team is building out Web Components support now, you can following along and try it out. Learn how to build your first component with Dart.


I had fun busting Dart myths, thanks to Addy for the interview. Dart is still evolving, and we love feedback. You can find more info at http://dartlang.org, follow along with our open source work at https://github.com/dart-lang, and file bugs and feature requests at http://dartbug.com. We look forward to hearing from you!


Popular posts from this blog

  • Sponsor:  Register today for  New Game, the conference for HTML5 game developers . Learn from Mozilla, Opera, Google, Spil, Bocoup, Mandreel, Subsonic, Gamesalad, EA, Zynga, and others at this intimate and technically rich conference. Join us for two days of content from developers building HTML5 games today. Nov 1-2, 2011 in San Francisco.  Register now ! This is the second article in a Box2D series, following the Box2D Orientation article. The Box2DWeb port of Box2D contains a nice example to show off the basics of integrating physics simulations into your web app. This post will provide a walkthrough of the example, explaining the high level concepts and code. First, let's see the example in action. The code for the above is open source and available on GitHub. It was adapted from Box2DWeb's example . Animating Before we look at Box2D, it's important to understand how the above simulation is animated. You might think setInterval or setTimeout is
    Keep reading
  • In which I port a snazzy little JavaScript audio web app to Dart , discover a bug, and high-five type annotations. Here's what I learned. [As it says in the header of this blog, I'm a seasoned Dart developer. However, I certainly don't write Dart every day (I wish!). Don't interpret this post as "Hi, I'm new to Dart". Instead, interpret this post as "I'm applying what I've been documenting."] This post analyzes two versions of the same app, both the original (JavaScript) version and the Dart version. The original version is a proxy for any small JavaScript app, there's nothing particularly special about the original version, which is why it made for a good example. This post discusses the differences between the two implementations: file organization, dependencies and modules, shims, classes, type annotations, event handling, calling multiple methods, asynchronous programming, animation, and interop with JavaScript libraries. F
    Keep reading
  • Angular and Polymer, sitting in a DOM tree, B-i-n-d-i-n-g. First comes components, Then comes elements, Then comes the interop with the node dot bind. Angular , a super heroic MVC framework, and Polymer , polyfills and enhancements for custom elements built on top of Web Components, can live harmoniously in the same app. This post shows you how to connect Angular-controlled components to Polymer-controlled elements via data binding. And we do it all in Dart . Angular and Polymer I get asked "Should I use Angular or Polymer?" a lot. My answer is, "Yes". That is, both libraries have distinct strengths, and you can use both in the same app. Polymer excels at creating encapsulated custom elements. You can use those custom elements in any web app or web page, regardless if that app is built with Angular, Ember, etc. Angular excels at application engineering, with dependency injection, end-to-end testability, routing, and services. Here are som
    Keep reading