Designed by vectorpocket / Freepik updated by Shashank Sharma

Is it time to move on from Virtual DOM (React)?

Understanding the Framework’s Hell pattern and predicting the next paradigm shift.

Shashank Sharma
Dec 4, 2019 · 5 min read

I have been developing web apps over a decade and have witnessed the rise and fall of many JavaScript libraries and framework. Change is inevitable in Framework’s Hell. As a developer, I wondered if there exists a pattern and more importantly, can we predict the next shift?

Today’s most popular successor bridges the gap created by its predecessor

To understand this shifting pattern of frameworks, let’s go back a little bit in the era of JQuery.

It was the time when maintaining cross-browser support for any web app was a nightmare for a developer. JQuery (and associated libraries) was the de facto way to go about web development. However, it has its limitations. Code size bloated with lots of polyfills to support different browsers and most of the lifecycle management had to be done separately, which added more code footprints. Moreover, the big concern was how different jQuery plugins could co-exist together and communicate with each other without disturbing each other.

Any new framework solves some problems also creates a new demand

Eventually, libraries started evolving into frameworks and gave skeleton to whole web applications. This was the time when there was a rise in module driven development (AMDs/requireJS/Dojo etc.).

Enterprise adopted these patterns quickly. Many of these libraries were adopted by enterprises quickly. And soon there were several incompatible standards emerged in modular JavaScript ecosystem. Even the HTML community took a note of it and shared an initial draft of Web Components


Web Component specification enables capabilities to extend existing HTML elements. This gave rise to HTML extension model (Custom HTML elements <my-elements/>)was picking up.

However, it was nowhere close to being adopted by the browsers natively, but this inspired a new era of component-based JS frameworks, including AngularJS(by Google) and React(by Facebook). They came up with the component lifecycle management model, and the rest is history

Angular 1.x took over the web like a storm and became a new standard of web development with magically manipulating the HTML DOM with innovative change detection mechanism (Watchers).

However, as application size increased, many issues surfaced, including framerate drop while detecting changes. It was not very performant and efficient when the number of components or watchers increase.

ReactJS came up with improved change detection and update mechanism called Virtual-DOM which outperformed angular’s Scope and Watch techniques

Angular2.x soon emerged trying to fix the mess Angular 1 created however it was little late to do so as React had overtaken the defacto thrown by that time

Also, there are few more players in the market like VueJS who are better in a few aspects where Angular or React lacks.

Also, remember all these frameworks evolve too. They ship newer versions trying to improve in each successive release. However, most of the time they stick to backward compatibility by keeping the core architecture similar.

Can you spot the pattern here?

Developers lookout for newer options when

  1. There are visible flaws in the existing framework that can not be fixed soon or without breaking changes (no backward compatibility)
  2. There are alternative options available which solve the above problem

Is it time to move on from Virtual DOM(ReactJS)?

To answer this, we need two things

  1. List of flaws that can not be fixed without breaking changes
  2. Do we have alternatives available today?

Flaws 👎🏻

Desclaimer — ReactJS is an awesome ecosystem to work with. I have been using react from some time now and it has helped me shipping the web apps efficiently and quickly. However it doesn’t mean that it is flawless

  1. All these frameworks discussed so far rely heavily on the browser’s capability to process their algorithm. Example change-detection / watchers / Virtual-DOM manipulation etc. Doesn’t matter how efficient the diffing algorithm evolves into it will always eat up client’s hardware resources. Although there have been few attempts to use various concepts like Web Workers, Web Assembly to accelerate the processing power in the browser, still the underlying challenges remain the same.
  2. Applications have to be shipped with libraries and dependencies no matter how small or large the app itself is. The average size of the modern webpages has passed 2MB, which most of the time contains lots of boilerplates.

Alternatives today

Can we continue to have the benefits of these frameworks, avoiding the bundle bloat? An excellent Developer and User Experience? Well yes!

An era of disappearing frameworks

Svelte / Stencil / Angular elements / Polymers / Web components are examples of this emerging trend.

Svelte, in particular, caught my attention initially as it is not a client-side framework; instead, it is a compile-time framework. Rather than relying heavily on browser for processing it shifts the bulk work in compile-time and finally, ships only rendered HTML/CSS/JS. The compiled bundle does not contain or depend on any of the library code.

Conclusion

So what is the pattern? Progress is a typical pattern. A common problem exists with most of the existing framework ecosystem, which spits a lot of boilerplate code base to the client and relies heavily on the browser’s resources for state management, routing, etc. It is hard to address these concerns in the subsequent release of frameworks with breaking changes. And at the same time, there are alternatives available which continue to give the benefits which current developers community is used to without bloating the work to browsers.

Disappearing frameworks are really worth an investment and deserve a shot.


I hope this post will help to understand the ever-shifting pattern in JS framework and help to make an educated decision in one’s private or enterprise project development.


Resources

Special thanks to Peter O'Shaughnessy and Rich Harris — Rethinking reactivity to assemble all the points together.

JavaScript in Plain English

Learn the web's most important programming language.

Shashank Sharma

Written by

💻 Web Architect | Developer | Working with PayPal | Learning & Delivering can go together 😎

JavaScript in Plain English

Learn the web's most important programming language.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade