Frantic image

The 2020s - From choosing to composing frameworks

Looking back at the past decade makes us think about what we accomplished in the web development community, and what we want to achieve in the next decade.

The 2010s was the decade of the so-called Framework Wars. Every few months a new Javascript framework would be released, and a battle for the top spot ruler of the frameworks would be fought. At the end of the decade, the state of JS for front-end frameworks includes React, Angular, Vue, Svelte, Preact, and Ember – all with sizeable shares of usage. 

Framework Wars are about choosing sides. The idea being that you can only choose one framework to work with, making you carefully follow the rankings, betting on your own team to affirm the choice you or your company made. The choice is meant to last your company a decade. Losing in this model means that if your framework falls out of fashion, it can spell a monetary disaster: costly rewrites of your website and additional work. A company cannot afford to lose, so winning the war means everything.

Even now, two months into the new decade we are already seeing articles written on “What framework to use in 2020” and “What framework should you learn in 2020”, pitting frameworks against each other. However, shouldn’t we instead be asking ourselves if we still need Framework Wars?

Whilst the Framework Wars are often touted as a one framework, one company concept, this is not necessarily the real-world setup. Often through acquisition or a wish to try the new cool thing, a company will actually already be supporting multiple frameworks. Instead of overcommitting on one framework, we should be instead looking at how to get the frameworks to work together in a new composition – creating even more powerful applications and cost-effective solutions.

One of the biggest takeaways from the last decade is the concept of component-based software engineering in front-end development. This can be seen in the rise of web components and component-based frameworks. By changing our thinking from building individual pages of a website to creating reusable, lego-like, building blocks that form the components, we are able to quickly assemble many pages with shared functionality.

With a component-based approach, we can start mixing frameworks. This is a popular approach that has been used for upgrading from AngularJS to Angular 2+. The Angular 2 release in 2016 was a full rewrite of the Angular framework; it is practically unrecognizable from AngularJS. This meant that there was no simple upgrade process. Instead, companies were faced with a full rewrite if they wanted the latest flavor of Angular. This led to many different scenarios for upgrading. One of the more popular ones used by large enterprise-level applications such as in banking was the setup of running both an AngularJS and an Angular 2+ application side-by-side, whilst undergoing a slow migration. 

In this side-by-side approach, we create an application that acts as the glue that binds together the different elements. Web components are a popular choice for the different elements. These elements have all the logic about how to behave, but the elements don’t need to know about anything surrounding them. However, they are not the only solution. Other emerging solutions include natively embedding components into other frameworks, such as this example of embedding Angular components into React applications using the new Angular Ivy renderer

The advantage of using the composition model is that we can become less dependent on any one element and more flexible to future changes in technology. Whilst there are some advantages to using one framework throughout, it is not the end of the world if you choose wrong or don’t stick to the one framework model. Additionally, by broadening your stack you can take advantage of the best of each technology and broaden your safety net in case a rewrite is needed.

Where the 2010s were the decade of frameworks and components, I propose the 2020s as the decade of composition. Let’s stop stressing over the correct timeproof framework, and instead look at ways to assemble different frameworks into one application. In this way, we avoid winners and losers. We can ideally strategize solutions that will truly last a decade.