Web components are okay

I tried to understand the referenced article "Web Components Are Not the Future" - but found that there weren't many convincing arguments.

The current state of Front-end frameworks is an absolute mess. Speaking for myself, I don't want to learn a complex framework. I don't want to learn magic that I don't understand without reading the documentation (useState, createSignal et al). Magic in frameworks is often a hack, unlike magic in libraries. The first library I used was Prototype. It felt like magic, and it truly was. And so was jQuery, and Backbone. I never had to guess what "useState" does behind the scenes.

There are many things which don't carry over into Web Components from current JS frameworks. But if you start from Web Components (ignoring everything you know about frameworks), it suddenly becomes intuitive. And it brings in abilities which are missing otherwise, such as isolation via Shadow DOM. It grows on you.

In my view the only thing we should retain from the React era is JSX (for many reasons, true type-safety, autocomplete etc). I wrote a library last week for using Web Components with JSX. No magic other than JSX. https://webjsx.org

I think part of the reason people talk past each other on this issue is because they're optimizing for different things. If you're working for a VC-backed startup with a central product that needs to move quickly and is going to require constant maintenance anyway, a framework might be a good fit for you.

But I work in an academic lab. We don't have tons of money to maintain the apps that we've written. We need them to just keep working once funding has moved on to new projects.

We're just finishing up a rewrite of an app from Vue to Web Components. It had dependency rotted to the point where we couldn't update anything because of dependency hell. Rather than spend hours trying to fix it, which we've done before and would have to do again until the end of time, I decided to experiment with Web Components. The experience was immediately so nice that we went all in. No regrets. We went from ~15 dependencies to ~1 (d3js).

If you're curious to try the apps, old one[0] new one[1].

[0]: https://bam.iobio.io/

[1]: https://bam2.iobio.io/

One of the things I really appreciate about Svelte is its support for generating Web Components through the Custom Elements API. Since Svelte compiles down to plain JS/HTML/CSS, creating reusable components that work across any framework or vanilla JS becomes seamless. https://svelte.dev/docs/custom-elements-api

I have been following the web components discussion for years now and just don't see what I can do with them that makes my life as a fullstack developer better.

All the examples I have seen use them to template some data into html. I can do that with handlebars already.

Am I missing someting?

The worst part about web components and the shadow DOM is how they can prevent browser extensions from working correctly, or working at all.

And the browser vendors aren't in a hurry to remedy this situation.

I think one of the biggest "mistakes" with web components was coupling them in people's mind with shadow dom.

For app dev (not library dev) web components are a super lightweight easy option when you stick with the light dom.

You can continue to use bootstrap or tailwind or whatever css thing you like, but get great functional encapsulation with near zero cost, especially if you use lit-html or something similar as a renderer.

My teams have generally found working with native web components refreshing. It takes a dev coming from the framework world about a week to adjust, and then they never want to go back.

Just using simple class properties and a manual call to a render function on set() gives you all the benefits of reactivity without all the hassle of frameworks.

The problem most people have with getting started with WCs is that there's not much out there showing how do to it in "easy mode".

Most of the getting started things throw you right into shadow dom, css parts, and all these really painful technologies that were primarily intended for use by library authors, not app devs.

I've been building apps with native WCs for a long time now, I should get off my keister and write a guide on how to make your life easier with WCs, something like "The Good Parts".

I think this minimizes the fact that interop - the main selling point to me as a user - comes at a performance cost where every component you use could have its own unnecessary runtime attached.[1] Using a framework like Lit with web components is the recommended way to use them.

This cost will compound over time where new frameworks emerge, and components get stuck on older versions of their frameworks.

I can't see this as anything but significant, and not to be minimized. Having multiple redundant libraries on a page is not the direction I would advise anyone to take, particularly not when baked into the accepted best practices. This bodes poorly in the long term.

I've listened to the arguments from web component advocates in blog posts, social media, and videos for years now, and I should be in the target market. But on top of the interop tax, they're full of negatives that aren't present in the mainstream frameworks.

Interop works great within each framework's ecosystem. The same dynamics that cause developers to seek interop cause them to huddle around a small number of mainstream frameworks. So we get a few vibrant ecosystems that push the state of the art together. Web components cannot keep up on the tech side of things, and introduce a ton of complexity to the web platform - ignorable to me as a dev, but not for browser implementers - in service of their early 2010s designs.

[1] https://x.com/Rich_Harris/status/1840116730716119356

I love web components and am bullish on them breaking us out of the current frontend hellscape we have created for ourselves. I was recently able to give a short talk on the future of frontend, and it seemed like a lot of other people are hopeful for a way out as well.

