My thoughts about the most important front-end frameworks today — and a look at the future

It’s 2019, and writing Javascript has never been so fun.

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.

Standardization and Maturity

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

Alignment in concepts and paradigms

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”.

So — no more Javascript-fatigue?

Not exactly.

Javascript is still a very fast-moving language with a thriving community, and from time-to-time, we will still have to re-learn, update and refactor.

But it is a more standard, stable and mature industry than it was a few years ago, and that’s a good thing.

The Big ones: React, Vue and Angular

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.

Choosing a Framework: a matter of opinions, or objective differences?

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

Tooling and Community

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.

The rise of “disappearing frameworks”

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 to use smaller, disappearing frameworks?

When does it make sense to use one of these smaller frameworks?

• When you simply like them more than the others, of course…

• For building company-wide UI components: thanks to the capability of compiling to Web-Components these frameworks are ideal to share code with other projects, likely written in either on the big 3 or in Vanilla Javascript
  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

What about full-blown enterprise apps?

Well, maybe.

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.

Takeaways

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

• Despite the stabilization around the speed of the progression of frameworks and libraries, Javascript can still be challenging and difficult to keep up with

• 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.

I hope you enjoyed this article! If you did, follow me on Medium, Twitter or my website for more articles about Software Development, Front End, RxJS, Typescript and more!*