What Dart Wants

In which a long-time JavaScript community member learns what Dart wants, and is pleasantly surprised.

(Note, I'm speaking from my personal perspective in this post.)

A reasonable question

I received a nice email from Addy Osmani, my friend and colleague in Chrome Developer Relations. Addy is active with the JavaScript community, maintains TodoMVC archive, authors web development tutorials, and more. It's fair to say that Addy is plugged into modern web development.

Beastie Boys, So What Cha Want? (C) 2009 Capitol Records, LLC
As a current web developer, Addy was curious about Dart's motivations and philosophy. Is Dart out to replace JavaScript? Who is checking out Dart? What is Dart doing? What does it want? Luckily, Addy came to the right place. Here's what I wrote back.

Choice is good

We believe developer choice is good, and options are good. We believe Dart, which can provide a compelling option for modern web app development, ultimately brings more developers to the web. As long as those web apps run on the majority (aka modern and progressively improving and updating) browsers, we're happy and the web is happy.

Expect more

The developers interested in Dart are developers with a different set of expectations. They expect a programming environment that helps them craft larger and more complex apps. They expect refactoring from their tools. They expect static analysis. They expect a bundled and cohesive set of libraries. They expect a bundled package manager. They expect significantly improved performance. They expect a better concurrency model.  We aim to meet and exceed those expectations.

Web development is improving every day, but it can sometimes be a chaotic mixed bag of roll-your-own solutions. Even if you have a set of frameworks and tools for creating your non-trivial app, finding your way around the code, and working with a large team, can be a challenge without static analysis tools. Dart really helps here because it is a toolable language, with three major editors (Dart Editor, Eclipse, and IntelliJ/WebStorm) supporting features such as refactoring, jump to definition, quick fixes, outline view, show callers, code completion, integrated debugging, and more. When apps and teams cross the non-trivial threshold, it's tools and features like these that really make a big difference.

Dart wants developers to stay productive. The debugging support in Dart Editor works closely with Dartium, a custom build of Chromium with the Dart VM. Set breakpoints, examine state, see exceptions, and more without ever waiting for a compile step. It's important to Dart to maintain a tight iteration loop, striving for a fast edit/reload cycle that current web developers demand.

Dart also wants apps to start up faster. Much, much faster. It's silly that today's modern web apps are still parsed from source. Initial research has shown that Dart's snapshots, or serialized binary heaps, can help apps startup 10X faster. Especially on mobile devices, every millisecond counts.

Work with the web

Dart doesn't want to sit on top of the web. Instead, I believe Dart wants to work with the web and its existing infrastructure. To that end, progress continues on a Dart-JavaScript interop solution to enable Dart code to work with existing JavaScript code. This is one of the most requested features of the project, as we've heard that many developers would like a way to slowly start using Dart with their existing investments.

Web Components, which are new capabilities for declarative and sharable components, is also a natural integration point. Early work on Dart + Web Components is available as open source, and might prove quite an interesting way to blend JavaScript and Dart components.

One of the more important aspects of the project is the Dart-JavaScript compiler. The compiler is in its third generation, with correct language semantics, terse output size, and fast compiles among the goals for the project. Dart wants to run across the modern web, so that means it needs to be compiled to JavaScript. Luckily, many of the engineers on the Dart project have intimate knowledge of JavaScript engines (like V8, inside Chrome), which helps them to know how to generate efficient JavaScript code.

Build bigger apps

Dart wants to see more awesome apps running in modern browsers, and wants to help a broad range of developers (not just endemic to the web) meet and exceed the rising user demands for beautiful, easy to use, fun, powerful apps running in the browser. Dart wants to see more developers demand better workflows, tools, frameworks, and performance for whatever language or runtime they are using. Dart wants to be a great choice to help more developers build for the most ubiquitous platform out there.

I was very happy to debunk some myths for Addy, and that he now understood what we're thinking and striving for.

The Dart project

So what is the Dart project doing about it?

  1. Building a familiar, interesting, and simple language with clear semantics.
  2. Building tools and libraries for better developer productivity.
  3. Building a new VM for running Dart code, providing speed boosts, debugging, and modern concurrency.
  4. Building a Dart to JavaScript compiler, ensuring Dart runs across the modern web.
  5. Building a Dart to JavaScript interop layer, because Dart wants to be part of the web, not just sit on top.
  6. Building a Dart + Web Components library, because we think Web Components will be the foundation for the next evolution of web development.
  7. Making changes based on feedback from the community, and accepting pull requests.
  8. Building in the open as an open source project.
What's next

Dart is, at the time of this writing, still evolving rapidly and is a technology preview. The first milestone is coming soon. The M1 launch will provide a fairly stable language base with which to build upon. If your first introduction to Dart was the public launch in October 2011, you're in for a treat with lots of changes to the language, runtimes, and tools (many of which were in response to community feedback).

If you're interested, or want to share your thoughts, please join the discussion at the Dart mailing list. Also, Stack Overflow is a good place to ask Dart HOWTO questions.
Post a Comment

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