How car2go chose a frontend framework
In December 2016, car2go started building a new development team in Berlin and later Hamburg to in-house development of some internal products. People experienced with nodeJS, frontend, rails and some other skills were hired and pretty soon, the frontend framework question came up.
Building a new frontend dev team in 2017 means you inevitably get a framework debate as soon as the first few developers join the team. While I was already a big fan of a specific framework, we wanted to give the team the chance to decide on their own and settle the debate for at least the next 2 years. In this article I’ll explain how we approached this and what choice we made in the end.
The Problem
Getting a diverse group of people with different experience, backgrounds, programming ideologies and skills into one team means they all have their idea of an ideal product, workflow and coding style.
The different experience levels meant that some developers decide on a framework out of pure preference or because they know it from previous projects. Others factored in business needs and app requirements. My role was to also look at the longevity, community support, on-boarding overhead and finding developers who’re happy to work with this framework.
An important aspect was that this decision was not made somewhere in management but inside the dev team with some product owners and me to give input on some high-level requirements like on-boarding time for new developers.
The idea was to limit the choice to a few frameworks which fulfilled most of the business needs and let developers build a small product in a hackweek with these frameworks. After that, they should present their findings on specific criteria and — after a discussion based on these apps — decide collectively and objectively on a framework.
This can’t be done blindly though, so we had to define some rules.
Hackweek Rules
- Every developer builds the product from scratch and on their own
- Devs have to choose a framework they either don’t like, or don’t know. This greatly reduced bias and improved their ability to judge said framework in their presentation objectively and compare it to the framework they already like and use.
- The product to build has to include some gotchas that’d lead the devs into a territory where they have to dive deeper into the framework. A simple todo-demo is not sufficient
- All devs are building the same product (described later) to better compare results.
- Devs have to observe the set criteria during the hackweek and elaborate on them during the presentation
Framework Candidates & Criteria
Right off the bat we decided on some frameworks. For example it doesn’t make sense to include backbone, ember or angular 1 in a 2017 choice on frontend frameworks. The obvious three candidates that had community support and seemed future proof were reactJS, angular 2 and vueJS.
VueJS was the least known while react and angular already had lots of fans and discussions in the industry and our teams. While building the product with one of the frameworks, a developer should note down the experience on specific topics.
Among others, the criteria to observe were
- Documentation
- Maintainer activity
- Questions and answers on the usual platforms
- Available tooling
- Amount and quality of plugins or extensions
- Web technology standards
- Setup Time (setting up the build and support for things like sass, custom fonts, etc)
- Code style, API Design
- Extendability
The Product To Build
The product was pretty straight forward: show a leaflet map (without using an existing, framework-specific leaflet component) with all of our car2go vehicles that update in a 10 second interval. Each city/location should be reachable via a select box and the URL.
Fetch geojson polygons for the active location and display them on the map. Then calculate how many cars are in each polygon and display it as a label on the polygons — all updated every 10 seconds.
This required the developers to decide on solutions for routing, state management, HTTP calls and to include leaflet, which is out of scope of the frameworks DOM update mechanism but still has to react to state changes.
This is very helpful when you want developers to explore how the component lifecycle or reactivity works in detail.
Presentation Day
On a friday, the whole day was blocked to show off the products and do discussions after. Each developer showed his/her progress, explaining framework difficulties and positive experiences. How easy was it to find help/answers on the web? Did the documentation had all info needed to get from start to finish? Questions were answered, smaller discussions spawned and the frameworks way of dealing with our criteria was explained. Developers experienced in e.g. angular 2 saw presentations of first-time users and could respond to their problems while the presenter learned what could’ve been done differently.
Some developers were enthusiastic about their framework after their first-time use. Some simply said their framework is good and they don’t see a problem working with it. Others were a bit frustrated and couldn’t recommend their framework.
At the end, the team collectively and objectively decided on a framework they felt comfortable with, which became our choice for all new frontend apps.
Our Choice and some interesting remarks
During presentation day, there were some very interesting arguments exchanged that I want to share. Please note that this is not a pro/con list of these frameworks.
Someone hold against vueJS that there are not enough StackOverflow questions while others took that as a pro for their documentation and their forums. And indeed, vueJS had the best documentation by far.
Typescript was a big clash as well. At the end, the team agreed to go with standard ES6 to limit pain points for the next developer team who takes over an app. After all, none of us would like to take over a coffee script app now. In case type definitions are needed, we’d use Flow.
Angular 2 did not gain any new fans during that week despite their incredible tooling when using Typescript. Their documentation, especially the Javascript docs, where not complete, long and confusing. It took the devs much longer to get up and running and the weird release cycle (or the communication of it) simply did not spawn any confidence regarding future-proofness. Version 4(!) was already announced at that time.
JSX vs Directives — HTML in JS vs Logic in HTML — was also an interesting discussion. The team concluded that directives lead to more readable HTML and they’re familiar with it from their angular 1 background. Also vueJS solved this very elegantly while still supporting JSX if wanted.
ReactJS and vueJS were very close but due to the documentation and beautifully elegant API, vueJS came out on top.
At the end of the day, all of these frameworks solve our problems and this is all developer preference. So don’t take our decision or the remarks as a general fact but more an opinion our developers agreed on.
The Future
The frontend landscape introduces new frameworks every other week (hello, moonJS) and developers obviously want to try them out. For the foreseeable future, the big apps that are relevant to our production business will be written in vueJS while we give everyone the opportunity to try out new technologies and frameworks in smaller proof-of-concepts and dashboard apps.
Conclusions
From the feedback of the participating developers, management and other observers, this week was a success to me. While expensive (nothing else was developed in that week) it settled this discussion for the foreseeable future. It also limited teams from going into completely different directions (technology wise) and opened the door for easier collaborations. Like moving apps to other teams, shared knowledge and in the best case: commonly used components.
