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! 🙂

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…

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.

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.