The early adopters dilemma in JavaScript

Not everyone can be cutting edge all the time, especially not in JavaScript (in 2015).


While the hipsters were already hyping up AngularJS as the next big thing, most of us where still in jQuery land or using one of the more traditional JavaScript MVC frameworks (think Backbone, Spine or Knockout).

At 25th-floor we were still looking into ember.js in 2012, thinking that this might be the framework to use in 2013. Then at some point, AngularJS started to lift off, gaining traction and on its way to going mainstream. We would fall into the category “early mainstream”, meaning not too early, as we have to be risk averse (we are mainly building business applications not todo apps) but jumping on as soon as the technology seems to be stable and has a future that surpasses the current hype. We have been using AngularJS for 2+ years in production now. We have gained insights into the good and bad parts, especially the limitations.

Now consider when React started coming up. A certain group of developers were early on, experimenting with the framework and pushing the boundaries. We looked into React in 2014 but we didn’t use it anywhere up until this year. We had seen the limitations with the previous framework and knew what solutions React would offer to our existing problems. At some point React was about to go mainstream, this is when we jumped in. Same thing goes for Flux, we are finally starting to really experiment with the pattern.

Just think about what’s going on in the JavaScript / front-end world right now. The pace with which new patterns, frameworks and guides are being pushed is more than amazing. Only in the last couple of months have we seen the rise of local css, the phrase “to reason about” (thanks to React) going mainstream and ES6/ES7 code as the de facto standard. Grunt being replaced by Gulp maybe being replaced by something else (while I’m typing this), hot loaders, immutable frameworks, lodash merging with underscore, Ramda emerging as the functional library to go to and and and.

Not everyone can be an early adopter, especially when you are building apps that rely on some sort of support in the long run. Sometimes we need to take a more defensive approach, meaning — wait and see where a technology is heading and then jumping in at the right time.

We are used to some sort of consistency on the backend. You have Ruby On Rails, Zend, Symphony, Spring, JavaEE. Things appear stable on the other side. Actually things are stable on the other side. There are developers who have been using Spring for x number of years and who will continue to do so, same goes for all the other aforementioned mainstream frameworks.

Being an early adopter can have its benefits, including but not limited to emerging as a leader or having some major influence on the direction a certain tool, library or framework is taking on. The downside is that you might be jumping onto a technology too early — not seeing the bigger picture. A todo-app might not be enough to evaluate a framework properly.

The good thing about coming later into the game is that a common ground has been found, surpassing fundamental discussions on how to solve pending problems. Are we switching to local css this week? No. Not even after reading this fantastic post on the end of global css. Will we be using local css this year? Maybe.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.