The Dart language

Introduction

I have been using JavaScript for many years now as my primary language and most of the time I have been developing front-end rich applications. Not only applications with lots of data, but also with robust custom widgets/elements that are not native to the web (like scalable design views, video editor times lines etc).

When I first started writing those complex apps it was very very hard to compose such an app and make it run on all browsers. Now days when I have to quick fix something written years ago I see how custom objects have been sprinkled in IE only code and other terrible things.

Then came the libraries. jQuery, Mootools etc. They made it a bit easier.

And then there were the frameworks. Without them a lot of what is possible today would not have existed at all! I will not iterate over the problems of incompatible implementations etc, but the thing is even the best of the best of those frameworks and libraries had issues on their own and most importantly the developer needed to choose one and stick with it for the whole project basically, changing it requires learning a whole new world of class implementation and strategies for building an app.

The last thing to consider was the lack of comprehensive and useful tolling for the language as a whole and in particular for those enormous libraries/frameworks.

Alternative solutions

Meanwhile some of the shortcoming of the language (JavaScript) have been addressed by different organizations differently for a long time now (think GWT, Closure tools,  TypeScript etc). Some are targeted to the JavaScript community, some appeal to the developers community as a whole and try to attract interest from developers not traditionally writing for the web.

One of the earliest was GWT. It was targeted at Java developers who want to write web applications, but are not versed in HTML and JavaScript. Google used it internally and many companies outside of Google are also using it to build data driven apps. However the built-in widgets and utilities tend to be seen as obsolete and not attractive enough for the new markets and the new generation of users that are spoiled by the Apple inspired designs. The promise there is that you can write in the language you already know and you get for free the type safety and the rich tooling typically existing for type safe languages and for Java in particular. On top of that the tools were able to produce optimized code tailored for each target platform. GWT is still an excellent choice today as it continue to evolve and addresses some of the shortcomings raised by the extensive use of the tools and revolves around the evolution of the web as a platform. Mobile is also a big word in the newest history of the project, so if you already know Java and maybe you wish you could target several platforms at once (see keynotes from GTW create conf) this might be the best choice for you.

Closure tools are also a Google conceived product, later on open sourced. It consists of an extensive JavaScript library, a compiler written in Java and a template language that can be compiler to run both on the server and on the client side. The compiler is used to optimize and minify the JavaScript code, supports tree shaking (meaning eliminates dead code paths assuming it is provided with the full code for your application) and does some neat tricks like using the comments in your code to infer types for an abstract type system. Assuming all of your code is sprinkled with the needed comments the whole of your project can be type safe, bringing the benefits of the previous project (GWT) to the JavaScript world. However this comes at a cost - all of the JavaScript in your application must obey a stricter subset of the JavaScript language, mainly the classical pattern for inheritance can only be used and no constructor addressing should be done. Other than that you still write in JavaScript and you get type checking, type inference, safety and because of those - tree shaking and safe advanced rewrite and minification. If you are starting a new project and you expect the code size to be large or you would like to try and see what you can do when you have type safety throughout of your application you can count on this project. Check out the wiki page as well as it links to some helpful third party widgets and libraries that are compatible and highly efficient.

TypeScript came only recently and is produced by Microsoft. It was also open-sources. The approach there is different, inspired by the new features yet to be released for the JavaScript language and mixes it with some optional type information, basically becoming a superset of the JavaScript language. It allows reuse of existing JS code (unlike Closure), however the support for tooling and type safety and inference is only available for Visual Studio on Windows, which limits the usability for the developer community. Unlike Microsoft, Google has always targeted all platforms when providing tools for the developers. Never the less TypeScript, being young has yet to be used in very large scale projects, but in the mean time it is successfully used by several not-so-small ones. If you are looking for ways to reuse your code or a popular library, like jQuery, but get good tooling and you are okay with using Windows, TypeScript might be jut for you.

Dart - batteries included

The latest project, trying to address some of the shortcoming of JavaScript is Dart. Unlike the above mentioned projects it is targeted at all developers regardless of their background. This is because Dart is an entirely new language, mixing features from several other languages and trying to make sense of the web platform.

The language itself is okay, its functional (see functions as a first class citizen), but also has classes, single inheritance, mirroring support, isolates, mixins and some very nice sugar syntax for common use cases. As whole it looks familiar for Java as well as for JavaScript developers, probably for other as well.

Dart VM is a virtual machine for the dart language and can run dart scripts natively. For now it is not available in any stock browser and this tend to be the future at least for non-Chrome browsers. However it has been proven by many project already that it i possible to compile to very high efficiency JavaScript from other languages, so I would not worry if Dart VM will ever be adopted in stock browsers as far as it produces efficient JavaScript.And that turns to be the case as of recently.

The type system in Dart is optional and is really not used in runtime, not in the Dart VM (the virtual machine that runs Dart programs natively) nor in the compiled JavaScript version. The type system is actually there for the developer and for the tools around the language. First of all it is used by the Dart editor which gives you very rich real time information about your code, intelligent code completion, intelligent re-factoring and problem resolution and helpful information. This speeds up my programming at least 3 times compared to the closure tools where I need to look up type information myself while writing the code and only later when I run the compiler I can see if I have a type error. Because the types are optional and because of the excellent type inference you can often omit the type annotations in your code and still get very useful information and help from the editor. As a bonus you also get very efficient JavaScript.

