Skip to main content

Why Blossom is Switching to Dart

Thomas Schranz, CEO and Founder of Blossom, an online Kanban board for product teams,  explains why switching to Dart was an easy decision for his company.  We wanted to publish excerpts from Thomas Schranz's post, but had trouble figuring out what to leave out! We reproduce his post in its entirety here:

We are Switching to Dart. Why?

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 in many areas. 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 StackOverflow questions 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 (bowercomponent.ionpmcommonjsamdjam, …).
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.
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 usessemantic 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 :)

As always, view the changelog for the full list of changes, and to get started with the Editor, see our tutorial.

Popular posts from this blog

A stronger Dart for everyone

We are constantly asking ourselves:
How do we make developers even more productive when writing Dart apps? We believe that a critical part of the answer to this question is to make strongmode – a sound static type system for Dart – the standard for all Dart developers.

Teams that use Dart to build apps like Soundtrap, AdWords, AdSense, and Greentea say they really enjoy using strong mode features, such as early error detection. In fact, teams that have switched completely to strong mode cite not only early error detection but also better code readability and maintainability as major benefits. We hear this both from small teams and – even more so – from large teams with hundreds of developers writing and maintaining millions of lines of Dart code. As Björn Sperber from Soundtrap says,
Strong mode and the smooth integration with IntelliJ is a joy to use and a huge improvement. If you’ve tried out Flutter, you’ve already used strong mode checks from the Dart analyzer.

Given the benefits …

AngularDart 3.0: Easy upgrade, better performance

AngularDart 3.0 is now available. It brings better performance and smaller generated code, while also making you more productive.

Version 3.0 is an evolution: although it has some breaking changes (detailed below), it is a smooth upgrade due to minimal public API adjustments. Most of the progress is under the hood—in code quality, stability, generated code size, performance, and developer experience.

Code quality:
2731 instances of making the framework code more type safe (using sound Dart).The AngularDart framework code size is down by 12%.Many additional style updates to the codebase:Changed to use idiomatic <T> for generic methods.Removed NgZoneImpl, all the code exists in NgZone now.Stability:
Many CSS encapsulation fixes due to update with csslib package.Fixed bugs with IE11.

For the Mail sample app, we see 30% faster time-to-interactive (currently 3812 ms on a simulated 3G connection, measured via Lighthouse).Our large app benchmark shows 2x faster render times of…

AngularDart 4

AngularDart v4 is now available. We've been busy since the release angular2 v3.1.0 in May. Not only did we "drop the 2", but we also improved the compiler and tightened up the framework to give you smaller code, we updated the package structure to improve usability, and we added several new features. Check out the updated documentation to get started.
Just angular Upgrading to v4 will require more than updating your version constraint. The package has changed names (back) to angular – dropping the 2. You'll need to update your pubspec.yaml and the corresponding imports in your code. In most instances, find-and-replace should do the trick. Going forward, the package will be called package:angular. We'll just update the version number.
Smaller code The updated compiler in 4.0 allows type-based optimizations that not only improve runtime performance but generate better code because we are able to strongly type templates. A big result of the update is that many ap…