The Case for Web Components: A Simpler, Framework-Free Future for the Web (opens in new tab)

> 1. No Need for Node.js: Keeping Development Simple

You can have code that requires a server or build script with and without web components. You can have code that doesn't require those with and without web components.

> 2. Native Browser Support: No Server-Side Rendering Headaches

This is the point that makes the least sense. You can opt out of server-side rendering when using a non-WC framework, and you lose the headaches. If you don't want server-side rendering and are just glad that Web Components gives you an excuse to not support it, that's silly. If you want server-side rendering, it is possible with Web Components but there's currently a lot more guidance on how to do that with popular non-Web Component frameworks.

> 3. No Compilation Required: Write Once, Run Anywhere

Duplicate of #1. smh

> 4. Universal API, No Lock-In

Does Lock-In just mean including an unencumbered open source library? The API doesn't provide a whole lot. That's why a lot of people are using Lit. When you have Lit, you have some of what is called Lock-In.

> 5. Smaller, Faster, and More Performant

It encourages you to do things that are less performant, maybe only by a little bit, but still. Having a shadow DOM for each item in a large collection means you'd likely have an event handler instead of one that bubbles up. Luckily this is totally optional with Web Components. You can have a Custom Element without a shadow DOM, or you can just create plain elements for items in a large collection and have those bubble up. You can also have your events be composed and they will cross the shadow DOM boundary, though that is tricky in some cases.

> 6. Better Long-Term Maintainability

If you are using a framework (or library), you have to keep up with changes to the framework. If you aren't using one, you may have to do extra maintenance because you're doing something extra that would normally be handled by a framework (or library).

> Conclusion: Embracing the Simplicity of Web Components

Some stuff is simple, some stuff is not.

Edit: I realized that Lock-In could refer to how frameworks try to manage the child elements by default. This can be disabled, and you can have something manage its own child elements. Otherwise you wouldn't be able to use stuff like CodeMirror inside of React. That tends to be done with a ref.