React has been gaining popularity at a rapid rate since its launch. React provides a lot of new things, but someone reading about React for the first time is fascinated by the Virtual DOM implementation because it completely removes one of the major parts of writing any web application, DOM manipulation. This, unfortunately, hides a lot of other good things that React brings to the table, such as how it facilitates the use of functional programming techniques in front-end web development. But, even more important is the fact that it is declarative, well almost.
The two layers of React
To understand React (or React Native), we should break it into two parts. The first part provides the APIs needed by developers to tell the framework what should be rendered. The other part (invisible to the developer), interprets these instructions and, renders or updates the view in the most performant way possible.
The core APIs remain the same when moving across various view technologies though the view primitives change. Thus, React can be extended to support any view technology by implementing an engine which knows how to redraw the view.
Virtual DOM is one of the layers
The virtual DOM implementation used in React is just one way of implementing the engine which can redraw the DOM elements. Another naive way is to just replace all the DOM elements of the page. There are other virtual DOM libraries in existence today, which are completely independent of React, and there will be others cropping up.
Unfortunately, some of the links above are not just virtual DOM implementations but also try to implement a framework, thus, handling two different concerns.
Declarative View Engines
In ASP.NET MVC, a view engine is supposed to create HTML from the view, which is markup with some custom code. As server-side view engines, they are enough, but for client-side this is not enough because we have to modify the DOM without refreshing the page.
The browser itself includes a view engine, that can understand the HTML and render the page. It also provides the DOM APIs to modify the view easily (ya, sure). React has shown us that we can create a declarative abstraction over the DOM and provide a declarative view engine. A DVE will be using some kind of APIs to allow developers to specify what needs to be displayed and where.
Let’s delve a bit into the kind the APIs a DVE may provide. A DVE needs a DSL to describe the what is to be rendered. This can be a template language or a set of functions. It will also require an API to render the view in a container.
viewSpec = /** Description generated by DSL **/;
DVE.render( viewSpec /** Or template file path **/, container);DVEs would require one final API to update the tree under a particular container.
DVE.update( viewSpec /** Or template file path **/, container);Note that a DVE can be created not only for the DOM but also for any other view technology. The virtual DOM concept is just one way to implement a declarative view engine for the DOM.
The Future
I see a future where we have libraries for:
- creating component (view) hierarchies
- doing communication between various components.
- handling data manipulations, and
- Declarative View Engines
There may be frameworks that provide all this and an opinionated structure. We will see developers using both frameworks and using these small libraries to create applications.
A developer in the future will be able to choose a view engine based on their requirements. The engine may use the virtual DOM concept or may use something that we have not yet thought of, because virtual DOM is just a strategy, which can be replaced by any other better strategy, maybe even at runtime.
Update: Incremental DOM, an alternative to Virtual DOM.