In the last few years, the community has given us builders that automatically kickstart our projects, linters that format our code and types that correct us; we can use WebAssembly, WebWorkers/ServiceWorkers, and our apps run can on virtually any device.
The possibilities that we have today thanks to tools such as Webpack, Parcel, and Rollup are nothing but awesome.
And, we have tons of frameworks and libraries. Tons. Isn’t that an amazing world to code in? I think so.
But with all this abundance, we are often tasked with choosing the stack for that next project our employer asked us to start, and then, as it usually happens, defend it.
Notice: This post does not intend to incite a flame-war or anything like that. On the contrary, I want to invite readers to reflect on the current state of the frameworks by addressing my views and opinions.
While we can certainly see new stuff coming out daily, it is undeniable that the crazy influx of new libraries and frameworks in the last few years has decreased, and that the whole industry seems to have reached a certain amount of standardization and maturity.
In fact, it seems that the industry has agreed that:
Components are cool
Reactivity is cool
Typescript is cool
State in components is (mostly) a bad idea
The most difficult thing when having to learn new frameworks is not usually its API, but rather it is its different programming paradigm.
When I was learning AngularJS in 2013, coming from a JQuery background, I had to change my whole perspective about building user-interfaces. It was pretty different.
While every library has various variations of API and implementations, we can say that thanks to the standardization of the points above, we are not tasked with a complete shift in the way we write and think code.
For example, React has certainly popularized the concept of components and (thanks to Redux) to place state outside of your components.
Yet, other frameworks have taken note and subsequently implemented similar concepts: components are also building blocks in Angular and Vue, and they all have their own Redux implementations (NgRx and Vuex), which is today the most used pattern for managing state in approximately each one of these frameworks.
This is not to say you’ll learn both in no time — but that you’ll have a much easier time now that they all shared the core concepts behind their architectures.
Everything feels “kind of similar”.
But it is a more standard, stable and mature industry than it was a few years ago, and that’s a good thing.
As we all know, we have the big three frameworks that appear to be the biggest competitors: React, Vue and Angular.
React has established as the most used framework for a number of reasons; along with it, there are various frameworks with a compatible API but with a smaller footprint such as Preact and Inferno
Angular is historically powerful and has shipped a robust new version that is still trying to find love among non-enterprise teams and users
Vue, that appears to have strengths from both the other two, not backed by any tech-giant, and with a large, welcoming community
The quality of these frameworks has somehow stabilized; they each have their strengths and controversies — but overall, I would say that the differences between them are often a matter of personal opinions.
Whether you care about longevity, community size, performance, bundle size, and ecosystem, these frameworks provide similar results.
So how do you choose what technology to choose? Do you really miss out if you choose one instead of the other?
If your team is experienced with a framework already, the safe answer is to keep using that one, unless you have real reasons not to
Generally, no. I don’t think that choosing one will make you miss out on incredible features or performance that the other one has
It usually comes down to your preferences: these frameworks are similar in some aspects, as I have said above, and yet have some fundamental differences. For example:
React sort of banned classes from their best practices with hooks
In Angular, instead, you’ll almost just be writing classes: this is a big difference if you prefer an approach over the other
Vue is extremely flexible and gives you the choice. You can write JSX, Angular-inspired Component API, etc. Vue is a pretty safe choice given the amount of flexibility it provides
In terms of community and tooling, they seem to also be on par:
They can all be server-rendered
They can all be lazy-loaded
They can all run natively as Mobile applications (Nativescript, React Native)
They have UI component libraries for awesome design systems
Except for Angular, Both Vue and React have a third-party static-site generator
At the time of writing this article, I would say it’s rare not to have a similar utility or library for a framework that the other doesn’t.
On the other hand, we also have a large number of smaller prominent projects such as Svelte and Stencil (and well, many others).
The so-called “disappearing frameworks” are extremely exciting projects for a simple reason: they compile the code you write, without the framework; as a result, applications will be smaller and faster.
For certain projects — such factors can be extremely important.
When does it make sense to use one of these smaller frameworks?
When you simply like them more than the others, of course…
As an example, Ionic was able to quickly ship its framework to not just Angular but also other frameworks by writing components with Stencil rather than re-writing them all from scratch
Applications oriented to an audience with prevalent low powered devices or slow networks
I do not have the amount of experience with them to be able to answer that. But I think as more companies and projects will adopt them, maybe we will see how these frameworks will compare at large scale.
It’s a great time to be a developer, so great that choosing a framework is a matter of controversy.
Frameworks are mostly stabilizing in terms of concepts and best practices — despite their unequivocal differences
Choosing a framework over another won’t make you miss something fundamentally important than the other has. Follow your preferences and see which of the future developments of each framework appeals to you the most
Mind the newcomers: the so-called “disappearing frameworks” such as Svelte and Stencil are proposing themselves as possible new players in the field, and successful projects such as Ionic are an example of how you can leverage these type of framework to build cross-framework components
If you need any clarifications, or if you think something is unclear or wrong, do please leave a comment! Feedback is always welcome.