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.
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?
(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 |
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?
- Building a familiar, interesting, and simple language with clear semantics.
- Building tools and libraries for better developer productivity.
- Building a new VM for running Dart code, providing speed boosts, debugging, and modern concurrency.
- Building a Dart to JavaScript compiler, ensuring Dart runs across the modern web.
- Building a Dart to JavaScript interop layer, because Dart wants to be part of the web, not just sit on top.
- Building a Dart + Web Components library, because we think Web Components will be the foundation for the next evolution of web development.
- Making changes based on feedback from the community, and accepting pull requests.
- 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.