React • 6 min read

Will Web Components Replace React?

Will Web Components Replace React?

This past year (2021), in Stack Overflow's survey with over 80,000 participating developers, React pulled ahead of jQuery as the most commonly used web framework. With its declarative, component based API, support for data binding, event and state management - what's not to love? Over nearly a decade React has proven its great benefits, but has also unveiled some very noteworthy drawbacks. "Web Components" represent a set of browser technologies and could pave the way for alternatives to UI libraries like React.

In this post I compare these two UI technologies. What does the future of UI development look like... will Web Components replace React?

Note to readers of the future: this post is specific to trends of the times and may no longer be relevant.

Pros and Cons of React

React is known for its declarative, component driven API. But, when you think about it, differences to UI frameworks of the past aren't necessarily ground breaking. For example, before React - Backbone.js was building momentum in JavaScript framework trends, giving structure to web applications with an API based on "views" and "models". I find the concept of "views" similar to "components" in that a piece of UI is declaratively defined and bound by events and data.

The driver of React's success isn't necessarily what it does, but how well it does it. It does component driven UI very well!

Pros of React

  • Unopinionated: As a framework, React provides enough leeway to choose your own flavor of things like CSS, JavaScript, TypeScript, global state management, effect management, etc.
  • Declarative, component based API: Not only does React provide an API for modular development, but it does so very well. The component structure in React is clear especially with its coupling of JSX.
  • The Virtual DOM and Reconciliation: At the heart of React is its reconciliation mechanism. React manages an in-memory DOM tree that subscribes to and handles change so that the real DOM is only updated when necessary, in theory providing render optimization.
  • Documentation: React has provided great documentation since its inception and has set the stage for related frameworks and libraries which generally do the same.
  • Community: React has a large and continuously growing community of engineers. Not only does it have a large number of contributors but also related projects with large contributor levels. Many React based open-source projects exist, including component libraries, that provide great value in streamlining UI development.

Cons of React

  • Unopinionated: Although React prides itself in being unopinionated, it's not always a good thing. With so many options to handle styling, rendering (SSR vs CSR vs SSG, etc), state management - developers are forced to make difficult choices that don't always end well. Without such enforcement comes a lack of standardization.
  • Frequent major changes: Within a short period of time React introduced multiple major changes to its core, including hooks and deprecation of life cycle methods in favor of function based components over class based components. From the inside, these improvements seem good overall, but from the outside -the benefits aren't so clear. Every day developers are beginning to learn React and even for those who are more experienced, working with a moving target requires a lot of attention that could be better used elsewhere. Don't get me wrong, I prefer using hooks and functional components, but I still have difficulty describing and justifying these improvements to those who aren't familiar.
  • Performance: As tools like Lighthouse and Web Vitals have emerged, it's been clear to me that after implementing React and after choosing companion technologies to handle styling, state management, etc - most websites suffer in initial page load performance (typically the "unused JavaScript" callout from Lighthouse). Even with all the build tool options, code splitting, etc... React based websites continue to suffer.

Pros and Cons of Web Components

Comparing Web Components to React is not a one-to-one comparison as these are two very different technologies. React is a UI framework while Web Components represent a set of native browser technologies. In fact, because Web Components involve native browser technologies, they could theoretically be used with React and React with them.

Virtual DOM vs Shadow DOM

These distinguishing characteristics make for an interesting comparison. React's "virtual DOM" is meant to solve a different problem than the "shadow DOM" used by Web Components. React's virtual DOM is an in-memory representation of the actual DOM, subscribing to bound data and event changes so that actual DOM updates are minimized. Web Components deal with the actual DOM and a shadow DOM has the primary purpose of encapsulation.

