On Monday, Google announced a new programming language named Dart. It aims to be faster than JavaScript and better suited to large scale software projects. After thinking about the language for the last couple days, I think Google's engineers have started a compelling replacement for JavaScript.
Any client-side web programming language will be used by programmers from all backgrounds. Dart's optional typing lets both static typing enthusiasts and dynamic language enthusiasts have what they want (with some minor compromises). Throughout this article, I've linked to Dart code samples on the Dartboard so you can try for yourself.
"I Hate Static Types"
Many web developers come from a dynamic languages background and actively dislike static typing. Many more probably have no idea what static types are and simply grew up writing JavaScript code. Both groups of developer should be happy with Dart. They never have to enter a type declaration and Dart is still an improvement over JavaScript.
Dart provides block scoped variables rather than the function scoped variables used in JavaScript. Accidentally overwriting a function scoped variable is one of the most common JavaScript errors I encounter. It's more likely to become a problem as functions evolve and grow. With Dart, for example, this is less likely to happen.
Dart also provides a succinct function syntax rather the verbose JavaScript one. As often as client-side programming uses callback functions, this sort of code is a pleasant change of pace.
Dart even has string interpolation. Anyone who's programmed in Perl and JavaScript for longer than 5 minutes knows how nice this will be.
Some developers may not care, but Dart provides immutable variables with compile time errors. As far as I can tell, JavaScript "const" just silently ignores subsequent assignments. I've debugged quite a few JavaScript programs where code modified a variable it shouldn't have. Declaring a final variable and receiving an error would have saved me lots of debugger time.
Dart makes some other improvements which aren't as noticeable. For example, Dart's namespace rules should eliminate bugs from global variables. The language spec makes several accommodations which should eventually make Dart run faster than all current JavaScript engines. Lars Bak, who developed the super-fast V8 JavaScript engine is one of Dart's main developers. He ought to know a thing or two about making a language that can run fast. Dart's library system also allows for optimizations that could substantially improve website load times someday.
Even if Dart just used dynamic typing, these changes alone are enough for me to switch.
"I Love Static Types"
Many other web developers come from a static typing background and want types when developing for the browser. GWT and Closure Compiler show how far these developers will go to have their static types. Dart's type system gets them most of what they want.
One benefit of static typing is describing a developer's intentions. JavaScript developers often use specially formatted comments for this purpose. One can think of Dart type annotations as a more succinct version of the same thing. Since Dart type annotations don't change a program's semantics, they really are just fancy comments. As always, the comments can be wrong if your tools don't enforce otherwise.
The Dart compiler performs type checking. If you want to catch type problems at compile time, just pay attention to the warnings (hover over line 4). Even though they're not errors, the compiler did the hard work for you. Dart also provides a development mode for runtime type checking. These checks are disabled in production, but it reminds me of the well-tested robustness principle, applied to programming languages.
Since type annotations are part of the language, it's likely that future tools will handle type inference. Closure Compiler already does this for JavaScript, so the tools will probably arrive soon. Type annotations also provide additional hints the JIT could use to further improve performance. With JavaScript, the JIT must rely entirely on its own observations.
Be Patient
Many of Dart's critics act as though the language is finished. Yes, the Dart to JS compiler produces horribly bloated JavaScript. No, Dart doesn't have mixins. Yes, Dart's VM is slow. A quick glance at the version number (0.01) suggests we should be patient. The Dart issue tracker and mailing list are full of good discussions about solving these problems. The language designers are open to evolving and improving the language.
Dart isn't perfect and can't be perfect, but I think it will become a meaningful, valuable improvement over JavaScript
No comments:
Post a Comment