Skip to main content Accessibility Feedback

Will Web Components replace React and Vue?

Over the weekend, I sent an email to my newsletter subscribers asking them what kinds of things they’d like to learn about Web Components.

One of the most common questions I got back was some variation of…

Will Web Components replace JS libraries like React and Vue?

Personally, I don’t think so. Let’s dig in!

Web Components are a different kind of component

To me, one of the reasons why Web Components have taken so long to catch on is that they were originally described as “a browser-native alternative to React.”

Frankly, they do “React stuff” badly, and are in my opinion better suited to a different way of building for the web.

I do think they’ll play a big role in whatever developers move on to after React, though (in my opinion, static generator tools like Astro and Enhance).

So… why aren’t they the React-killer?

React and Vue’s game-changing feature is that you can update a JavaScript have the UI automatically react to that change and update.

You don’t have to think about it. It just works.

Web Components have no built-in mechanism for doing that. You can “roll your own” with Proxies, but as history has shown us, devs will always collectively reach for tools that do the work for them instead.

And even if Web Components had reactivity baked in (they do, but for HTML attributes, not JS objects), there’s no browser-native way to diff the DOM and selectively render just the things that have changed.

A lot of developers really like the single-file component approach you can use with React and Vue, where the HTML, CSS, and JavaScript all live in a single file.

You can kind-of-sort-of get there with Web Components, but it’s not what they’re designed to do.

Web Components work with the fabric of the web, and the weave of the web is to separate concerns.

What are Web Components good at?

Where Web Components really shine is as a way to progressively enhance the HTML you’ve already got.

I like to use them as an interactivity delivery mechanism.

I’ll wrap them around forms to make the form ajaxy. I’ll wrap them around a password field to add a “show/hide visibility” toggle. I’ll wrap them around a group of headings and text to transform it into an accordion.

<ajax-form>
	<form action="/path/to/server" action="post">

		<label for="username">Username</label>
		<input type="text" name="username" id="username">

		<label for="password">Password</label>
		<show-password>
			<input type="password" name="password" id="password">
		</show-password>

		<button>Login</button>
	</form>
</ajax-form>

I absolutely use them to generate and inject HTML, react to user interactions, and so on.

But I’m mostly using old-school DOM manipulation approaches. I could do the same exact thing without Web Components. They just give me a much more convenient wrapper for doing so.

With Web Components, I never need to run new MyLibrary(), or pass in a selector for my target elements. I don’t need to worry about how to handle multiple elements that all need to use the same library with some slightly different options. I don’t need to figure out how to scope behavior of my library to just the target element.

Web Components handle all of that, easily and beautifully!

How do you do all that?

In future articles, we’ll dive into some details about how they work and how I use them.

If you have any questions or things you’d like to see me cover, send me an email and let me know!