Hi, I'm on the Dart team, I'll try to answer the best I can.
CoffeeScript doesn't really change the semantics of JavaScript at all, it mostly is just a new syntax. I don't fine the syntax to be the worst thing about JavaScript, so CoffeeScript has never seems that compelling to me.
TypeScript does a little more by offering types and classes, but it's still a superset of JavaScript and can't fix major issues because of backwards compatibility. I like TypeScript, but I prefer to go a lot farther.
Dart fixes a lot of fundamental issues with JavaScript, largely related to having a well-defined structure that humans and tools can reason about. This makes it easier for the VM to optimize too.
Here's a grab bag of things that Dart has over JavaScript:
* Dart has libraries, and library scope, no global scope. All code must be imported to be used.
* It has true classes with inheritance, interfaces and mixins. Objects are closed, so you can't accidentally add a new property because of a typo, and you get static warnings about undefined property names.
* Dart has optional type annotations and a static type checker. We catch a lot of bugs when porting JavaScript code to Dart and adding types.
* There are no top-level statements, only variable, function and class declarations. A program always starts at main().
* True lexical block scoping. No function scoping.
* Final variables and library private names.
* There are generics and they are reified.
* 'this' is lexically bound, removing a whole swath of confusing patterns and bugs.
* There is no implicit type coercion or boolean conversion. Being more explicit in boolean contexts reduces bugs.
* There are real collections like Maps, Lists, and Sets. They are interfaces and can be implemented by users.
* Dart has operator overloading
* There is an actor-like unit of concurrency call Isolates
* Metadata annotations (@something) can be processed by build-time and runtime tools.
* noSuchMethod() let's you catch undefined method calls.
All combined, I find Dart to be much easier to code in and much, much easier to read and navigate. Jump into a new Dart codebase and the types give you a lot of information. Even in code that's not typed, because it's statically analyzable you can jump to definitions and get documentation for fields and functions. At Google we see productivity is _much_ higher on Dart projects.
I like the performance of Dart VM for server side. I remember it was so-so initially and then it got a huge performance boost. You could see a sharp jump on
Thanks! Well, thanks to the whole team, it's quite an effort.
Server-side Dart is going to be a really great thing I think. It's by far my favorite server language already: much less verbose than Java, much more readable and maintainable than JavaScript, a similar "feel" to Python and Ruby in some ways, but with more structure and better performance. I'm excited about the future there.
It's not obvious, but you can click and drag the chart to see older results.
The drop in max latency is really notable. I assume that was caused by garbage collection improvements, but I can't find any details about what GC techniques the Dart VM currently implements.
Here's a list of Dart drawbacks. I like Dart's clean DOM API for the record, but here's what stops me using it:
* Documentation aimed at Eclipse users who are familiar with Java and .net that like cutting edge web technologies, rather than existing web developers.
* No npm, and little documentation emphasis on running on servers
* Poor integration with massive amount of existing JS technologies
* Surprising amount of redundant tokens for a language released in 2011. Semicolons, really?
* Most importantly: it's been nearly three years and Dart has made little to no impact on the world of frontend development. Even non-production Dart use is unheard of on frontend circles, and has less users than coffeescript or Typescript.
* Documentation aimed at Eclipse users who are familiar with Java and .net that like cutting edge web technologies, rather than existing web developers.
Eclipse users? How could you tell that the documentation is aimed at Eclipse users? What is it about documentation that could make it Eclipse user biased?
* No npm, and little documentation emphasis on running on servers
Dart is a different language to javascript so its got it's own package manager called pub. If you google "dart package manager" you will find it straight away. If you look at any dart documentation or examples you will see references to it. Did you expect that if you change your programming language you would have the same package manager? No other programming language has npm either.
* Poor integration with massive amount of existing JS technologies
* Surprising amount of redundant tokens for a language released in 2011. Semicolons, really?
A surprising amount sounds like there are very many indeed. Apart from delimiters like semicolons and braces (which have advantages in a modern language and are used by many) can you list some of the other redundant tokens? Dart seems very terse to me.
* Most importantly: it's been three years and Dart has made little to no impact on the world of frontend development. Even non-production Dart use is unheard of on frontend circles, and has less users than coffeescript or Typescript.
Remember that Dart was opened up long before it was recommended as being stable. Even at that, can you name one other language where the user had some choice (unlike, say, js) that had widespread adoption in a 3 year timeframe?
Documentation starts with 'download dart and eclipse' and continues from there. Have you read it?
npm is an ecosystem as well as a software tool, and pub is too. pub is tiny compared to npm.
Yes, braces are redundant in most cases too and can lead to errors where code looks different from how it executes. Main is also unnecessary, but I've been told the dart docs include it without needing to. Not having a default return type is a waste of programmers time, to return void, don't return anything. All these things reduce signal/noise when reading dart.
If you don't think extra tokens mean extra work I welcome you to do some testing and get numbers to prove it.
Python 1 got pretty popular in Unix circles immediately: everyone could see it was better than Perl for most purposes. The cleanliness of the language made people overlook PyPI being, at the time, so poor compared to CPAN.
I don't disagree but I'm wondering if a couple of these are ready to use yet:
- Are metadata annotations really usable (at runtime)? If they're based on mirrors then it's my understanding they're to be avoided when using dart2js.
- I haven't seen isolates used much. What's the status for them?
I have another question. C++ already has types, a main function, collections etc. and is really fast. What are the advantages of Dart over C++ with emscripten?
Dart is much more of a scripting language than C++. It makes as many code issues static warnings and runtime errors as it can, rather than runtime errors, so you can run a partially incorrect program.
Dart is also strongly typed, doesn't have pointers, has GC, has no shared-memory concurrency, uses dynamic dispatch, don't require a compiler (for development), has full access the the DOM (with a much nicer API than in JavaScript!)...
For instance, rather than use callbacks everywhere, most of our async APIs return Futures and Streams. All the "Array like objects", like NodeList, are actually lists in Dart. You can iterate over them and modify them list any other list. element.classses.add('foo') works, as well as some jQuery-isms like element.classes.toggle('foo', show). setInterval is replaced with the standard dart:async Timer class.
There is a ton of cleanup in the dart:html library that makes programming the DOM nice. I'd say there will never need to be a jQuery equivalent in Dart.
You don't, instead you use your existing connections with corporate management and your massive advertising budget to convince managers to force developers to use it. Even if they are perfectly fine using C++ or Smalltalk.
Well it was clear that since Java was statically typed, it would be possible to write a faster VM for it eventually. And Sun bought up the startup that was implementing Strongtalk, an actual improvement over the bad performance of Smalltalk consumer hardware.
You are missing the point. jQuery fixes the DOM API. Dart's "dart:html" already provides a clean nice-to-use API. All those list-like things are actual Lists. Futures and Streams are also baked into the language. Normalization also isn't needed anymore.
> Apple, FF, MS are all against Dart.
Oliver Hunt isn't Apple. Brendan Eich isn't Mozilla. He doesn't even work for Mozilla anymore.
Mircosoft's JavaScript team also isn't equivalent with Microsoft itself. It also would be pretty weird for them to endorse Dart.
They have TypeScript, which sells Visual Studio, which sells Windows licenses, which sells the Microsoft ecosystem, which sells Windows Server licenses.
That's how they operate and there is nothing wrong with that, really. If you have a large existing JavaScript codebase which you want to keep, TypeScript is a pretty good choice.
CoffeeScript doesn't really change the semantics of JavaScript at all, it mostly is just a new syntax. I don't fine the syntax to be the worst thing about JavaScript, so CoffeeScript has never seems that compelling to me.
TypeScript does a little more by offering types and classes, but it's still a superset of JavaScript and can't fix major issues because of backwards compatibility. I like TypeScript, but I prefer to go a lot farther.
Dart fixes a lot of fundamental issues with JavaScript, largely related to having a well-defined structure that humans and tools can reason about. This makes it easier for the VM to optimize too.
Here's a grab bag of things that Dart has over JavaScript:
* Dart has libraries, and library scope, no global scope. All code must be imported to be used. * It has true classes with inheritance, interfaces and mixins. Objects are closed, so you can't accidentally add a new property because of a typo, and you get static warnings about undefined property names. * Dart has optional type annotations and a static type checker. We catch a lot of bugs when porting JavaScript code to Dart and adding types. * There are no top-level statements, only variable, function and class declarations. A program always starts at main(). * True lexical block scoping. No function scoping. * Final variables and library private names. * There are generics and they are reified. * 'this' is lexically bound, removing a whole swath of confusing patterns and bugs. * There is no implicit type coercion or boolean conversion. Being more explicit in boolean contexts reduces bugs. * There are real collections like Maps, Lists, and Sets. They are interfaces and can be implemented by users. * Dart has operator overloading * There is an actor-like unit of concurrency call Isolates * Metadata annotations (@something) can be processed by build-time and runtime tools. * noSuchMethod() let's you catch undefined method calls.
All combined, I find Dart to be much easier to code in and much, much easier to read and navigate. Jump into a new Dart codebase and the types give you a lot of information. Even in code that's not typed, because it's statically analyzable you can jump to definitions and get documentation for fields and functions. At Google we see productivity is _much_ higher on Dart projects.
Hope that helps a little!