As far as performance we built out a data table for our DB GUI that can load in hundreds of thousands of rows and the scrolling through is still buttery smooth.

We actually are getting ready to release our web component library, it's a bit early and rough around the edges but would love to get some more eyes on it! www.astra-ui.com

A few months ago I started a job where I inherited a JS code base that is around 250,000 lines. It was one big class, with several sub classes, that did everything. Some files were 30k lines long.

No frameworks, no reactivity. If you click a button, you had to update everything on the screen with event listeners manually.

Took the guy years to write it. It's like a monk got locked in a cell for years with a basic book of javascript.

I started by refactoring into web components, because I had to do it piecemeal. It's been a big help, and I've cut 50k lines of code so far. But the real point was to just learn everything the old code was doing before I start a rewrite.

One thing about web components that I've appreciated is that they can work without JS enabled (at least in theory). I've done this a few times for progressive enhancement.

Broadly I agree with Nolan, though. Web components have enough rough edges that they're not going to take over the world in the current state. But, they are pretty nice for certain use cases.

I'm not sure what he means by not playing well with server side rendering though. I've been doing that without issues.

Web components are okay as long as you only use them to progressively wrap actual HTML elements. If you're using custom-elements by themselves like a JS frontend replacement and just making entire web pages full of blank grey boxes that do nothing without JS, you're doing a bad job.

See: https://blog.jim-nielsen.com/2023/html-web-components/

I don't really get this "frameworks vs. web components" discussion. They are both tools to solve different problems. Frameworks exist to render your view as function of state in a declarative way. They use web primitives to define the view layer. Web components can help there, but it doesn't solve the state management issue that frameworks aim to solve. That's a different problem that requires different solutions. In my opinion they can perfectly co-exist.

How can it be possible that we are in 2024 a no one seems to be proposing the most obvious improvement to the web, which is to create a new standard designed for web applications and let the HTML alone serving it's original purpose, which was to serve documents? (H*T*ML the T goes for "TEXT"!). Instead of that, and make things complex and unmanageable to the extreme, to "improve" things now we dropped out completely the MVC philosophy and went completely ahead with an spaghetti mess of Javascript, HTML, CSS, and create-your-desired-tags-at-will everywhere, aka Components.

PS. And not even mentioning Madnesscript which deserves another chapter in this story of horror.

I really dislike the Shadow DOM part of Web Components. Someone didn't learn any lessons from past mistakes and went and reinvented iframes. Trying to write tests or any automation for a web page that uses shadow dom is an exercise in misery, unnecessary at that.

Web components are lacking some basic functionality that makes using them in something complex difficult.

For example, one of the deal breakers we faced was the inability to unload and reload a web component. Once you load a web component you’re stuck with it until you refresh the browser.

You cannot have an SPA with one page loading 1 version of the web component and another loading another version without some ugly namespace mangling.

I dig WebComponents because I love building on standards which promote interoperability across frameworks and have long term lifelines. Standards reduce platform + dev lock-in and reduce framework balkanization and frankly chaos in many cases. You are a better developer if you understand the root standards and core systems, which WebComponents get you closer to.

