A few years back, I was taking some time, together with our small, distributed team, to review modern approaches to web app development. For years, Woven had been working with Drupal and the LAMP stack, building online community websites for our clients. But now we were setting out to build our own web app, and I knew we needed a new stack.

So we made a rough list of what we were looking for (things like performant, scalable, future-leaning, moderate learning curve, mature ecosystem, great docs, solid templating solution, and more). We listed many of the modern tools and frameworks we knew of (Python/Django, RoR, Scala, GWT, Go, Node.js, Dart). We set about reading and experimenting and discussing.

Not Node

Soon we were focused on Node.js. We already knew it was a serious contender and knew about its appeal: JS on the client and server, non-blocking event-driven I/O, a focus on modern, performant, realtime apps. So we explored Node frameworks like Express, Derby and Meteor. Derby in particular looked really promising. But we found the Node ecosystem to be more of a maze than felt acceptable to us: little documentation, lackluster support in the forums, half-baked frameworks each with their own lingo and syntax, the regular confusing patchwork of JS libraries. While Node was all the rage, I was not especially enthusiastic after actually digging in.

Dart

I had been tracking Dart, and so I dug in there too. First of all, it was similar to Node in concept with its events and asynchrony, and that felt right to me. I appreciated its stated aim of bringing sanity and structure to modern web app engineering. I liked that its creators had worked on the V8 engine, which powered Node. And that its corporate backer had created some of the most scalable and performant web apps in the world. Speaking of Google, I, perhaps paradoxically, appreciated how Dart appeared to live wholly on its own, unlike GWT which lost me at its very name.

I liked how much of what are widely accepted as JS’s quirks were being addressed in the brand new but grounded Dart language. I was intrigued by the promise of “batteries included”, with Dart bundling a strong set of core libraries for both client and server, a package manager, an IDE with a great analyzer, deployment tools and more. The class-based, OO language resonated with me — long before LAMP, I had started with Visual Basic. It seemed like there was a concerted effort with respect to docs, and that someone from the Dart team was always ready to answer a question.

I wish Dart would use this as their logo.

It felt like Dart was the future — a better Node.js. There was hardly an ecosystem, nary an exciting example of its real world use, and it was well short of stable. But from the beginning, we felt like we could keep moving with it, and so we did. My small team changed as we wrapped some final client projects, and I soon hired from within the Dart community — a talented Finland-based developer who had been providing excellent answers on SO, and who remains a friend and advisor even as he moved to a company in his own part of the world after a long and learning-filled year together. Our first line of code soon became 50K+ lines, client and server, leveraging the pre-cursor to Polymer called WebUI on the client. As far as I knew, we had the most comprehensive pure-Dart app, and the first in production.

There were challenges. Dart, and particularly WebUI, would often break from release to release. WebUI and its SPA approach meant our app’s size and thus initial load time grew. Our app had horrid SEO as it was all JS-rendered client side — not an issue specific to Dart, but nonetheless a painful lesson I wish I’d learned sooner as ours was not a closed Gmail-like app but one that could have really benefited from strong SEO. And the disconnect from the JS world can make life more difficult, for example when encountering a service with libraries available for JS but nothing for Dart.