new site

src/site/support/faq.html

 ---
 layout: default
 title: "FAQ"
 rel:
   author: eli-brandt
 ---
 
 <h1>Frequently Asked Questions (FAQ)</h1>
 <em>Collected by Eli Brandt
 <br>
 Version 0.02, February 2012</em>
 
-<section>
 <p>
   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.
 </p>
 
+<section id="contents">
+
 <h3>Contents</h3>
 <ol id="faq-toc" class="toc">
   <li><a href="#strategy" class="faq-topic">Strategy</a>
   <ol>
     <li><a href="#why-dart">Why Dart?</a></li>
     <li><a href="#why-fix-the-language">Is the language really what needs to be fixed in web development?</a></li>
     <li><a href="#does-dart-divert-effort">Is Dart going to divert community effort from JavaScript-based web development?</a></li>
     <li><a href="#will-dart-be-standardized">Is Google planning to put Dart under the control of a standards body?</a></li>
     <li><a href="#how-will-dart-take-input">Until that point, how will you be taking input on changes to Dart?</a></li>
     <li><a href="#why-not-designed-by-standards-body">Why didn't Google make Dart an open standard right from the start?</a></li>
@@ skipping 34 matching lines @@
     <li><a href="#what-browsers-have-dart">What browsers support Dart now?</a></li>
     <li><a href="#hello-world-js-size">Why was the JavaScript output for "Hello world" so big?</a></li>
     <li><a href="#debugging-output-js">How do I debug Dart code after it's been compiled to JavaScript?</a></li>
     <li><a href="#what-input-compiles">Will any valid Dart code compile to JavaScript, or are there limitations?</a></li>
     <li><a href="#json-support">Does Dart support JSON?</a></li>
     <li><a href="#server-support">Will Dart run on the server?</a></li>
   </ol> </li>
 
   <li><a href="#acknowledgments" class="faq-topic">Acknowledgments</a></li>
 </ol>
