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.
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.