The structure of the language itself is crafted in such a way as to allow high expressive power without sacrificing the safety. Because classes are supported in the language itself the problem with different class implementation that exists in JavaScript land is basically non-existing here. You can be sure that your code is compatible with the rest of the ecosystem and you would never again need to choose inheritance implementation etc.

Because of the type system in the editor and the tools around the language tree shaking is possible and performed every time you deploy, which means that you deploy only the code that you are actually using regardless of the size of the libraries your project utilizes / links to. This puts the constant chase for the smaller code size in a library to its end. Very similar effect you can get with GWT and Closure but not with TypeScript. The later translates directly to JavaScript and will not exclude anything from the compile, so you still need to think how to rectify that after the compile. This is not to say that there are no other method to achieve this (AppCache, server caching, even localStorage and Desktop apps (for Chrome only)), but if you are on a team that likes to make updates and improvements often this might be challenging. On the other hand you get the minimum possible code size for free from your tools if you decide to go that way.

Another interesting option is the ability to run on the server side and while the language is targeted mainly at the front-end developers, it is not impossible even today to share code between the front end and the back end, just like with JavaScript and Java. This seems to be a mandatory feature as of lately.

On top of that Dart has its package management system, similar to npm for JavaScript. There are hundreds of packages there already, but just like with npm the quality varies. One of the nice things still is that the language itself makes the packages compatible with each other, which is a great relief, unlike with NPM where each author decides on the structure and API exposition  to use. With the time, just like with NPM the bad projects will die out and the good once will grow. And as mentioned early growth is not a a problem with Dart as everything not used is excluded from the builds.

So who will be appealed by the language?

For once I can easily see Closure tools guys switching to Dart. They are already disciplined enough to use type safe code and dream of a shorter syntax and more expressive power and the amazing tooling will be an unexpected bonus for them.

I do not see Java developers running toward Dart right away, but with the right packages they might be tempted as well.

There seem to be two types of JavaScript developers: the ninjas will probably not be impressed by the language neither the tools, no matter that arguing on the implementation of the Promises and how we should create our objects is only possible in only two cases: either you are so passionate about the language you tend to be obsessed with the details or you have too much time on your hand. So those "ninja"s will not be impressed at all. Those are also what I call "the low level engineers", the tweakers and the experimenters. We need them in order to move the platform forward and I would say they are doing a great job at that. However they can be of little use in a small company or in a start up as their obsession with the language itself and the detail is often very time consuming.

The rest of the JavaScript developers are the guys like me, who have learned the language to a great deal, but wish there was compatibility at least to some extent in the ecosystem. Those guys write applications, not libraries (thou many of them, me including have written at least one library or a small framework just to get a good grip of the language).For them application level support in the used tools might be something very useful and unexpected considering the state of such support or more precisely the lack of it currently.

There are some great examples out there demonstrating the power of the language - things only a real JS master can do are easy and natural in Dart! Take a look at this for example: extending the regular Array object to count the access to its items. Try to do the same in JavaScript! Operator overriding is cool!

If you have not yet - please go and check out the one hour tutorial. You will be surprised how easy to understand and natural this language flows. If you are coming from Closure tools I bet you can understand and finish the exercise in less than 10 minutes and understand everything crystal clear! If you are coming from TypeScript the same should happen! If you are a regular JavaScript user you might wonder why those types, but fear not - you can add them later!

Of course there is still much to be desired. For example for me it is still unclear with what to replace closure templates for example. I see the community pushing strongly toward polymer and/or angular. Angular for me is just a toy and is more of an obstacle when it comes to very complex highly interactive widgets (image editing, design instrumentation etc - widgets that do not naturally link to a model of a strict JSON representation) and this is indeed what I have been doing a lot lately. Polymer might be better suited because it can encapsulate model handling that is not necessarily observer based and instead, but it is poorly supported in non-Chrome browsers. Even the demos on the dart site are not running on Firefox. Also there are bugs in the Polymer JavaScript implementation (basically styling issues - see my post dedicated to polymer. If and when polymer stabilize it would be a great addition to the dart ecosystem but for now I would really like to build complex apps with it but based on secure and fast templates like the ones used in closure, however I cannot find it.

Regardless of the hiccups and the fact that it is still evolving the goodness it brings is so tempting that I just might use it to build a real app!

You should try it definitely! If nothing else you will at least have a real opinion on it!

A colleague of mine has tried it too early (before 1.0) and was very disappointed. As application developers we should know when to try out a new technology. Let the ninjas handle the demo and beta versions! We want security, stability and robustness. I believe Dart is capable of provided all those and more!

Disclaimer: I am a front-end developer and have been doing this for 8 years. I use mainly JavaScript and HTML/XML/CSS as complementary tools/languages. I have been using in the past several other languages: Python, PHP, C, I have a working knowledge of Bash, TLC and other tools and instruments from Unix/Linux. By no mean is my opinions the ones of my employers nor that of a community, those are only mine.