We are Switching to Dart. Why? by @__tosh

So what motivated us to switch to Dart? In this post I’ll try to answer this question and go into how I see Dart as a huge step forward for the web & mobile development ecosystem.

What’s Blossom?

Blossom is a lightweight project management tool for people who craft modern mobile and web applications. It’s basically an online Kanban board for your product team.

From a technical point of view Blossom is a cutting edge single-page web application with Google App Engine as the backend (JSON API).

In the last few years we’ve learned a lot about building non-trivial JavaScript applications and have seen a ton of frameworks & libraries come & go. Yet despite all that innovation building web applications with decent user experience using JavaScript still is really hard and I believe way harder than it should be.

I feel the JavaScript ecosystem suffers from NIH more than any other language community that I know. Here’s why.

JavaScript Plumbing Fragmentation

At Blossom we are huge fans of JavaScript and in many ways it is a wonderful language if you know how to avoid its dark corners. That said, I feel the JavaScript ecosystem is severely lacking inmanyareas. Especially when it comes to core plumbing.

There are great projects like Underscore, Sugar, Prototype, jQuery, CoffeeScript and many many more that help to work around JavaScript’s language quirks. Unfortunately they don’t mix and match very well. Also, which map() or forEach() implementation should I use if I have multiple available?

This situation causes a lot of confusion, apparently not only for me. I wasn’t surprised to find a ton of StackOverflowquestions from people looking for advice. There are also a ton of blog posts that recommend different combinations e.g. mixing CoffeeScript with Sugar.js (love those names).

Higher level frameworks pick different combinations to build their foundation, some even build it completely from scratch.

We also had to go through this decision/evaluation process for Blossom and after weighing the pros and cons of different combinations we went with the following stack.

• Underscore – utility functions to work around JavaScript language quirks

• jQuery – a DOM abstraction layer

• CoffeeScript – classes and lexical scoping

• Backbone – structure around frontend code and widgets

• Brunch – an application assembler that ties all of the above components together

While we were pretty pleased with picking this specific set of building blocks over others that we’ve tried, I find it pretty frustrating that you have to jump through so many hoops in order to arrive at a situation where you can start to get things done. I don’t know how this must feel for newbies to the ecosystem, but I guess the learning curve is rather steep and the question marks are plenty.

Also it doesn’t help that some libraries are assuming a certain set of plumbing while others strive to be agnostic and therefore implement their own plumbing. I don’t even want to know how many different forEach implementations from third party libraries there are in our code base.

I don’t see a problem with different choices in frameworks, I believe diversity is very useful – at the right abstraction layer. That said, I don’t think this kind of fragmentation in the plumbing helps the JavaScript community in any way.

And I don’t even want to get into other areas like dependency management between libraries, handling of namespaces or various approaches to modularity (bower, component.io, npm, commonjs, amd, jam, …).

It is a complicated mess. It makes my head swim.

Dart comes with Batteries included

From my point of view Dart solves all of these problems and even goes a few steps further.

So what’s Dart? It’s an object oriented programming language for building modern web and mobile applications. Dart compiles to very efficient JavaScript and therefore supports all modern browsers out of the box. But Dart is not only a very pragmatic programming language, it comes with batteries included.

Dart comes with a great standard library, support for classes, support for libraries & namespaces, testing built in, a package repository, support for dependency management, a blazing fast virtual machine, Web UI (similar to angular.js), strong tooling support and last but not least, a ton of great documentation.

This makes Dart a cohesive foundation to build upon. A one stop shop if you will.

Also, if you follow the links above and dig in you will find that Dart not only comes with a ton of infrastructure support out of the box – the actual implementations of these parts are very well thought through by smart people with a ton of experience in API design, software engineering and computer science. The parts fit together and make sense. They are pragmatic and unsurprising. Exactly what I need to be productive.

To give you a few examples – Pub,  Dart’s package management tool uses semantic versioning, the Dart compiler uses tree-shaking to reduce code size by getting rid of code that isn’t used, DartDoc supports markdown, the standard library comes with data structures like List, Set, Map and many other wonderful things like Futures.

Dart is built with Performance in Mind

The cohesive development experience of building stuff with Dart was definitely our main motivation to switch. Being able to focus on making your product better without having to fight the ecosystem feels amazing.

That said there is an additional upside on top of that. Dart is built with performance in mind.

John McCutchan recently gave a talk on Dart performance. It is super fun and interesting to watch and well worth the 30 minutes. He explains how Dart as a language makes it comparably easy to do performance optimizations and some of the challenges people face in trying to speed up JavaScript.

He’s also the guy who brought SIMD support to Dart which enables blazing fast CPU supported Vector Math. This will make a huge difference for people who want to create modern games and graphics intensive applications for the web.

Using Dart in Production

Some parts of Blossom are already written in Dart, compiled to JavaScript and deployed to production. One is a very simple web component that calculates and displays the cycle time of a feature card.

The biggest part written in Dart is responsible for handling invitations to organizations and authenticating users in that workflow. This is an essential part of our application which helps hundreds of our paying customers to organize their product teams.

Our migration plan for the whole app is quite pragmatic. Every new feature gets implemented in Dart. If we want to make improvements to parts of the JavaScript code base we rewrite it in Dart (porting from JavaScript to Dart is pretty straight forward). On top of that we have a weekly Dart sprint where we migrate existing code to Dart.

The only scenario where we work with the existing JavaScript code base is when we find bugs that make sense to fix as soon as possible and a Dart rewrite would take longer than acceptable (almost never the case).

Even while some APIs are changing from time to time since the language is in its early days it is a worthwhile trade-off for all the good stuff we get from the ecosystem. So far Dart has been a pleasure to work with.

I can’t describe in words how liberating it feels to have a consistent web development experience that makes sense. Hard to say when the last time was when I felt a similar joy & productivity increase in writing web applications. Probably back when I switched from PHP to Ruby (on Rails).

Getting Started with Dart

Dart is really easy to dive into. You’ll be surprised how fast it is to get up to speed if you come from C#, Java, JavaScript, PHP, Python, Ruby et al.

If you’re curious about giving Dart a try go check out Game of Darts, a set of hands-on tutorials to get you started.

I’m looking forward to a Blossom frontend code base that’s entirely written in Dart. We’ll keep you posted on our progress & also might have some interesting Dart related announcements in the future. Stay tuned :)