Dart

| Tags: dart, dev, web

Some time ago as I was looking into JavaScript frameworks for the development of mobile web applications I stumbled upon Google Closure. Compared to jQuery and jQuery mobile Google Closure is a somewhat underhyped toolset for the development of client-side web applications.

Several features of Closure made me take some time to dive into it:

  • The closure library contains many small useful frameworks that fit together. So there is no need to mix and match different frameworks for functional programming, ui composition etc.
  • There is a working module concept. You can separate your application into different parts and specify which of the many frameworks in the closure library you really need.
  • You can use static typing and there is a compiler that checks it. So many errors can be found by the compiler. You don’t have to find them while running the app in the browser.
  • Since the compiler knows what is used from the huge closure library and your own code, it can delete unused code from the compiled application and run some other advanced optimizations that make the resulting code much smaller and faster.

Especially the static typing and having a compiler that checks the code before it is executed, appealed to me. Debugging in a browser is quite comfortable nowadays but if there is a chance to get rid of bugs without having to debug, I’ll take it. As someone having developed in Java for over a decade now, using an IDE and a compiler feels natural to me.

But there is a downside. The static type information for Closure has to be typed in into comments since JavaScript itself as a dynamically typed language doesn’t provide any constructs for this. Having to put type annotations into comments is quite cumbersome and after some time my initial enthusiasm for Google Closure somehow waned. Was it really worth the additional effort?

Dart seems to be the answer for all those loving Closures’ features while disliking the notation needed to get them. Dart is a new class-based language by Google created for the development of client-side web applications.

Dart has optional static typing. You can provide static typing information and if you do, the compiler that generates JavaScript from your Dart code, will check it. If you choose not to provide that information, it will obviously not be checked.

Static typing in Dart only affects compilation. It isn’t used while running a Dart based application.

Dart also comes with real classes and inheritance among them. The notation for classes and inheritance is much simpler than the prototype-based notation in Closure. It all just looks cleaner and more readable in Dart than it does in a Closure class.

The Dart team provides an Eclipse-based IDE for Dart called Dart-Editor. It’s still in the alpha phase and lacks many features that simply belong to a good IDE like refactoring support, but even in this very early stage it’s useful for the development of Dart applications and the exploration of the Dart libraries.

Currently much is happening in the Dart universe. The language is far from fixed. Frequently new proposals or changes that will break code from a month before are announced. Some weeks ago for example a change of the meaning of the == operator was proposed. Currently Dart is not for the faint of heart but it’s fun.