Frequently Asked Questions (FAQ)
Initially collected by Eli Brandt
Version 0.03, December 2012
This FAQ answers many of the questions we've been asked about Dart. However, because we released Dart
as an early technology preview rather than keeping it under wraps until version 1.0, some important
open questions remain. We hope to address them with upcoming work and experimentation, inside and
outside of Google.
Strategy
Q. Why Dart?
At Google we've written our share of web apps, and we've tried in many ways to make improvements to that development process, short of introducing a new language. Now we think it's time to take that leap. We designed Dart to be easy to write development tools for, well-suited to modern app development, and capable of high-performance implementations.
Q. Is the language really what needs to be fixed in web development?
We want to fix ALL the things. There's "Dart" the language, and then there's "Dart" the overall project. The Dart project is betting that the language needs some changes, but we also want to improve the DOM and other libraries, and to improve the tools we use.
At the same time, Google is also placing bets that JavaScript can be evolved as needed, and contributing to that work. Google wants web development to be great, and if that happens with JavaScript, we're happy.
Q. Is Dart going to divert community effort from JavaScript-based web development?
If people like Dart and use it, then to a certain extent, yes, but isn't this true of any improvement to existing web development? Nothing is zero-effort to learn or 100% back-compatible to legacy browsers, so people use both new and old. You might look at it this way: Google is putting significant effort behind both Dart and JavaScript, choosing to develop Dart while at the same time using JavaScript extensively, and working on JavaScript tools, implementation, and language spec. We're doing both because we think Dart is worth it.
Server-side web programming finds room for many languages: does Python divert effort from Perl, and does Java undercut C++? Again, to a certain extent, yes they do, but people generally consider that a healthy situation, better than if we all used a single programming language. Multiple languages have allowed for faster change than any single language has achieved through a standards process. Furthermore, languages coexist in different niches: does Groovy really compete directly with C++? People face different engineering tradeoffs and choose different languages to meet them. Ultimately, we think client-side developers should have this kind of flexibility.
Q. Is Google planning to put Dart under the control of a standards body?
Yes, we hope to. Once Dart reaches a certain level of maturity and acceptance, we expect that a standards process will be the next step.
We plan to handle it like the V8 project. We'll listen to feedback and issues, and we'll review patches from outside contributors. A contributor with a good track record can become a committer to the repository. Google engineers will also be working in the public repository, making visible changes.
Q. Why didn't Google make Dart an open standard right from the start?
We're taking the usual route to get to an open-standard programming language: someone creates a coherent first version, people experiment with it, and we standardize later. The open standard web platform has been known to add other pieces this way, where standardization follows after a vendor experiment: canvas, for example. We understand that this route raises concerns, but we think it is sometimes useful, and in particular that it is useful for programming languages, where design by committee is risky.
The most recent successful language designed by an open committee was Haskell, starting in 1990. The most widely used was COBOL, followed by Ada. It's not a common way to do language design. Among dozens and dozens of major languages, six (give or take a couple of debatables) were designed this way. (And one of those six was ALGOL-68.)
Q. What's the future for GWT?
Bruce Johnson posted on the GWT blog (with further comments on Plus): "Dart and GWT both share the goal of enabling structured web programming. In fact, many of the same engineers who brought you GWT are working on Dart. We view Dart as an ambitious evolution of GWT's mission to make web apps better for end users, and we're optimistic about its potential. As Dart evolves and becomes ready for prime time, we anticipate working closely with the GWT developer community to explore Dart."
"Meanwhile, rest assured that GWT will continue to be a productive and reliable way to build the most ambitious web apps—and even games like Angry Birds. Key projects within Google rely on GWT every day, and we plan to continue improving (and open-sourcing) GWT based on their real-world needs."
Watch our Google I/O 2012 talk The History and Future of Google Web Toolkit to learn more.
Q. Why didn't Google build a bytecode VM targetable by multiple languages including Dart?
Each approach has advantages and disadvantages, but we feel that in the context of Dart it made sense to build a language-specific VM for the following reasons:
- Google already works on a multi-language bytecode: LLVM bitcode in PNaCl.
- Even if a bytecode VM is specialized for Dart, a language VM will be simpler and faster because it can work under stronger assumptions—for instance, a structured control flow. These assumptions make the implementation cleaner and optimizations easier.
- A general-purpose bytecode VM would be even larger and slower, as it generalizes assumptions and adds functionality that for Dart is dead code: for example, multithreading with a shared heap.
- No bytecode VM is truly general-purpose; they all make assumptions that privilege some class of languages. A language VM leaves more room to improve the VM and make deep changes to optimization of the language. Some Dart engineers wrote an article talking about the VM question in more detail.
Language
Q. Isn't Dart a lot like JavaScript?
Yes and no. The Dart project thinks that JavaScript can use some changes for more productive software engineering, smarter editors and development environments, and web apps that are as beautiful and pleasing as the best client apps can be. On the other hand, we don't think everything needs to change, and why change what isn't broken?
Dart, like JavaScript, is a dynamically typed language. It adds optional compile-time type annotations to help you catch errors earlier. It takes out a few features of JavaScript, such as prototypes and the global object: this should streamline the VM, enable faster execution, and make it easier to do code completion and refactoring. And Dart adds some goodies. To name a few:
- User-defined operator methods. We like the lightweight, readable code these give for our DOM interface.
- Lightweight syntax for anonymous functions. You use them a lot in web programming; now they look great. And they come with correct binding of
this and full block-level lexical scoping, no gotchas.
Dart aims to be like JavaScript, but faster, more regular, and more scalable to large programs.
Q. Isn't Dart a lot like Java?
Well, Java is statically typed, and Dart is dynamically typed. Dart has optional static type annotations, where in Java they are required. To us these are big differences in the nature of the two languages. But Dart is a curly-brace language, and it shares some keywords with Java, such as extends and final, so we can see why people make the comparison. Honestly, we like having a straightforward and familiar syntax that's easy to pick up, even if that means it's less exciting.
Q. How does Dart compare with using the Closure compiler on JavaScript?
The idea of optional type annotations is similar. Dart's are nicer syntactically.
Compare the following Closure compiler code:
// Closure compiler code
/**
* @param {String} name
* @return {String}
*/
makeGreeting = function(name) {
/** @type {String} */
var greeting = 'hello ' + name;
return greeting;
}
With the following Dart code:
// Dart code
String MakeGreeting(String name) {
String greeting = 'hello $name';
return greeting;
}
If you are using Closure and can switch to Dart, you will probably enjoy the change.
Q. How does Dart compare with CoffeeScript?
Both Dart and CoffeeScript are inspired by JavaScript, and both can be translated back to it. They make different choices, particularly in the flavor of their syntax. As a language we think it's fair to say that Dart differs semantically from JavaScript more than CoffeeScript does; that may result in a less line-for-line translation, but we believe Dart-generated JavaScript can have excellent size and speed.
If you like CoffeeScript for its more structured feel than raw JavaScript, you may like Dart's optional static type annotations.
Q. What does Google think of TypeScript?
TypeScript and Dart have similar goals; they make building large-scale web applications easier. However, their approaches are fairly different. TypeScript maintains backwards compatability with JavaScript, whereas Dart purposely made a break from certain parts of JavaScript’s syntax and semantics in order to eradicate large classes of bugs and to improve performace. The web has suffered from too little choice for too long, and we think that both Dart and TypeScript are pointing to a brighter future for web developers! You can read a more complete response on our blog.
Q. How does Dart relate to Go?
Dart and Go are both language projects started at Google, but they are independent and have different goals. As a result, they make different choices, and the languages have very different natures, even while we all try to learn from each others' work.
Q. Why isn't Dart more like Haskell / Smalltalk / Python / Scala / other language?
Various reasons, depending on the language being asked about.
For languages that are quite different from JavaScript: it's important for Dart to compile to efficient JavaScript. Our experience in GWT is that if the source language is too different from JavaScript, it creates some cases where complex output code is needed to emulate the source language's behavior. This can cause performance to vary in ways that are not transparent to the programmer.
For languages that are less mainstream: we expect that modeling Dart on these would, on the whole, hurt our adoption. Our team includes fans of these languages, and if we thought Dart could take up our favorite cool language features and push them to widespread adoption we might be tempted, but really we think we've got our hands full introducing a new language at all.
For languages that are "more dynamic" than Dart: Dart deliberately trades off some of this arbitrary runtime modification for the goal of better performance and tools.
Q. Why isn't Dart syntax more exciting?
We did throw in some nice syntactic features such as this. constructor args, but we'd agree that Dart chooses familiarity over excitement. One team member's personal testimonial: "I wish it had a little more razzle dazzle but I can't deny that literally on my first day of writing Dart code, I was productive in it."
Q. Is it really a dynamic language if it doesn't have eval() or adding fields to a value at run time?
Dart as initially released didn't have anything like these, but future versions of Dart will look at adding dynamic features of this sort. The feature set won't match up exactly with the features in your question, but we hope to serve very much the same purposes. When we see what gets added, then everyone can decide how they classify the language.
What's important to us is that what you want to do with a dynamic language, you can do with Dart and not feel cramped. You should be able to design your system without interference from static rules, and to modify the live system during development and sometimes at run time.
So, for example, Dart isn't likely to support evaluating a string as code in the current context, but it may support loading that code dynamically into a new isolate. Dart isn't likely to support adding fields to a value, but it may (through a mirror system) support adding fields to a class, and you can effectively add methods using noSuchMethod(). Using these features will have a runtime cost; it's important to us to minimize the cost for programs that don't use them.
This area is still under development, so we welcome your thoughts on what you need from runtime dynamism.
Q. Can Dart add reflection?
We are currently in the process of adding reflection support using the mirrors API.
Q. Can Dart add tuples, pattern matching, non-nullable types, partial evaluation, optional semicolons, ...?
The language is not finished yet. It might be able to include your feature, although it can't include everything. Some features don't fit the basic nature of the language, and some don't play well with other features. Simplicity is the single most important gift we all can give to future programmers.
Please look at the list of Dart issues to see if your request is already there, and add a new issue if not. Make a thoughtful argument for your feature. Sample code with and without your feature is good evidence; a sizeable codebase that shows the need is even better evidence.
Please don't be surprised if the Dart designers say "no" by default, especially for now. It's far more painful to remove a language feature than to add it, so Dart is likely to add the most obvious features first, and then revisit the next tier later. And there simply are more possible language features in the world that can fit into any single language without making a total hash of it. But we do very much appreciate suggestions and evidence. We hope you'll see our appreciation through careful design choices and fair communication about them.
Types
Q. Does Dart have type inference?
Type inferencing is not something specified by the language specification, but it is something that implementations are free to do. It's important to remember that Dart has a dynamic type system, so type inferencing doesn't play the same role as it does in languages such as Haskell. However, Dart Editor does do some type inferencing, such as when you use var for local variables. We expect that the Dart VM and dart2js will use type inferencing when it's useful for performance or for other reasons.
Q. Why are type annotations optional?
We want to maintain the feel of a dynamically typed language, which is familiar to web developers. Mandatory types don't fit with that goal.
Q. Why is the type system designed to be unsound?
Rather than using a full, static type system, Dart has a dynamic type system with optional static type annotations. Our main goals for the types are to support tooling and documentation. We want to build a pragmatic tool that helps web programmers without getting in their way. In particular, we want our static warnings to be optimistic rather than to complain about dynamically typed code that may be valid and correctly written, such as "downcast" assignments. Because Dart execution is always type-safe, we can let some unsound cases get through the static warnings and be caught at run time instead.
Typical object-oriented languages let you downcast, which also introduces unsoundness into the type system and may result in a runtime type error. In Dart, we choose to allow downcasts without a syntax to mark them.
Sound types can help with performance but aren't essential. What we need are uniform, simple semantics.
Q. Why do type annotations have no effect on the runtime behavior?
If type annotations affect the runtime, programs will change their behavior as programmers add type information, even though the logic remains unchanged. The normal mode of development is to gradually add types for documentation and validation, and if that changes what the program does, programmers have no stable foundation to work on. This is especially true given that types could be inaccurate.
In addition, this policy helps us and others add additional type-checking tools that implement different policies without unforeseen interactions with the runtime.
Q. Why are generics covariant?
Covariant generics fit a common intuition that programmers have, and very often this intuition is correct, such as in the common "read-only" use of a generic. Although this intuition isn't always correct, Dart doesn't need it to be. Dart has already chosen optimistic static checking, so why not continue down that path and allow covariant uses of generics to pass static type checking?
Where covariant generics are too optimistic, Dart's type-safe execution allows the static warnings to be optimistic without being dangerous. Although covariance can be pessimistic too, we think it will be rare that people run into that, and and there's a simple workaround for any pessimism.
We are familiar with a variety of ways that languages try to mark or infer variance. We don't think any of them are suitable for Dart, where we want type annotations to be optional and unobtrusive: it wouldn't fit to require marking, and we feel that variance inference systems add too much complexity for their benefit in Dart.
Again, we're trying to be pragmatic, and we think the outcome is reasonable.
Usage and tools
Q. Should I write my web app in Dart?
We'd love for you to try Dart and give us feedback. If your web app is something that needs to be ultra stable, we recommend waiting until Dart is more mature. However, if you're willing to follow our blog and update your code in response to breaking changes we occasionally make, you may find that Dart is a really exciting community to be a part of!
Q. How does Dart code interoperate with JavaScript libraries?
Although Dart and JavaScript are completely separate languages with potentially separate VMs, they can interoperate. See this article to learn how.
Q. I have a large JavaScript codebase. How would I migrate it to Dart?
Try migrating one major feature at a time, and use the JavaScript interoperability library only when necessary.
Q. I have a large application written in GWT. How do I port it to Dart?
Java and Dart are syntactically similar, so this might be easier than you think. You can rely on Dart Editor to flag any syntax problems. Alternatively, you may consider porting one feature at a time to Dart and using the JavaScript interoperability library as the common middle ground. Be sure to watch our Google I/O 2012 talk Migrating Code from GWT to Dart, but keep in mind that it predates our JavaScript interoperability library.
Q. What browsers do you plan to support as JavaScript compilation targets?
We're currently aiming to support the following browsers:
- Internet Explorer, latest two versions that are 9 or higher.
- Firefox, latest two versions that are 7 or higher.
- Chrome, latest version.
- Safari, latest two versions that are 5.1 or higher.
- Opera, latest version that is 12 or higher.
That's a goal; we don't actually support all of these browsers yet. The goal may change to be either more restrictive or more permissive. We'll refine this further as Dart matures.
Q. What browsers support Dart now?
As of December 2012, no production browsers can execute Dart code unless it's first compiled to JavaScript. However, the Dart Editor ships with a version of Chromium (called Dartium) that has the Dart VM integrated into it. Dartium not only executes Dart code natively, but it also has really good interoperability with Dart Editor so that you can debug your Dart applications directly from within Dart Editor.
Q. Why was the JavaScript output for "Hello world" so big?
Dart was young. At the launch of Dart, our initial goal was to generate functional JavaScript from Dart code.
Since the initial launch, we've created an improved compiler, dart2js, written in Dart. This compiler aims to be compliant with the language specification, and will continue to be optimized for performance. The dart2js compiler generates significantly smaller JavaScript output than the launch version of dartc (the original Dart-to-JavaScript compiler).
Q. How do I debug Dart code after it's been compiled to JavaScript?
dart2js now generates source maps, so you can debug Dart code in browsers that don't support the Dart VM. However, even in rare cases where you must inspect the raw JavaScript, it's fairly debuggable using the browser's normal JavaScript development tools.
Yes. We intend for any valid Dart code to compile to JavaScript. Of course, there are some libraries that will only run on the server because they don't make sense in a browser context.
Q. Does Dart support JSON?
Yes. See the JSON class in the standard library.
Q. Can Dart run on the server?
Yes. The dart:io library is aimed at server-side code that runs on the standalone Dart VM. dart:io uses an asynchronous programming model inspired by node.js, EventMachine, and Twisted. See An Introduction to the dart:io Library to learn more.
Acknowledgments
Thanks to users who asked questions, and to many Googlers who contributed questions, answers, and improvements: Mukesh Agrawal, Lars Bak, Adam Barth, Shannon -jj Behrens, Gilad Bracha, Paul Brauner, David Carlson, Patrick Doyle, Matthias Ernst, Nicolas Geoffray, Dan Grove, William Hesse, Bruce Johnson, Seth Ladd, Patrick Linehan, Florian Loitsch, John Messerly, Srdjan Mitrovic, Anton Muhin, Bob Nystrom, Jack Palevich, David Rochberg, Matt Shulman, Joel Webber, and Brian Wilkerson.