> Web components get imported and registered at the global level. This also means if two different libraries have a component called my-button, you can’t use both of them.
In my opinion, fundamental problems like these really ought to be addressed before things become part of the web platform.
I thought this was going to be about shipping web components made with React, but it's about consuming web components from apps made with React, which is a much more sensible thing to do in my opinion
The problem with web components is that they've never had a templating/reactivity story, which means if you wanted to build one reactively you'd have to ship it with a framework, and shipping a separate framework per-component is just unworkable. So they don't make sense internally to an app, and they don't really make sense for a large library of components. They only really make sense for a single hand-crafted widget that a company wants to ship to various consumers who may be using different frameworks
My dream is still that browsers come up with an actual reactive-templating API for HTML. If they did that, we might finally be able to get rid of frameworks for many common use-cases
The good: this seems like a necessary step towards standards-based development
The worrying: we might be setting up for a scenario where newer developers are bewildered by mixed paradigms within what was (at least once upon a time) a simple library
Full disclosure I work for Mux (OP), so as a team we're web component fans, but I'm personally still almost exclusively writing React. So...personally, saying this with love, but add this to all the new esoteric hooks in React 19 and it feels like React might be losing the plot.
Why hasn't Facebook made a browser that runs React/JSX as native code? Should work well for their ad business.
Make a Llama 3 based search as the home page :) And fully support AI/LLMs in the browser :)
One of the biggest problems I run into with Web Components is how to share common CSS styles between them. I understand that goes against the idea that each web component should be encapsulated, but sometimes this is desirable.
Say you have a component library where each component depends on a base set of styles and you don't want to load duplicate styles for each component.
Is there a best practice around this yet?
Alas that Web Components will be forever held back from their true potential until WebKit pulls their obstinate finger out and implements the customised built-ins half of the standard. Or proposes something better that otherwise solves the content model issues. To date they have done neither, leaving us with a shortfall of composability and a fistful of janky polyfills
> But that doesn’t exist in the web components world (at least not yet). When you use <my-button> in a React component, you don’t have to explicitly import my-button from anywhere inside that file.
Technically you can just export a string with the name of your web component:
export const MyButton = 'my-button'
import MyButton from './MyButton'
...
return <MyButton />
In 18 years I have never once actually used a Web Component. What is the point?
Embrace, extend, extinguish?
Having worked with internal company web components, I despise them. In a bureaucracy, bad and buggy web components are a blight because, unlike a bad React component,ad hoc fixing them requires a mess of searching and tons of boilerplate. I accept this news with mourning.
It seems like Web Components are ideal for libraries shipping pre-built components, which is probably why Mux finds it compelling. From Mux's point of view, they want the highest level of compatibility with the least amount of framework lock-in. For example, they don't want to have to ship a library for React and another one for Vue and another one for bare bones JS/HTML.
In terms of building a web app where you control the environment end-to-end, I don't think there's any inherent upside to using Web Components over React.