Wednesday, December 28, 2011

Why DART?

‹prev | My Chain | next›

My next book is going to be on the Dart programming language, lovingly entitled Dart for Hipsters.

tl;dr

  • Dart looks to be an interesting language
  • Dart addresses real-world, legitimate limitations of Javascript
  • Google is not evil for proposing Dart
  • Follow along daily in this blog or sign-up for the mailing list

Why?!

Why Dart? More to the point, why Dart given that Javascript is the lingua franca of the web and has already won?

Simply put, it is silly to suggest that Javascript is the best that we can ever do. Don't get me wrong, I love Javascript. Of the 700+ posts on this blog, I'd estimate that 600+ discuss Javascript in some way. I love node.js, jQuery, and Backbone.js (heck I co-authored a book on it). I don't think Javascript is going away any time soon.

But that does not mean that we should be satisfied with Javascript. Nor should we be satisfied with the proposed additions to the Javascript standards.

For the past several years, I have developed something of an obsession for speed. One of the things that drew me to node in the first place was the speed promised (and more or less realized). After node, I began to look at HTTP as a bottleneck for responsive applications. The result, of course was The SPDY Book. Even as I grew to understand and appreciate the power offered by SPDY, it became apparent that it only solves part of the problem. It gets stuff to the browser blazingly fast, but does nothing to speed up application boot and execution.

I see many parallels between SPDY and Dart. With SPDY, rather than trying to work around the limitations of the status quo, (e.g. HTTP "optimization"), Google produced a completely different protocol adapted for the modern web. With Dart, it seems that Google is once again trying to do something completely different rather than patch more cruft onto a language barely newer than the internet itself.

I am not buying the argument that Dart (or SPDY) are Google's attempt to subvert the web. Google has been very good about embracing the community with SPDY. Google has been extremely open about the standard. I could not have written The SPDY Book if they were trying to keep tight control of SPDY. Surely Amazon could not have used SPDY to power the Kindle Fire if Google were hell bent on tight control of the protocol.

Similarly, I see Dart as a logical response to an obvious performance bottle neck in web applications. Javascript is slow. It lacks fundamental things that most "real" languages take for granted: libraries, iterators, dates. To be sure, there are workarounds that more or less address most of these concerns, but why settle? Why not start from the ground up with support for the things that cause the most pain?

Is Dart the language to do all that? Is Dart today better than Javascript? I dunno and prolly not.

But it has potential. And it's trying something different. And it's inherently different than the status quo.

That makes it worth learning.

Join me as I blog about this every day for 3+ months straight. At the end of January, an alpha version of the book will be available to purchase at a discounted rate. At the end of February, the beta will arrive. The first edition will be available at the end of March. Want more? Sign-up for the mailing list.

4 comments:

  1. Alpha version by the end of January? First edition by the end of March?

    Dart isn't near complete yet. Reflection hasn't been finished. Josh Bloch just started on the team and will probably overhaul the entire collections library. Javascript interop hasn't been fully hashed out.

    Dart's changing so fast that your book will be obsolete the day it comes out.

    ReplyDelete
  2. @Justin That's definitely a danger. I got lucky with SPDY book, but Dart could pass me by.

    To mitigate, I plan to absolutely *not* write a definitive guide. As you point out, too much is in flux so how could I?

    Instead, I am going to focus on fundamentals of the language and comparisons with Javascript (esp wrt to how to do similar things in both). I'll re-evaluate about 1.5 months in to ensure I'm going in a decent direction.

    And if that doesn't work, there always the 1.1 edition in mid-July :)

    ReplyDelete
  3. Yes, luckily with eBooks you have the ultimate in flexibility... Maybe your book version numbers should just track Dart's?

    ReplyDelete
  4. Ooh! I like that idea. With Recipes with Backbone we kept (most of) the JS in separate files so that we could ensure they compiled. With this book, I could do the same to ensure that they stay compatible with the languages.

    ReplyDelete