React vs web platform — web components and layered APIs

Almost a year ago I said that React’s days are counted. I still believe in this statement.This is how all frameworks end. However I wasn’t right about the timing. Back then I said it is a matter of a year or two. I might have underestimated some factors. Now I have more understanding on the reasons why developers moved to React. MuleSoft uses Facebook’s framework in most of our UIs. Because of that I had to learn to use React. It’s a minimal knowledge, I admit, but enough to understand concepts and workflow. My biggest pain point is that React moved away from the web platform too far.

When I was evaluating my opinion about React I only focused on componentization of the application code. At the beginning of 2018 web components specification was finalised and all browser vendors agreed to implement the spec. Today only Edge still pending implementation of the last specification related to web components, custom elements , but it is under development. Componentization is one of the problems React solves. Now web components are natively supported in most of the web platform (giving the usage) so I am expecting less incentive to use React for this reason only.

At the time I didn’t take the other problem into the account. DOM virtualisation. I couldn’t understand the idea of using virtual DOM. I mean I could because I was using virtual lists already but I couldn’t understand why would anyone switch to a framework that is so far away from the platform that you have to learn web programming again. I underestimated how complex the problem is.

Web platform is the only platform that does not offer view virtualisation. In Android or iOS there is a view that allows to render huge sets of data without harm to performance. It’s because this view only render as much as it is needed for the user to see smooth animation when scrolling. It’s not the case for the web platform. There’s no low- or high-level API that would make the same thing. Because building virtual views is very complex not many applications have it and performance suffers. Especially when it comes to large data sets rendering. That caused web developers started seeing DOM as something bad. It’s not but we lacking tools to optimize rendering. React seems to fix both problems: virtualisation and componentization. It lowers however accessibility. When something is not in the DOM or is not rendered ctrl+for anchors won’t work.

Recently I learned about new spec for web platform called Layered APIs. It allows to add high level layer to the platform APIs based on web components that uses low level APIs and makes web developers life much easier. One of such modules would probably be “virtual-scroller” component (see proof of concept here). It finally adds view virtualisation to the web. The component allows to create as much of the DOM we need to render the page but it only renders the amount that is needed giving current conditions (viewport). For now it is only a proposition for the part of Layered APIs spec but because it is really needed I hope it will become a living standard.

Layered APIs are revolution in how web APIs are defined. So far the web spec authors only worked on web primitives and never on high level APIs. This APIs would allow the web to catch up with mobile operating systems.

Proposition of usage of the virtual scroller module:

<script type="module" src="std:virtual-scroller"></script>

<virtual-scroller id="scroller">
  <template>
    <section>
      <h1></h1>
      <img>
      <p></p>
    </section>
  </template>
</virtual-scroller>
<script type="module">
  scroller.updateElement = (child, contact) => {
    child.querySelector("h1").textContent = contact.name;
    child.querySelector("img").src = contact.avatarURL;
    child.querySelector("p").textContent = contact.bio;
  };
  scroller.itemSource = contacts;
</script>

This adds the second feature to the web platform that React currently “fixes”. It will take a time to standardise the spec and to implement it in all browsers. Look how long it took to standardise custom elements. But we need to remember that standardised APIs lives practically forever so it has to be done right.

My conclusion is still in favour of the web platform. We already have web components. We eventually will have DOM virtualisation. Currently we can use components like virtual-scroller or iron-list (and there’s more) to add this missing functionality. State management don’t have to be React’s. From business perspective it is just a matter of time when Facebook managers decide that the web platform offers the same capabilities as React. When that happens development of React as a framework will became unjustified financially and React will end up like GWT — as a community project no longer developed by the original team. If today I would start a new business application I would think twice before investing in React.