I've checked out the site very briefly, and got curious. Is there any advantages of using Dart? Is it just a replacement for JavaScript?

It looks like simpler Java. Writing quite a lot of C# at work, the language feels very much like what I'm used to, so learning the syntax looks like a breeze to learn. Has anybody any opinions or experiences with the language?

(Compared to CoffeeScript (= I'm not doing Ruby syntax) the syntax looks more familiar to me).

  • 18
    Doug Crockford's comment is amusing: "So, I've thought for a long time... if I could take a clean sheet of paper and write a new language that retains all the goodness of Javascript... I would not have come up with anything like Dart."
    – MebAlone
    Sep 9, 2012 at 19:26
  • 2
    @MebAlone Ho-ho-ho, how insightful. What a wag that Crockford is. Wisecracks over wisdom.
    – funkybro
    Sep 10, 2012 at 9:23
  • 11
    @MebAlone The Dart language designers weren't trying to come up with a new language that retains all the goodness of JavaScript. They were trying to come up with a class-based, object-oriented language language for the browser.
    – MarkJ
    Sep 10, 2012 at 14:22
  • 1
    What does Is there any advantages of using Dart? mean? Advantage over what and measured how? There's a range of languages that compile to JavaScript. Most of them do something a lot better than Dart. Some do most things better than Dart. And for example, if you do C#, then ScriptSharp might be interesting for you. While among all the languages compiling to JavaScript it would be far from being my first choice, for you it would present a very easy transition, possibly even allowing to port existent code painlessly.
    – back2dos
    Feb 12, 2013 at 10:03
  • 1
    @MebAlone Douglas is a bit in conflict. Complaining developers don't accept new ideas but saying dart is bad in 2012 when it's only just released 2 days ago. They've announced it would come 2 years ago. As is dart addresses some of the things Douglas is unhappy with in JS (no constructor functions with "loose hanging" prototype). While keeping the things he likes (like closures). In several presentations I've seen him praise prototype, then criticize the syntax of constructor functions (he's right). Then "solves" it showing a module pattern that completely ignores the existence of prototype.
    – HMR
    Nov 16, 2013 at 11:22

4 Answers 4


Thanks for your question! Full disclaimer, I work on the Dart team.

Probably the best advantage Dart has today is that it's familiar to C#, Java, C++, and most JavaScript developers. Many developers have a set of expectations around their language (class-based OO, lexical scope, familiar syntax) and their tools (code completion, refactoring, code navigation, debugging) that Dart aims to meet and exceed.

Here's some things that I like about the language:

  1. Optional static types. When I'm prototyping or simply writing small scripts, I don't use a ton of static types. I just don't need 'em, and I don't want to get bogged down with the ceremony. However, some of those scripts evolve into bigger programs. As the scripts scale, I tend to want classes and static type annotations.

  2. Innocent until proven guilty. Dart tries hard to minimize the situations that result in a compile-time error. Many conditions in Dart are warnings, which don't stop your program from running. Why? In keeping with web development fashion, it's imperative to allow developers to try a bit of code, hit reload, and see what happens. The developer shouldn't have to first prove the entire program is correct before just testing a corner of the code.

  3. Lexical scope. This is awesome, if you're not used to it. Simply put, the visibility of variables, and even this, is defined by the program structure. This eliminates a class of puzzlers in traditional web programming. No need to re-bind functions to keep this to what you think or expect.

  4. Real classes baked into the language. It's clear most developers want to work in classes, as most web development frameworks offer a solution. However, a "class" from framework A isn't compatible with framework B, in traditional web development. Dart uses classes naturally.

  5. Top-level functions. One painful part of Java is that everything has to be put into a class. This is a bit artificial, especially when you want to define a few utility functions. In Dart, you can define functions at the top level, outside of any class. This makes library composition feel more natural.

  6. Classes have implicit interfaces. The elimination of explicit interfaces simplifies the language. No more need to define IDuck everywhere, all you need now is a class Duck. Because every class has an implicit interface, you can create a MockDuck implements Duck

  7. Named constructors. You can give constructors names, which really helps with readibility. For example: var duck = new Duck.fromJson(someJsonString)

  8. Factory constructors. The factory pattern is quite common, and it's nice to see this baked into the language. A factory constructor can return a singleton, an object from a cache, or an object of a sub-type.

  9. Isolates. Gone are the days of sharing mutable state between threads (an error prone technique). A Dart isolate is an isolated memory heap, able to run in a separate process or thread. Isolates communicate by sending messages over ports. Isolates work in the Dart VM and can compile to Web workers in HTML5 apps.

  10. Dart compiles to JavaScript. This is critically important, as JavaScript is the lingua franca of the web. Dart apps should run across the modern web.

  11. Strong tooling. The Dart project also ships an editor. You'll find code completion, refactoring, quick fixes, code navigation, debugging, and more. Also, IntelliJ has a Dart plugin.

  12. Libraries. You can organize Dart code into libraries, for easier namespacing and reusability. Your code can import a library, and libraries can re-export.

  13. String interpolation. This is just a nice feature, making it easy to compose a string: var msg = "Hello $friend!";

  14. noSuchMethod Dart is a dynamic language, and you can handle arbitrary method calls with noSuchMethod().

  15. Generics. Being able to say "this is a list of apples" gives your tools much more info to help you and catch potential errors early. Luckily, though, Dart's generics are more simple that what you're probably used to.

  16. Operator overloading. Dart classes can define behavior for operators like + or -. For example, you could write code like new Point(1,1) + new Point(2,2).

Having said all that, there are many more JavaScript libraries out there.

Personally, I believe there's room on the web for many languages. If the app is awesome, and it runs in the majority of modern browsers, I don't care as much what language it is written in. As long as you, the developer, are happy, productive, and launching on the web, that's what matters! :)

  • Many modern programming languages (Ruby, Scala, Python) include some kind of multiple inheritance mechanism, and this is coming in JDK8. Is this planned for Dart?
    – MebAlone
    Sep 10, 2012 at 5:17
  • 4
    +1 on point #1 -- dynamic typing is quite adequate for small scripts (i.e. "form validation"-level). Anything much beyond that and I find the safety-net of static typing indispensable.
    – funkybro
    Sep 10, 2012 at 9:32
  • 2
    @MebAlone I expect we'll see mixins come to Dart in the near future.
    – Seth Ladd
    Sep 10, 2012 at 16:52
  • Surprised Snap-shotting wasn't mentioned - IMO one of Dart's best features.
    – mythz
    Sep 11, 2012 at 3:55
  • @mythz I didn't mention snapshots because they aren't implemented all the way yet. But yes, they are cool!
    – Seth Ladd
    Sep 12, 2012 at 4:57

Writing quite a lot of C# at work, the language feels very much like what I'm used to

That's one point about Dart. Javascript is considered an awkward language with few general idioms. In a language like Java there is often a natural way to approach a problem. For instance if you keep an inventory of table, in Java or C# you will create a class Table.

Javascript has no classes, you might want to use prototypes but they feel awkward and don't provide such strong structure and encapsulation tools. (At least not without making any stunts.) Inheritance, composition etc. is awkward with Javascript prototypes. That's why most people use plain hash maps to store data. Or they use 3rd party libs like prototype which gives you a class-like experience.

So convenience is one thing, structure the other. Javascript just doesn't scale well because there is no standard way to structure large-scale apps. However currently such 3rd party libs are becoming really popular. (Like backbone.js)

Dart is something to solve that. It's there to give you the stuctural convenience of Java and moreover it doesn't have all these awkward JS features. (Most of them related to weak typing.)

So the answer is yes: classes, inheritance, ...: "traditional OOP". (Most realworld JS webapps out there use jQuery's callback based approached as main structure.) And it has a loose form of static typing, that's however not the key selling point.

BTW: you may want to read this "internal" Google mailing dated 2010: Future of Javascript

Javascript has fundamental flaws that cannot be fixed merely by evolving the language. We'll adopt a two-pronged strategy for the future of Javascript... Develop a new language (called Dash) that aims to maintain the dynamic nature of Javascript but have a better performance profile and be amenable to tooling for large projects...

  • 5
    Not everyone considers Javascript "an awkward language". There often is a natural way to approach a problem. All too often it requires techniques (functional programming, operator overloading, mixins, generic programming) that are not supported by Java. Inheritance, composition, etc. is not awkward with Javascript prototypes. It's just different from Java and C#, but similar to Ruby, LUA, and Perl. Sep 10, 2012 at 19:20
  • 1
    Mmm... first time I hear anything good about prototypes. But in which way do you see JS prototypes similar to Ruby?
    – Philip
    Sep 11, 2012 at 11:24
  • 1
    you need to get out (of the Java world) more often. Look at Ruby metaprogramming (ruby-doc.org/docs/ProgrammingRuby/html/ext_ruby.html) and you will see that Ruby member name resolution is similar to (but IMO more complicated than) Javascript member name resolution. Sep 11, 2012 at 16:26
  • jQuery in no way shape or form promotes a callback approach any more than the DOM API (which it essentially wraps) or core JS itself does or Dart would have. Prototypes are the inheritance mechanism that allow us to do things classes can't. Compare classes to functions constructors, which encapsulate internal instance vars just fine, not prototypes. Not that your median talent level bean/getter-setter spamming Java or C# dev has the slightest idea of what encapsulation is good for or the average Google dev has the slightest idea of how to write JavaScript. Dec 6, 2013 at 2:30
  • @ErikReppen: if you use jQuery exclusively for DOM manipulation, you can write code that hardly needs any callbacks, in case you combine it with other frameworks like backbone.js. Binding events with jQuery very much promotes (anonymous) callbacks. backbone.js has IMHO a more structured approach.
    – Philip
    Dec 9, 2013 at 20:30

For me, it gives me the chance to structure my code better than JavaScript with scope and classes.

It's similar to Java and JavaScript and with Dart editor, I had close to zero adaptation. I started coding straight away.

var ws = new [Moz]WebSocket having to cater for different browsers is annoying. Dart compiles to JavaScript code compatible with popular browsers.

My challenge mainly is interfacing with JavaScript code. I somehow find ways around it but it would be better if it's part of Dart.

  • Agreed, @Abiola, Dart needs better JavaScript interop. It's very much on the radar, I'm looking forward to what the team comes up with.
    – Seth Ladd
    Sep 10, 2012 at 3:16

Java/C# approach is definitely biased in knocking JS since the beginning of web 2.0 That is because of an artificial (or very real & necessary) differentiation between client-side languages and server-side languages. I think this is so server-side language can remain in 'control' of the core problem domains of web apps and to demarcate less serious code (ui code) from business code (server-side). Also Java I think loves to remain a server-side kernel since it lost the GUI war with applets due largely to Flash and HTML 5. Now you have RedTamarin a NodeJS-esque AS3 project alluding to a pluralistic blended future of unified front and backend paradigms.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.