Four years ago I picked JavaScript framework, and I feel comfortable about it
Have you already heard about a new shine JavaScript framework/library that have been released recently? In JS ecosystem they spring up like mushrooms so you can have your `developer chase mode` always on. Learning something new is by definition a good thing, don’t get me wrong. Still, if you look at JavaScript Fatigue, it is a pretty overwhelming situation.
In 2013 when Single Page App frameworks were immature, there were few emerging options available. Angular.js, Backbone.js, Batman.js, Ember.js to name just a few.
What happen since then? So Angular.js (1.x line) got a full rewrite as they original architecture was broken by design — plans ware announced in 2014, and only two years later, in 2016 it was delivered :-). For Angular.js (1.x and 2.x) — things still roll on, even it is not the technology that cool kids use those days. Backbone.js have still a small group of active users, but today most developers that love this style pick React.js or Vue.js. Batman.js have been dropped by Shopify (the maintainer) 18 months later (at the end of 2014). Ember.js also have a major update released in 2015 — key ideas stay the same, and the framework is still in the game.
Four years ago I didn’t know what the future holds, you never know. It’s good also to highlight that no one knew how to do client side application in JavaScript well those days. Now in 2017 we are in much better position. Unfortunately, we are not there yet.
Looking at the architecture, ideas behind, and exceptional people behind I’ve put a bet on Ember.js. It has it’s ups and downs, as everything is changing in the technology. In the end, I fell comfortable with the decision made. And this leads me to some notes for the future:
The crucial factors for evaluating technology at the early stage are core values and philosophy of the people behind it.
Even if we can’t predict future, knowing people behind the project makes easier to forecast direction in which the solution will develop. The creators usually have a track record in open source; they wrote articles; did presentations — do you feel comfortable with the way they solve problems (and define them)? Another factor that is good to take into account is the context — are they familiar with the environment of product companies or maybe they experience challenges of software development house. Do they do small or enormous projects?
Ember.js is not a silver bullet, works great where it align well with the project context. When I look back at what happen in JavaScript ecosystem, and how Ember.js evolve, it seems to me that Ember.js was a solid choice. And here I want to say thank you to all that make it happen —great job!
I’m interested, about your ideas and best practices. What are you taking into account when making a technology decisions?
