Slagging Off JavaScript Frameworks

An analysis of how easy it is to slag off various decent JavaScript Frameworks.

← andyshora.comworth a tweet?+1

Why didn't you use Vanilla JS?

Remember this, kids. It's the easiest phrase you'll ever learn to introduce yourself as an Elitist Frontend God.

Sure, many frameworks provide layers of abstractions that can provide opinions about how you should structure your code, and how data should flow, but I'd like to take a look at the big players people love to hate, and assess just how much of the criticism comes down to egosistic snobbery.

Interviewing a new pilot? You better make sure he knows how to fly the plane if the autopilot fails.

A wise man

Candidate: AngularJS

Dude: Do you know what technology you're going to use for this new project?

Me: Angular.

Dude: But you don't know any of the requirements yet...

Me: Angular is awesome. It will do what you need, and I love it right now.


VERDICT: Great for client-side web apps. Not for pre-rendering markup.

The most important thing you need to know about AngularJS is that the markup is created dynamically on the client. Search engines will not be able to index your content. Yeah, you can argue with these statements in the comments, but let's be sensible and refer to Angular as a way to build rich client-side applications which don't need to have multiple states indexed by Google.

So, we've specified why you might not want to choose Angular for a project. Now for the good stuff. Angular is currently my go-to tool for prototyping web apps. The speed at which you can produce views, fetch data and bind it to modules, is blazingly-fast. The quality of third-party directives is currently very good. The Angular team are also very active in the community, and will likely tweet your work if you do something helpful.

If you're being criticised for using Angular, it's more than likely you're one of the 'Angular for everything' guys I've tried to represent in the dialogue above. Web apps, yes. Websites, no.

Candidate: React

Dude: Do you know what technology you're going to use for this new project?

Me: React.

Dude: Oh cool. Is that the thing Facebook made?

Me: Yep. I'm basically one of the first to use it. It makes our company bleeding-edge.


VERDICT: Great for websites. Difficult to bash unless used naively.

React is difficult to bash right now, because it's the latest badass framework that all the best Frontend Developers are getting into. Its steep learning curve and requirement for solid engineering principles ensures it hasn't yet attracted much criticism.

In short, React currently falls into the group of frameworks that will only make you look bad if you:

a) Insist on using it for something which clearly doesn't need markup pre-rendered on the server. The term over-engineered might be thrown at you.

b) Implement it very badly, hacking trivial code examples into something which resembles your requirements.

React is also pretty heavy. The minified version weighs in at 122kb. This further strengthens the argument that it should really only be used for serious websites which can make use of it's capability of running on the server to pre-render markup, and of running on the client to dynamically update views in response to interactions.

Put simply, when React is used because the developer wants to show that it's 2015 and they can use React, it's not cool.

He has a right to criticize, who has a heart to help.

Abraham Lincoln

Candidate: jQuery

Dude: Why did you use jQuery for that?

Me: It works, doesn't it?

Dude: Yeah, but do you even know why?

Me: Look, some guy on StackOverflow who is clearly a genius, did the work for us. Stop asking me questions. You're too old school.


VERDICT: Use only when absolutely necessary.

If you've been a developer for more than six months, you're probably aware that snippets of jQuery can anger the Web Development Gods and create a storm of ice and fire which can wipe out the largest armies known to man.

jQuery has it's uses. It abstracts away cross-browser inconsistencies via an easy-to-use API. It's great for interacting with the DOM, toggling classes, and sending AJAX requests. It's great for prototyping interactions too. The problem is, it does too much, too easily, to the extent where Junior Developers start to use it for the wrong reasons and don't learn what's really happening under the hood.

It's also worth noting that the poor quality of the hundreds of thousands of jQuery plugins which are dotted around the web have lowered jQuery's reputation to a level where we believe that the only people who use the library are either young and naive, or old and behind-the-times. If you do occasionally use jQuery on a project, you're likely to have a battle to prove you're in neither of these boats.

Interviewing for a JavaScript position? It's very easy to go wrong with jQuery. Best avoid shortcuts like this.
$("#id").html("<span>"+ variable + "</span>") /* very dangerous */
$("#example").text("Hello, world!");
$("#example").css("color", "red");
$("#example").addClass("fun"); /* heard of chaining or selector caching? */
$("section div a").addClass("highlight"); /* not very efficient */

Candidate: Underscore.js

Dude: I see you used Underscore there...

Me: Yeah.

Dude: Why?

Me: Because Underscore is fucking great at providing the best practice implementations of tons of utility functions.


VERDICT: Stop with all the bashing.

It's difficult to attach a negative third-party code connotation to something which has been written and revised over and over by some of the planet's greatest JavaScript Developers. In my eyes, these are the people recruiters often refer to as the Ninja Rockstars of our generation, and we're basically talking about best practice implementations of small functions.

The only bad thing about Underscore is that you can perhaps overuse it. For example, I've seen many examples of Developers using _.each when a simple for loop would suffice.

It's also not cool to answer interview questions using utility functions from Underscore. Asked to check if a variable is a string? Best avoid any mention of _.isString. You need to be familiar with what's going on inside Underscore.js. Using Underscore does not make you a bad developer. Used correctly, it makes you a good one.

It might even be suitable to extract the functions you need from Underscore, just be careful of the dependencies that exist between functions.

Interviewing for a JavaScript position? Best use plain old JavaScript.
// How do you check var str is a valid string? 
var valid = _.isString(str); /* fail */
var valid = typeof str === 'string'; /* better */
var valid = === '[object String]'; /* _ implementation = perfect */


Every JavaScript library has a purpose.

Experienced Frontend Developers should be able to see suitable use cases for each of the frameworks above. Naive Frontend Developers shriek the moment they see them being used.

What we have to do as a community is not be too judgemental the moment we see a fresh jQuery question on StackOverflow.

A good answer is not: Why are you using jQuery?!

It should be: Here's how you would do it in jQuery. Have you considered it might be simpler in plain JavaScript?

Sure, we all have go-to tools for prototyping and rapid app development. Lets just try to avoid slagging off uses of pre-2015 frameworks in an attempt to elevate ourselves into the clouds of frontend snobbery.

by Andy Shora

I'm a Front-end Web Developer based in London. I currently work with some very talented people over at QuantumBlack. I love to build sites which are clean and have great performance, and I dabble with whatever technologies are most suitable for the job. Send me tweets!