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.
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).
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.
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!