What framework(s) should I use?
This might be one of the most asked questions amongst JavaScript developers, and there is a reason for that: there are too many frameworks out there, thus causing “framework fatigue” amongst the JavaScript community!
And yet, the best answer I’ve had so far was the one Bryan LeRoux gave a couple of years ago during PhoneGap Day EU: “the best JavaScript framework is HTML”. He probably wasn’t the first to say that, and he will definitely not be the last, but that answer stuck with me.
The way I learnt JavaScript was by picking bits of code here and there and by heavily using frameworks. There is that feeling that you can outsmart JavaScript by adding another layer of abstraction and therefore only use the good parts of the language. But here is why I was wrong and Bryan was right: the only thing that hasn’t changed in the past 10 years around client-side JavaScript is HTML.
An (incomplete) overview of JavaScript frameworks
Backbone was kind of the pioneer in building front-end single page applications with JavaScript. I still am a fan of Backbone and use subsets of it from time to time for small projects. Nevertheless, in a world of infinite flux of new shiny frameworks, it was somehow out-powered by Angular.
For most JavaScript developers, Angular seemed to be the framework that would finally rule them all and that would bring some stability into a bustling and chaotic landscape. Unfortunately, a year ago the Angular team announced they would rebuild the framework from the ground up, a move that seemed to bring back chaos to the lands of JavaScript (apparently it will be possible to run Angular 1.x code in Angular 2.x, making the transition a bit smoother). And so the hype seems to be on React lately!
I haven’t used React, mainly for the same reasons I haven’t touched Angular (mostly because I feel like it holds too much magic in it), but it does seem to gain a fairly sizable momentum. The problem of those frameworks is that they are so far from the language, that when you learn Angular for example, you basically don’t learn JavaScript. They also gently force you into their opinionated way of doing things, which is good if you agree with their philosophy, but probably not so good if you don’t.
Small modules: the solution?
In the mean time, some people have putting away those gigantic monolithic frameworks for a more modular approach. There is a trend towards micro-frameworks: tiny pieces of code that do only one thing (like, templating or routing) but that do it really really well. You can therefore create your own custom stack depending on your needs. Here I am looking at MicroJS andNPM modules.
This solution looks great on paper, but the problem is that there is a lot of noise and fragmentation. How do I know that this little framework I am using right now to route my app is still going to be maintained 2 months from now? Am I actually making the right choice combining those 5 micro-frameworks? How portable will the code I am writing be? As Rich Harris pointed out: “small modules, it’s not quite that simple”.
Most of all, understand your needs!
So what to do? I’m not going to code this huge single page application using just plain vanilla JavaScript, right?
Well, I think that the best solution lies somewhere in between all of that. Most of all, understand your needs. Building a hybrid mobile app with 5 views probably doesn’t require the same heavy lifting as a full-fledged 100-view web app. As a rule of thumb, before adding any piece of code to your project, make sure to fully understand how it works so that you are confident you can tweak it if needed. And, as always, experiment!
PS: The new ES2015 standard actually has templates and modules (and a lot of other awesome stuff) built into the language which make a framework-less solution more viable!