-</section>
+</section> <!-- /#contents -->
 
 {% comment %}
 <!--
 TODO: do we have a standard trick to add some scrollable whitespace at the bottom so people can click on the bottom TOC entries (like #server-support) and go to the right place? 
 
 ANSWER: no. :( It's a common problem but not one I'd thought about fixing. If we add space above the footer, people won't see the footer. If we add space below, it'll just look weird... but maybe that'd be OK. -->
 {% endcomment %}
 
-<section>
-<h2 id="strategy">Strategy</h2>
+<section id="strategy">
+<h2>Strategy</h2>
 
 <h3 id="why-dart">Q. Why Dart?</h3>
 
 <p>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.</p>
 
 <h3 id="why-fix-the-language">Q. Is the language really what needs to be fixed in web development?</h3>
 
 <p>We want to <a href="http://hyperboleandahalf.blogspot.com/2010/06/this-is-why-ill-never-be-adult.html">fix ALL the things</a>.  There's "Dart" the language, and then there's "Dart" the overall project.  The Dart <em>project</em> is betting that the language needs some changes, but we also want to <a href="http://www.dartlang.org/articles/improving-the-dom/">improve the DOM</a> and other libraries, and to improve the tools we use.</p>
 
 <p>At the same time, Google is also placing bets that JavaScript <em>can</em> 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.</p>
@@ skipping 27 matching lines @@
 <h3 id="why-not-multi-language-VM">Q. Why didn't Google build a bytecode VM targetable by multiple languages including Dart?</h3>
 
 <p>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:
 <ul>
 <li>Google already works on a multi-language bytecode: <a href="https://developers.google.com/native-client/overview#distributing-an-application">LLVM bitcode in PNaCl</a>.</li>
 <li>Even if a bytecode VM is specialized for Dart, a language VM will be simpler and faster because it can work under stronger assumptions&mdash;for instance, a structured control flow.  These assumptions make the implementation cleaner and optimizations easier.</li>
 <li>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.</li>
 <li>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 <a href="/articles/why-not-bytecode/">an article</a> talking about the VM question in more detail.</li>
 </ul>
 </p>
-</section>
+</section> <!-- /#strategy -->
 
-<section>
-<h2 id="language">Language</h2>
+<section id="language">
+<h2>Language</h2>
 
 <h3 id="compare-to-javascript">Q. Isn't Dart a lot like JavaScript?</h3>
 
 <p>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?</p>
 
 <p>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:
 <ul>
 <li>User-defined operator methods.  We like the lightweight, readable code these give for <a href="http://www.dartlang.org/articles/improving-the-dom/">our DOM interface</a>.</li>
 <li>Lightweight syntax for anonymous functions.  You use them a lot in web programming; now they look great.  And they come with correct binding of <code>this</code> and full block-level lexical scoping, no gotchas.</li>
 </ul>
@@ skipping 26 matching lines @@
   return greeting;
 }
 {% endhighlight %}
 
 <p>With the following Dart code:</p>
 
 {% highlight dart %}
 // Dart code
 
 String MakeGreeting(String name) {
-  String greeting = 'hello ' + name;
+  String greeting = 'hello $name';
   return greeting;
 }
 {% endhighlight %}
 
 <p>If you are using Closure and can switch to Dart, you will probably enjoy the change.</p>
 
 <h3 id="compare-to-coffeescript">Q. How does Dart compare with CoffeeScript?</h3>
 
 <p>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.</p>
 
@@ skipping 31 matching lines @@
 
 <p>Yes.</p>
 
 <h3 id="can-add-everything">Q. Can Dart add tuples, pattern matching, non-nullable types, interface duck typing, partial evaluation, optional semicolons, ...?</h3>
 
 <p>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.</p>
 
 <p>Please look at the <a href="http://code.google.com/p/dart/issues/list">list of Dart issues</a> 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.</p>
 
 <p>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.</p>
-</section>
+</section> <!-- /#language -->
 
-<section>
-<h2 id="types">Types</h2>
+<section id="types">
+<h2>Types</h2>
 
 <h3 id="type-inference">Q. Does Dart have type inference?</h3>
 
 <p>That's not specified by the language, and it's left up to the compiler or editor that wants to do it.  Type inference could certainly be useful.</p>
 
 <h3 id="why-types-optional">Q. Why are type annotations optional?</h3>
 
 <p>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.</p>
 
 <h3 id="why-types-unsound">Q. Why is the type system designed to be unsound?</h3>
@@ skipping 14 matching lines @@
 
 <h3 id="why-covariant-generics">Q. Why are generics covariant?</h3>
 
 <p>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?</p>
 
 <p>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.</p>
 
 <p>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 <em>require</em> marking, and we feel that variance inference systems add too much complexity for their benefit in Dart.</p>
 
 <p>Again, we're trying to be pragmatic, and we think the outcome is reasonable.</p>
-</section>
+</section> <!-- /#types -->
 
-<section>
-<h2 id="tools">Usage and tools</h2>
+<section id="tools">
+<h2>Usage and tools</h2>
 
 <h3 id="should-i-use-dart-yet">Q. Should I write my web app in Dart?</h3>
 
 <p>If you want to experiment, we'd love for you to try Dart and give us feedback.  If your web app is something that needs to be reliable, we really recommend waiting until Dart is more mature.  We've released Dart at a very early stage, and we're likely to make breaking changes to the language.</p>
 
 <h3 id="interop-with-js-libs">Q. How does Dart code interoperate with JavaScript libraries?</h3>
 
 <p>Right now, the supported way is to port the library to Dart.  We're trying an approach using isolates: Dart code calls across an isolate boundary to JavaScript, using RPC stub code that we hope to autogenerate.  This approach has the good property that you never have multiple heaps trying to share data, and that you're not locking yourself out from running on a Dart VM.  We'll see how it works.</p>
 
 <h3 id="js-codebase-integration">Q. I have a large JavaScript codebase.  How would I migrate it to Dart?</h3>
@@ skipping 38 matching lines @@
 
 <p>Yes, we intend for any valid Dart code to compile to JavaScript.  If some support is missing from one of our compilers, that's a bug (in either the compiler or the spec).</p>
 
 <h3 id="json-support">Q. Does Dart support JSON?</h3>
 
 <p>Yes, Dart libraries can parse from and stringify to JSON.  You can find such a library at <a href="http://code.google.com/p/dart/source/browse/#svn%2Fbranches%2Fbleeding_edge%2Fdart%2Flib%2Fjson"><code>dart/lib/json/</code></a>.</p>
 
 <h3 id="server-support">Q. Will Dart run on the server?</h3>
 
 <p>We have some server code now, such as our test suites.  Have a look at the file, socket, and process APIs in <a href="http://code.google.com/p/dart/source/browse/#svn%2Fbranches%2Fbleeding_edge%2Fdart%2Fruntime%2Fbin"><code>dart/runtime/bin/</code></a>. </p>
-</section>
 
-<section>
-<h2 id="acknowledgments">Acknowledgments</h2>
+</section> <!-- /#tools -->
+
+<section id="acknowledgements">
+<h2>Acknowledgments</h2>
 
 <p>Thanks to users who asked questions, and to many Googlers who contributed questions, answers, and improvements: Mukesh Agrawal, Lars Bak, Adam Barth, 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, Brian Wilkerson.</p>
 
 </section>
-
-
-