At that time, I was primarily programming in JavaScript; both on the backend with Node.js and the frontend with various bigger frameworks (like Ember.js or AngularJS) or smaller libraries and tools, and there was one thing I had learned: never to start a big project with JavaScript again.

There are many things to love about JavaScript: it’s omnipresent, easy to dive into, well supported by practically every Editor and IDE, has a huge user base, and libraries for everything you can think of. But there are also many things to dislike about it and I knew right from the start that I didn’t want to fall into the same trap as before: rapid initial development at the cost of messy code that is hard to maintain.

The server languages we considered were:

Old-school and battle-tested Java (Spring, for example)

Ruby (with Ruby on Rails as a prime candidate)

Go (a solid language but a bit outlandish)

Dart (the new kid on the block, with no prime examples)

The client languages were:

JavaScript (the only native language in the browser)

TypeScript (Microsoft’s JavaScript superset)

Dart

CoffeeScript was not really considered because I had developed a hatred for it (after writing many lines of code in it).

Why we chose Dart

My preference at that time was Dart. Not only was I personally involved in, and attached to, the language (my brother Florian Loitsch was working on the compiler at that time and has since been promoted to the library manager) but it seemed to have a lot going for it:

It was typed, but not as heavy as Java, since it introduced a fairly novel concept of optional types. This alone solved many issues I had with JavaScript.

It came with it’s own runtime, meaning that we could use it directly on the server as well (and not compiled to JavaScript running on node.js).

It came with many great core libraries, making it very comfortable to work with the DOM without needing third party libraries.

It had its own package manager (unlike JavaScript where you have to choose one of the many package managers).

It had an opinionated style guide that we could follow, instead of defining and writing our own guides.

It was the only language that had the possibility to make it as a native browser language with its own VM (which, unfortunately, never became reality).

It was potentially faster than JavaScript and Ruby since the developers who created the language came from the JavaScript V8 engine and designed the language to be more optimisable.

It is very familiar to, and easy to learn for Java and/or JavaScript developers.

All of these pointed to Dart being a great candidate! We would have the same server and client language — a language I would enjoy writing in (unlike Java or JavaScript), that I was familiar with (unlike Go) and where it would be easy to get new developers due to its familiarity with JavaScript and Java.

There were obvious downsides as well of course. Dart was in its infancy, and there was no way of knowing whether all the promises made by the Dart team would be fulfilled, whether we would have all frameworks necessary to finish the project or if the development of Dart would simply be canceled one day.

We discussed all these pros and cons and finally came to the conclusion: let’s take the risk, and build something with tools we’d love, not tools that are safe.

It was a bold move, but Exit Live was all about being bold.

Our first year with a language nobody knew

The first months were full of ups and downs, and we needed to roll with the punches. There were times at which I wasn’t sure whether everything was going to collapse, but in the end we made it through.

The programming aspect

At that time, the best way to work with Dart, was with their dedicated and now discontinued IDE DartEditor, which was a customised Eclipse build. Although I had never liked working with Eclipse before that, they did a great job reducing all the unnecessary clutter and optimising the experience for Dart. Working with their editor, and using their workflows made sure that everybody in the team got the full “Dart experience”: code completion, type suggestion, navigate to definition, etc… I think that this saved us a lot of time during our setup phase, because we didn’t need to start configuring tools and writing guidelines, which is especially difficult with a new language.

Apart from minor annoyances and issues here and there, the development process was quite enjoyable. What wasn’t enjoyable was the growing concern about their capability to deliver a server solution in time…

Choosing our server infrastructure

Before I started working at Exit Live, I was working on a very ambitious shopping platform. As was modern at that time, we built our whole infrastructure on “microservices”. We had a file server, a template renderer, a backend, a frontend renderer, etc… all either Node.js or Java instances communicating with each other through JSON APIs. Although the concept is nice, it was a nightmare to deploy and debug, especially since we were running our own servers with our own scaling tools.

I am not a “server guy” and I don’t enjoy fiddling with server configs, so with Exit Live I wanted to go the complete opposite route: use Google’s App Engine solution — a completely hosted, autoscaling server infrastructure with load balancing and health checks.

The Dart team told us, that it was not long, before Dart was one of the supported languages for App Engine, so we decided to wait for it and start building the app blindly until we get all the specification on how to run a server on App Engine.