I've read about Dart, but I haven't used it much in practice. What does it do better than similar languages that compile to JS (CoffeeScript, Typescript, etc)?
Specifically, why would one consider moving to Dart from any of the above languages?
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.
> What does [Dart] do better than similar languages that compile to JS (CoffeeScript, Typescript, etc)?
CoffeeScript doesn't really help with scaling. It's basically just a slightly more compact JavaScript dialect. Personally, I don't see the point.
TypeScript is closer. It offers type annotations and more structure. Being a strict superset of JavaScript also means that it can't fix any of JavaScript's issues. However, it also means that it can seamlessly interact with JavaScript.
Dart is a clean break. Straightforward, nice semantics, and none of the weird stuff. There are official code conventions, a package manager, a doc generator, and a built-in way to do inheritance. Compared to JS, this skips a lot of research and pointless discussions. Naturally, it also avoids the associated compatibility issues and annoyances.
The VM is also a big advantage, because you don't have to compile your code hundreds of times a day during development.
As a result, the compiler can perform rather heavy optimizations, because compile speed isn't the top priority anymore.
Having that VM also allows you to write command line tools and web servers. It can be also embedded in other applications.
Anyhow, if you know something like C#, you already know most of Dart's syntax. Just give it a try. You can be productive on your very first day. It's really that straightforward.
dart2js is not just a feature to ease migration. It's the primary means of deploying Dart code, and will be so for a long time, even if/when the Dart VM gets into Chrome.
There is a native VM for it that is fast and it has the highest chance of getting implemented in a browser (let's say higher than Typescript).
There is good tooling behind it (IDE, package system).
Google supports it. Whether we like it or not that makes a huge difference.
Native VM has good IO characteristics and can be used on the server side as well. (So can start using that on the server side without having to wait for browsers to embed it).
Does away with Javascript warts better than CoffeeScript.
That little side note there makes no sense at all. The runtime semantics of TypeScript are exactly the same as JavaScript. TypeScript is little more than some ES6 notation (class, =>, etc) plus compile-time type checking.
You could remove all types from a TypeScript file and it'll probably run fine on any existing JS VM that supports ES6.
Dart is faster because it lacks features that JavaScript has, such as dynamic loading or eval or adding fields to objects/classes, and has some special case hacks for SIMD.
One could easily tweak JavaScript to have the same lack of features and same performance gains (many could be done in asm.js style) so I do not see how Dart is relevant except as a way to not participate in the evolution of JavaScript.
Personally I feel that getting even a 50% boost on a scripting language that's never going to be as fast as C# or Java anyway, by making an additional incompatible VM, is totally foolish. Both VMs will be needed for many years, and this collateral bloat is just not worth the benefit. When you look at performance over JavaScript + asm.js the gains are seen largely where performance does not matter much anyway.
Exactly so unless it goes the asm.js route there is probably not much chance it will improve a lot over regular JS. Dart VM is already faster than JS VMs and it will probably get even better and faster in the future.
Imperfections in an art form like Glitch are the substance, not the dirt. Same way, imperfections in JS make it so much fun to work with, for the sufficiently insane. Taking a puritanical approach to programming and weeding out the imperfections leads to a very boring language. I understand the business argument, but creativity requires a certain amount of chaos, no? Or it depends on your theory of creativity I guess. Fair enough.
JS is not an artistic statement, it's a programming language foisted on us by corporate politics and Industry.
Also, mental chaos begets creativity. Chaos emerging from tools only serves to impede the expression of those using the tool. I'm not sure how you can argue how a tool that works against the user in a non-performance art is a good thing.
>Imperfections in an art form like Glitch are the substance, not the dirt. Same way, imperfections in JS make it so much fun to work with, for the sufficiently insane
Programming is not like "art" in that anything goes as long as it's an artistic statement. Programming is pragmatic and goal oriented, and the goals are not the expression of the inner self.
Sure, you can do some programming with an artistic intent (e.g code obfuscation stuff), but that's the exception rather than the rule. "Code as poetry" and "Hackers and Painters" are tired metaphors.
As for "glitch", those imperfections are not actual imperfections, but desirable and genre-defining elements. Glitchs exists because it HAS those. Programming doesn't exist to have imperfactions -- it exists to execute some kind of task.
That's about as valid as "Street cleaning is an art form, if for you street cleaning is art".
To quote an old essay:
= = =
"Let me say it simply - hackers are nothing like painters.
It's surprisingly hard to pin Paul Graham down on the nature of the special bond he thinks hobbyist programmers and painters share. (...) The closest he comes to a clear thesis statement is at the beginning "Hackers and Painters":
"Of all the different types of people I've known, hackers and painters are among the most alike. What hackers and painters have in common is that they're both makers."
To which I'd add, what hackers and painters don't have in common is everything else. The fatuousness of the parallel becomes obvious if you think for five seconds about what computer programmers and painters actually do:
Computer programmers cause a machine to perform a sequence of transformations on electronically stored data.
Painters apply colored goo to cloth using animal hairs tied to a stick.
It is true that both painters and programmers make things, just like a pastry chef makes a wedding cake, or a chicken makes an egg. But nothing about what they make, the purposes it serves, or how they go about doing it is in any way similar.
Start with purpose. With the exception of art software projects (which I don't believe Graham has in mind here) all computer programs are designed to accomplish some kind of task. Even the most elegant of computer programs, in order to be considered a program, has to compile and run [1]. So just like mechanical engineers and architects, computer programmers create artifacts that have to stand up to an objective reality. No one cares how pretty the code is if the program won't work.
The only objective constraint a painter has is making sure the paint physically stays on the canvas (something that has proven surprisingly challenging). Everything beyond that is aesthetics - arranging colored blobs in a way that best tickles the mind of the viewer.
This difference is what makes programming so similar to engineering, which also tries to create beautiful things in the face of objective constraints, but it's a parallel that really rankles Graham.
Design choices, in terms of the code structure and what is maintainable to you vs another person, are subjective in that they are often driven by personal choice and a sense of what is elegant. Your thinking is too left brained.
Says who? someone who doesn't the discipline to stay polite online? You think all design choices are driven by objective thinking? Funny, but not a valid response IMO.
The great thing about Dart is that it breaks backward compatibility with js. The bad thing about Dart is that it breaks backward compatibility with js :)
I think that the parent was referring to the fact that it is it's own language with its own VM/runtime. The idea is to create a new language with JavaScript as a compile target. Things like CoffeeScript, TypeScript, etc are much more conservative approaches to dealing with the issues JavaScript has.
Specifically, why would one consider moving to Dart from any of the above languages?