Choosing a JavaScript Framework

Warning: Illegal string offset 'filter' in /var/sites/t/ on line 1409

JavaScript frameworks are of course all the rage right now. When starting a new web-based project, one of the first questions asked is often – which JavaScript framework should I use? Probably the four most popular choices at present are AngularJS, Ember, Backbone and React. Of these, it is Angular which is comfortably generating the most interest among developers. Whilst exploring this very choice this week, and as I read conflicting opinions, it dawned on me that many of us are getting ahead of ourselves. Before deciding upon an appropriate framework for our project, we need to ask ourselves the following question:

Why do we want to use a framework?

After all, everything that can be done using one of these frameworks can be created using pure JavaScript, can’t it?

I am currently setting up a new pet project, and fell into the trap of thinking too early about which framework I wanted to use. The project is quite graphical in its nature, using Raphael.js to generate SVG shapes which the user can interact with. My initial choice was Angular, partly because I am more experienced with it than the others and I would like to gain more experience still.

However, I noticed the following statement on the AngularJS website:

Games and GUI editors are examples of applications with intensive and tricky DOM manipulation. These kinds of apps are different from CRUD apps, and as a result are probably not a good fit for Angular. In these cases it may be better to use a library with a lower level of abstraction, such as jQuery

I’m not building a GUI editor, but my application will be far more graphical than your typical CRUD app. I’m going to be using Raphael statements to draw shapes, so how would this fit into the AngularJS architecture?

A few google searches later, I found that this problem had unsurprisingly been encountered many times before. The common approach it would seem is to create Angular directives which encapsulate Raphael elements. This seems fair enough on first glance.

But hold on a second, this would also lead to code which is more difficult to understand than vanilla Raphael and JavaScript, so at this point I had to ask myself: what would be the benefit of using Angular directives in this way?

As far as I can tell, the main benefits of creating custom directives in Angular are readability (html) and reusability, and also possibly testability. So, let’s look at these in turn.

Regarding readability, would using an Angular directive for my Raphael canvas make for more readable HTML?

As all of my Raphael elements would exist inside a single div representing the canvas, using directives I would probably end up with something like this:

…rather than this:

Is the first way more readable? Marginally perhaps. However, my JavaScript code would certainly be less readable and easy to understand, therefore there is no advantage with regards to readability in this case.

How about reusability? I know there will only be one canvas in my application, therefore no advantage here either.

And testability? There is no behaviour here which is being moved from markup to script. Whether I use directives or not, all behaviour will be expressed in JavaScript, so no benefit with regard to testability.

So in conclusion, there is no benefit to using AngularJS directives to wrap my Raphael functionality in this specific case, and the same conclusion would surely be drawn with any other JavaScript framework.

Which begs the question – why should I use a JavaScript framework at all for my project? The benefits vary between frameworks, however largely they appear to share common benefits when applied to CRUD-style applications, which of course accounts for the vast majority of web-based apps. Now my application will include some CRUD-like features: authentication, settings and various other bits. However the Raphael element of my application lends itself less well to AngularJS at least.

So my solution?

I will use AngularJS in some parts of my application, but not in others.

This may not be a common approach, but in my case I think it makes sense. My point here is essentially that we need to treat each project according to its specific requirements, and avoid trying to grok our solution into a specific framework, and the same can be said of most fads in software development. Recognise the benefits and drawbacks, identify the key requirements of your application, and use your intelligence and creativity to select the best approach.

Share Button