Is it time to move on from Virtual DOM (React)?
Understanding the Framework’s Hell pattern and predicting the next paradigm 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.).
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
- There are visible flaws in the existing framework that can not be fixed soon or without breaking changes (no backward compatibility)
- 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
- List of flaws that can not be fixed without breaking changes
- Do we have alternatives available today?
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
- 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.
- 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.
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.
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.
Special thanks to Peter O'Shaughnessy and Rich Harris — Rethinking reactivity to assemble all the points together.