I also like the Lit Framework (https://lit.dev/) from Google which is rarely mentioned but it is quite nice for some of the simplifications and extras you might need when building them but it doesn't get in the way or try to take over your entire domain with dev-lockin.

Whether going direct to WebComponents or a higher level simplification like Lit, they really are a freedom from dev lock-in that is nice to see.

I'm bullish on web components as a distribution mechanism. In fact, we're currently hard at work betting our entire company (https://talkjs.com - a component library + API for chat) on it.

I agree with Nolan here that the performance is fine. People keep comparing web components to React or Solid components, but the latter inherently have a tiny granularity whereas web components is primarily a way to distribute reuseable elements, not an application framework on its own. Don't make every tiny piece of your app its own little web component (or, at least, don't do it without a framework such as Lit to skip the pain). But web components are the way to build a component once and have it usable in all web frameworks (including none at all) out of the box. That's fantastic! And also unprecedented (on the web, that is).

It bothers me that so much of the discussion is still about whether web components are good primitives to build frameworks on top of. No, not really, they're pretty awful for that! But for distribution, nothing else comes close.

I'd love it for some alternative standard to emerge, without all the awful design choices of web components. And I agree with Rich (Svelte) and Ryan (Solid) that WCs being built into browsers are getting in the way of some other collective component interop design emerging. But until the framework authors stick their heads together and invent a fast, modular, non-shitty, property-only, functional-smelling standard for distributing components, I'm sticking with web components. For component authors, the only alternative is making a React version, a Preact version, a Lit version, a Svelte version, a Vue version, an Angular version, a Solid version and a vanilla JS version of the same UI component. That's awful! Web components are clunky but they're here, now!

Let me explain the argument to you:

> You can always add another layer of abstraction to solve a problem but removing one can be difficult.

The argument being that there's no need to add anything to the browser stack and make it even more complex when it doesn't add any essential capability. There's already JS making everything possible; and yet, they keep on piling stuff. When with custom elements specifically, you also require JS anyway (to declare them).

> Elements are not components.

Idk maybe for "web devs" the concept is difficult to grasp that HTML isn't for them. It's for text authors, and as such a markup vocabulary where low-level elements are placed next to complex custom controls nilly-willy isn't really a useful evolutionary direction.

I like seeing accessibility respected. Good post.

I use web components, but I often want to design classes as MVC. It isn't obvious how this should work (though I assume the Web Component spec authors discussed the topic at some point). The awkwardness is:

(a) When you instantiate your View class (ie: 'web component') from JS, you probably want your Model and View to be 'owned' by properties of the Controller (eg: con.model and con.view). However...

(b) when an HTML tag instantiates your View, the View has to create its Model and Controller. And now there's no obvious place to store a reference to the Controller.

As a result, you have either to stick the Controller in a global variable somewhere, or - more likely - end up, not just with 'con.model' and 'con.view', but also with a new property: 'view.con'

So... two paths to create everything (Controller-based, or View-based), and this ugly '.con' property stuck in the View.

But, aside from this gripe, Web Components are okay.

I did a project that used Shadow DOM and related tech to address the problem of embedding a widget into a partner’s web site without any risk of CSS interference. Worked great, but this was one medium-sized widget that did not interact with the rest of the page.

I wish web components had a bit more to them

1. I wish you could reliably parse their attributes in the constructor instead of connectedCallback, so that they play better with typescript readonly properties

2. I wish I could declare properties in the class and have them automatically map to an attribute

3. I wish I could construct them using html instead of manipulating domnodes manylually

4. I wish I could construct child nodes first so that I can compose webcomponents with other webcomponents

As it stands webcomponents provide the ability to construct a single element at a somewhat predictable moment in time, automatically. That's cool, but their interface is lackluster to me

Web Components are fun. I've played around with Lit, which some people have mentioned. Anybody tried Stencil? It looks similar from the outside but wondering how it plays out mid/late-term.

Safari is the only browser without the full support

*Supports "Autonomous custom elements" but not "Customized built-in elements"

I found a practical way to foster critical thinking skills and encourage independent thought at the end of Netflix's documentary, The Social Dilemma:

> I follow people on Twitter that I disagree with because I want to be exposed to different points of view.

Here is another good opportunity for it.

What’s missing in his point and examples about “performance isn’t everything” (aria properties, forEach, …) is that these are cases where you could optimize later when and if needed. Using forEach is a fluid coding choice at the time but if for any reason you need to optimize to a for loop you can with minimal fanfare. But buying into web components is more of a one-way door and harder to iterate optimizations, and that’s the problem.

Tech discussions are hard to have nowadays because people are highly biased in favor of their current tech stacks.

The religiousness which used to be restricted to programming languages has expanded to include frameworks, databases, test runners, infrastructure, CI tooling, libraries; literally everything is a religion nowadays.

It makes almost all technical arguments disingenuous and pointless. Like people arguing about whose religion is more correct. Observable facts don't matter so much.

People see arguments in favor of some alternative stacks as a personal attack against their career.

It's probably because companies themselves have become so focused on hiring based on these stacks. They have become a matter of livelihood.

In the old days, many companies saw software engineering ability as a separate skill; now they barely even use the word 'software engineering.'

This might be a stupid hot take, but I am surprised that so little of web UI exist outside of the browser. I mean why bootstrap or other frameworks are not managed by browser ecosystem? Why millions of people how to download same frameworks over and over?

> From my own personal experience: at Salesforce

lol

We do web components better than the web. We just call them Parsers.

Geniuses build for The Scroll first. Retards build Web first.

(Don't misinterpret, I love The Web, but The Scroll is on track to be 100x better)

Web components are not OK. They are shit. I wouldn't touch them, just as I wouldn't touch shit.

If you find React hooks hard to understand, then I really don't need to hear your opinion about anything, including about how web components and HTMX are so great. Just learn programming.