Picking a new JS framework
A meticulous task: Picking a new JS framework
The original framework
Our main product was created in 2015. Back then, ReactJS wasn't yet very mature, VueJS was still a baby, and Angular 2 was not yet a thing! So at this moment, AngularJS was a good framework option, as it was well maintained, old enough to be stable, and had the biggest community. It was also something we were familiar with :)
But that was more than 4 years ago, and the JavaScript landscape has been evolving pretty fast. In the tech world, in order to stay current, it makes sense to review the choices that were made in the past, and update our product to what's best today!
As the original framework was AngularJS, you would assume (and we thought the same) that a migration to latest Angular would be the easiest. But we found out that going from AngularJS 1.5 to Angular 8 would be a huge gap, and it would be as complicated as migrating to any other framework. Angular 2+ has very little to do with Angular 2-.
So without an easy choice, we started to look around for new competitors, and there were a quite a few of them! The stars of the moment were Angular, VueJS, React, and VanillaJS (when knowing the scope of the project, this last one was obviously more a fantasy than an actual choice).
The most important things to keep in mind while choosing a framework is to know why do you need one at all, what it's going to be used for, and by whom!
Defining the need
A good way to find out the need for frameworks is to define what's fairly simple (things most people do in their web apps) and what's more complex (very specialised things that we do) in our product. That's what we did!
This way, we found out that our product has a fair number of distinctive qualities from the perspective of a frontend developer:
- It is only meant to be run on laptops/desktop computers, so the responsiveness of each page can be fairly simple. No need to handle huge number of small resolutions for mobile use, nor special touch events, which makes it much easier to implement and test new pages.
- We can also afford to only fully support 2 browsers, Chrome and Firefox, which makes it much easier to play with stylesheets and browser features.
- The product, being a web application deployed on private networks for each customer, doesn't have to be SEO compliant like most online websites as it won't be analysed by robots.
- The product has some sections with many similar functionality when dealing with data. This makes it very suitable to the principles of reusable components.
We also identified that the main complex technical points are:
- Dealing with potentially long requests (few seconds to few minutes depending of the content) nicely, by handling properly loading states and displaying meaningful loaders to the users.
- A detailed authentication system and composable permissions for each user to allow them to fully tailor access control to individual pages/sections/actions within the application.
- Displaying huge amounts of scrollable data as big tables (eg 50K table cells) in an intelligible way.
- Some data intensive visualisation (meaningful charts with thousands of data points), reloaded every few seconds via web sockets.
- One single view utilises nearly half the application logic, which makes it heavy to load.
A choice influenced by people
Another important consequence of the framework choice is that all the current developers have to understand the technology enough to use it, and to like it enough so they want to continue using it. It will also drive the recruitment orientation, as we would have to look for future developer with skills in the chosen framework, or at least with motivation to learn and use it. Nobody is looking to use AngularJS on their next cool project!
In the company, the technical landscape of JavaScript usage goes from tiny frontend projects to server side node scripts, but for now, always using JS/HTML/SASS. Which is probably why the team was pretty cold to switch for TypeScript based framework or JSX based templates. This happened to be a very subjective opinion.
From that perspective, an framework with a good hype on the market, easy to learn, as well as the ability to continue writing in JS, HTML and SASS, would make it easier to recruit new developers and to keep existing ones.
Backing the good horse
This analysis lead us to believe we were in the need for a lightweight framework with efficient state management, that would minimise the choices we would have to make as developer, in order to keep consistency between components written by different people, while enforcing good practices.
Now that we had a better idea of what we needed, we went through the nasty job of comparing frameworks by listing the pros and cons, testing performances, evaluating code cleanness, and checking good practices. There are many framework comparison articles out there, we read a bunch, built some prototypes and compiled an overview of our thoughts below.
| Angular2+ | React | VueJS | |
|---|---|---|---|
| Created in | 2016 | 2013 | 2014 |
| Created by | Evan You | ||
| Hype (github stars) | 51K | 136K | 148K |
| Learning curve | steep | medium | fast |
| Recomended langage | TS/HTML | JS/JSX | JS/HTML |
| Key advantage | Full MVC | Native Apps | Separation of Concerns |
| Size | 500kb | 100kb | 80kb |
| Performance | ++ | +++ | +++ |
| CLI & tools | +++ | ++ | +++ |
| Enforcing good practices | ++ | + | +++ |
| Flexibility | + | +++ | +++ |
sources:
So, first thing to note here is that the these three framework are the real deal, all of them are good choices! They have strong communities, are mature, used by big companies, come with great documentation and have better performance than pretty much everything else on the market!
It's just up to you to decide which one fits the use you are going to make of it, and the team that's going to use it!
Github Stars & Stack Overflow Trends
Choosing the challenger
That said, in our case, after a quick try on each of the three main frameworks, we first eliminated Angular because of it's size, complexity, learning curve steepness, and lack of flexibility. But the choice between React and VueJS was more complicated.
Both were flexible enough, had good practices, a nice and growing community, great performance due to their reactiveness, and good overall feeling when being used by the dev team. VueJS has a faster learning curve. It also keeps it simple using JS/HTML/SASS, and being able to update to pretty much any language component by component. Finally, the team loved having each component in just one file, having a CLI to easily interact with webpack building process. We were also seduced by the simplicity of routing (vue-router) and state management (vuex).
So after a few POC using VueJS to rewrite some basic components of our in-house library, the choice was made: we would use VueJS!
Now the main question was: how are we going to migrate our product smoothly, avoiding any regressions, continuing to improve the product with new features and deploying weekly? But we will answer that in detail in another article!