Shadow DOM is just normal DOM with two differences: 1) how it's created/used and 2) how it behaves in relation to the rest of the page. Normally, you create DOM nodes and append them as children of another element. With shadow DOM, you create a scoped DOM tree that's attached to the element, but separate from its actual children. This scoped subtree is called a shadow tree. The element it's attached to is its shadow host. Anything you add in the shadows becomes local to the hosting element, including <style>. This is how shadow DOM achieves CSS style scoping.

~ Shadow DOM v1: Self-Contained Web Components

Pros of Web Components

Shadow DOM is one of the three Web Component standards: HTML Templates, Shadow DOM and Custom elements. Some pros listed below are specific to the shadow DOM as described in the post linked above, but also relevant to overall benefits of using Web Components as a whole.

  • Native browser APIs: Without the need for numerous prescribed frameworks, a developer can lean more into native browser APIs. The result of this can reduce code complexity and web page performance.
  • Isolated DOM: A component's DOM is self-contained (e.g. document.querySelector() won't return nodes in the component's shadow DOM).
  • Scoped CSS: CSS defined inside shadow DOM is scoped to it. Style rules don't leak out and page styles don't bleed in.
  • Composition: Design a declarative, markup-based API for your component.
  • Simplifies CSS - Scoped DOM means you can use simple CSS selectors, more generic id/class names, and not worry about naming conflicts.
  • Productivity - Think of apps in chunks of DOM rather than one large (global) page.

Cons of Web Components

  • Sparse open-source projects: There are some great Web Component based projects out there, but they are more sparse than React based projects (at the time of this writing).
  • Sparse documentation: Although, there is good documentation out there - a central repo per se, doesn't exist - leaving developers to piece together knowledge.
  • Unknown SEO implications: Some tidbits on the internet, like this one, report SEO support for Web Components with mixed results. Because Google search is a black hole, most will find it a risky endeavor to embark on such a significantly different way of constructing a web page.

JavaScript Fatigue

The above meme was my favorite of the week from Twitter. It highlights a fear of missing out we feel as JavaScript engineers in the breeding ground of trends turning up at a rapid pace. This occurrence isn't new in the JavaScript landscape... I remember feeling it before React.

However, despite all of the language’s progress and growth, many developers have said they are dealing with JavaScript fatigue. JavaScript fatigue refers to the inability to keep up with the latest tools, the fear of becoming obsolete, the constant change of the ecosystem, and the overwhelming choice, according to the security company Auth0.

~ Is the JavaScript fatigue real?

I do think JavaScript fatigue is real. It was real ten years ago and it's even more real today. Software engineers entering the field of web development have the impossible task of learning tall lists of JavaScript frameworks in their first jobs... before mastering native technologies like HTML, CSS and JavaScript. Web page performance is arguably worse than it's ever been when browsers need to load piles of unused CSS and JavaScript. Code complexity is driving developers bonkers when writing code becomes blocked by limitations or bugs from upstream frameworks.

This JavaScript fatigue could drive the future of UI web development towards a world of less frameworks and prioritization of native browser APIs.

Will Web Components Replace React?

I think the answer is "yes" - Web Components will replace UI frameworks like React. Although, I don't think UI frameworks will go away... we love them too much 😘 I believe the future of UI web development will eventually lead in a direction towards standardization and native browser technologies. Frameworks will still exist, but hopefully with a closer connection to browser APIs and features. Native JS, HTML, and CSS features like @layers are evolving faster recently and will support this direction. For React lovers, my advice is to continue with it, but be prepared for future change and dabble with Web Components. Below are some interesting projects using Web Components that are building serious momentum.

  • Lit: Lit is a simple library for building fast, lightweight web components. At Lit's core is a boilerplate-killing component base class that provides reactive state, scoped styles, and a declarative template system that's tiny, fast and expressive.
  • FAST: Interfaces built with FAST adapt to your design system and can be used with any modern UI Framework by leveraging industry standard Web Components.
  • Material Web: Material Web is Google’s UI toolkit for building beautiful, accessible web applications. Material Web is implemented as a collection of web components.