Let’s talk about how we fell in love with Google Dart. In just a few short years, RESTful web services have become the standard for inter-application communication.
As such, there are thousands of platforms that developers use to write web servers. Some are really popular – like Ruby on Rails or Node.js – while others are gaining traction or serve a niche need – like Erlang’s Cowboy or JVM’s Play framework.
Related: Read about our server-side web framework for Dart called Aqueduct
Most of these platforms do the same things, but tackle them in different ways. It is important to us and our clients that we use platforms that allow for a high degree of productivity, testability and maintainability. In order to identify a platform that we could become experts in that also delivered on these three things, we set out to evaluate the web server platform landscape and find a platform that fit our needs.
We built a list of some popular (and not-so popular) platforms for building web servers. For each one, we went through the steps necessary to build and deploy a very basic web server: downloading the SDK, configuring an IDE and building a simple route that talked to a local database.
Then, we looked at some very specific things during this process:
First, what IDE support is offered by the platform?
We need a strong set of tools for the everyday tasks of programming for the platform. Without good IDE support, programmers could spend more time on tasks that didn’t contribute to the specific project we were working on.
Platforms ranged from having zero IDE support (“just use Emacs”) to have their own dedicated IDE (like IntelliJ’s product line). We prefer to use something on the IntelliJ platform since most of our developers already use Android Studio (built on top of IntelliJ’s platform). The team could quickly become productive due to familiarity with the IDE.
Next, the language needed to be relatively easy to learn and have enough features to support the type of development we like to do.
How easy a language is to learn is fairly subjective. However, since everyone on our team has experience with Swift, Objective-C, Java and now Kotlin, we gravitated towards languages that had similar features and syntax to those languages.
Languages with syntax that fell outside of the C family would be inefficient for our team. Jumping back and forth between dissimilar syntaxes on a given day would require additional training for our more junior developers. This could also cause our clients unnecessary concern about their ability to hire developers to maintain the project in the future. This reasoning disqualified several esoteric languages that, while likely fun to work with, were not pragmatic options for our team.
We knew we wanted to use a language that offers first class support for functions. Much of our code makes heavy use of typical functional programming capabilities like mapping, filtering and folding. We like encapsulating state and behavior in objects, and we need a system strong enough to support that. This narrowed our search a bit more.
We don’t like platforms that hide the languages they are built upon with lots of magic. This can sometimes create a deferred problem: an engineer can get away with only knowing the simple stuff that the platform magic gives them, but they can’t ‘drop down’ and handle more difficult problems that haven’t already been solved. Platforms like Ruby on Rails fall into this category.
Most web servers are relatively simple – they route requests to a handler, handle authentication and authorization, read or write information to a database and return an appropriate response. Therefore, a platform must offer good libraries for querying a database and receiving and picking apart HTTP requests. Whether these features came out of the box or had a strong enough community developing additional libraries didn’t matter – as long as we could be productive right away.
As a corollary, we really wanted a platform that other people were using. Having the ability to ask questions and find answers is important, thus, a relatively popular platform with a strong community was a must.
The platform also needed longevity – while a strong community was a good sign that a platform wasn’t going to be unceremoniously dropped a year from now, we needed more than that. A platform needed a strong economic incentive to stick around – if the platform going away would cost some big companies a lot of money, then it is more likely that the platform would be kept alive.
I ended up being surprised with our choice: Google Dart.
In marketing the product, Google failed to emphasize that Dart has its own easily deployable, stand-alone virtual machine, an incredible set of libraries for building web servers, asynchronous programming and reflection, and is a simple, elegant language that Swift, Objective-C and Java programmers would love.
The language tour for Dart is a great resource for Dart’s feature set and usage. I highly recommend that developers give it a try. Expect to hear more about Dart from us in the future.
