It's a debate that runs through development teams on an almost weekly basis, which javascript framework should we use for our new project?  To understand a bit more, we need to look at the history of front-end development and understand why we have ended up where we have.

In the beginning of the internet, web pages were completely static and whatever came down from the server to the web browser was what the user would see.  There was no interactivity, buttons didn't even change colour as you hovered your mouse over or clicked them.

Some way down the line, along came Netscape Navigator 2.0 in September 1995 with a new coding environment called 'LiveScript' later renamed Javascript.  And so writing code that runs directly in the browser was born.

For years later, javascript was only really used to visually enhance (well we'll use that term lightly!) web pages through the use of annoying flashing and scrolling banners, slide out menus, button hover effects and lots more.

Whilst it had its use, it wasn't considered a proper programming language for years.  This didn't really change until in December 2009 ES5 (the 5th version of Javascript) was released.  This brought in a number of new features to the language and programmers started to realise that Javascript could play more of a part in their application development.

Fast forward to today and Javascript is now used to build entire applications.  The server element now consists of a number of web services that the front-end interacts with.  It's a huge turn around for the lanugage and with it has come a huge number of frameworks to sit on top of it to enhance and improve it.

Libraries and frameworks have existed in almost every programming language since time began, but the nature of the internet is such that you can never be sure which environment a javascript program is running in, for instance operating system, browers and in recent times which device be it desktop, tablet or phone.  Therefore the first libraries like Jquery setout to standardise certain javascript features across all platforms to make development easier.

The next iteration of these libraries were more like frameworks.  For instance, Backbone.JS was monumental when it was released as it brought the concept of MVC (model, view, controller) to the browser where applications had a single version of truth in the data (the model bit) and dumb views that had no logic and finally controllers that manipulated the DOM (document object model).

For a while, Backbone was great as it was providing the application framework javascript had been missing for some time (note there were a number of other libraries around at the same time like Knockout.js but Backbone was one of the most famous).  However, as time has gone by a couple of large developments have taken place that have caused tools like Backbone to start becoming obsolete.

Firstly, since Backbone was first released, two new version of Javascript have been released.  These have brought a huge overhaul to the language and it has become a much more fully fledged programming language.  Radically different implementation of a class system, typing on variables and much more.

Secondly, brand new techniques surrounding performance have been developed including Shadow DOM.  This is where the HTML that makes up a page is split like a tree's branches and different modules can be ring fenced.  This has a huge performance benefit as it means that the entire DOM need not be updated every time there is a change to the UI, but simply the appropriate piece of shadow DOM.

New frameworks leverage these techniques, coupled with the new version of Javascript and new build tools like Webpack and we now have a fully fledged development platform.

The three main 'hot' frameworks at the time of writing are; React, Angular and VueJS.  This is not exhaustive, there a number of other frameworks that come with their merits, for example EmberJS but we are just going to look at these three for this example.

So, how do we choose which one to use?  The answer is that each of the frameworks set out to do essentially the same thing.  They all provide similar features, namely they give the developer the ability to write their domain logic in a sensible place (controllers) and they manipulate the DOM leveraging Shadow DOM.  They also provide other facilities such as state management, routing and more.

The reason to choose one over another will come down to technical specifics for your project, the skillset your developers already have and, frankly, preference.  React and ViewJS are very similar in that they leverage single file components when writing the code.  Essentially, this means that all of the code including the template, the controller and any data manipulation take place in the same file.  Years ago this would have been considered bad practice and you've be encouraged to slice your files by type rather than function.  This is the way Angular works where each file is of a particular type, for example a template file or a controller file.

Where React and VueJS diverge slightly is that VueJS asks the developer to write regular HTML templates using handlebars like syntax, where as React uses JSX which is essenitally a preprocessor for HTML that allows developers to add sugar to their templates via an XML like syntax.

The end result for all three of these are the same.  From a developer perspective, the choice is more about which of these approaches you prefer to use and which suits your coding style.  

Another factor is that Angular and React are commerically created and backed by two major companies (Google and Facebook respectively) where as VueJS is independent although they are starting to attract major sponsorship.

Backing from a large organisation is both a blessing and potential pitfall.  Angular and React have commerical license agreements in place and indeed there was a huge argument over the terms of React's licence because it stated that if you sued Facebook for infringing your copyright of something you'd developed in React, then they would revoke your React license.  Whilst in practice this was probably very unlikely to cause anyone a problem, developer resistence forced Facebook to back down.  But it's an important point that there is a potential conflict of interest from commercially backed/created frameworks.

On the flip-side frameworks that are not commerically backed, like VueJS, could potentially run out of money or interest and is perhaps more exposed than a commercial framework.  However, the benefits are that there is no conflict of interest, there is more flexibility and the likelihood of improving the framework quickly and efficiently is greater.

We hope this has been useful and it demonstrates that it's simply not possible for someone to write in a blog post which framework you should use.  It's likely that if someone is pushing a particular framework that they either have an agenda, or they just want to talk about a piece of technology that they really love and has worked well for their project.

Something working well for one project does not automatically mean its the best fit for the next.  When having initial discussions with new clients we are often asked which framework we're going to use.  Ocasionally this is even prescribed.  Unless there is a particular reason to use one over another, we prefer to understand the requirements first with an open mind and then map those onto the correct framework that ticks the most boxes rather than try and mould a solution onto a framework.

Have we struck a chord? If you'd like to chat more, get in touch!