Web Components: The Framework-Free Renaissance

Getting tired of their framework-free narrative.

What they are doing is backing in the browser, via specifications and proposals to the platform, their ideas of a framework. They are using their influence in browser makers to get away in implementing all of this experiments.

Web Components are presented as a solution, when a solution for glitch-free-UI is a collaboration of the mechanics of state and presentation.

Web Components have too many mechanics and assumptions backed in, rendering them unusable for anything slightly complex. These are incredible hard to use and full of edge cases. such ElementInternals (forms), accessibility, half-style-encapsulation, state sharing, and so on.

Frameworks collaborate, research and discover solutions together to push the technology forward. Is not uncommon to see SolidJS (paving the way with signals) having healthy discussions with Svelte, React, Preact developers.

On the other hand, you have the Web Component Group, and they wont listen, they claim you are free to participate only to be shushed away by they agreeing to disagree with you and basically dictating their view on how things should be by implementing it in the browser. Its a conflict of interest.

This has the downside that affects everyone, even their non-users. Because articles like this sell it as a panacea, when in reality it so complex and makes so many assumptions that WC barely work with libraries and frameworks.

Home Assistant [1] has been written using web components and it has been great. In 13 years that we've been around, we never had to do a full rewrite of the frontend but always have been able to gradually update components as needed. Not being tied to the JavaScript industry upgrade cycle (which is short!), has allowed us to pick our own priorities.

We currently use Lit for the framework on top (you do need one, that's fine). For state management we just pass props around, works great and allows community to easily develop custom cards that can plug into our frontend.

The downside is lack of available components. Although we're not tied to a single framework, and can pick any web component framework, the choices are somewhat limited. We're currently on material components and migrating some to Shoelace.

I talked more about our approach to frontend last year at the Syntax podcast[2].

[1] https://www.home-assistant.io [2] https://syntax.fm/show/880/creator-of-home-assistant-web-com...

> A component deep in your UI hierarchy can dispatch an event that bubbles up through the DOM tree

Sounds like people are about to rediscover why Redux came to be.

I lean towards vanilla javascript and webcomponents myself, and eschew large frameworks in favor of lighter, or in some cases, no framework at all.

That said, this and many other webcomponent articles mischaracterize usage cases of webcomponents:

1. Being "Framework-free"

Frameworks can mean anything from something massive like NextJS, all the way to something very lightweight like enhance.dev or something more UI-focused like shoelace. To suggest being completely free of any kind of framework might give some benefits, depending on what kind of framework you're free of. But there's still some main benefits of frameworks, such as enforcing consistent conventions and patterns across a codebase. To be fair, the article does mention frameworks have a place further down the article, and gets close to articulating one of the main benefits of frameworks:

"If you’re building something that will be maintained by developers who expect framework patterns, web components might create friction."

In a team, any pattern is better than no pattern. Frameworks are a great way of enforcing a pattern. An absence of a pattern with or without webcomponents will create friction, or just general spaghetti code.

2. Webcomponents and the shadow DOM go together

For whatever reason, most webcomponent tutorials start with rendering things in their shadow DOM, not the main DOM. While the idea of encapsulating styles sounds safer, it does mean parts of your page render after your main page, which can lead to DOM elements "flashing" unstyled content. To me, this janky UX negates any benefit of being able to encapsulate styles. Besides, if you're at a point where styles are leaking onto eachother, your project has other issues to solve. The Shadow DOM does have its use, but IMO it's overstated:

https://enhance.dev/blog/posts/2023-11-10-head-toward-the-li...

Web components are already very mature. I have used them to develop a desktop and mobile note-taking application called Simark, which is available on the Apple App Store. If you are interested, you can download it and take a look. It has zero UI framework and is 100% web components.

The shadow DOM and all the encapsulated CSS shenanigans it comes with has get to win me over. I do reach for custom elements quite often though.

A lot of times I just need a small component with state simple enough that it can live in the DOM. Custom elements gives me lifecycle hooks which is often all I really need for a basic component.

As someone who spent the last year messing around with web components, I think there’s some cool stuff there but I have a new level of appreciation for actual components APIs from actual frameworks.

It’s more a custom element API than a component API, I mean that line in the sand is pretty subjective, but I just can’t see this API being a part of any major web framework, I can see that with shadow dom, I can’t see that with the whole customElement.register and garbage you have to do in the constructor.

Also the goals of this API are just not aligned with the purpose of a framework/component system. I do encourage people to play around with them but it’s really annoying to hear how they’re being promoted they’re are a lot less exciting than the platform advocates are willing to admit but that doesn’t mean they are useless but we need up stop pretending they’re the future of web applications.

Frameworks are often designed with the goal of managing application complexity without being overwhelmed by the shortcomings of the platforms. Web Components have done little to reduce the need for such a thing.

I just wish declarative shadow dom had bit better support or declarative custom elements landed already. Problem is that now i have to duplicate the template part, instead of just declaring it once and then specifying component instances many times.

Wow, XSS just waiting to happen.

  <h3>${this.getAttribute('title')}</h3>

I have 3 web components working inside the body frame - rectangle with text, with image or blank, been using that since the Renaissance.

I skimmed this. I use web components a lot. Unless I'm mistaken, they don't provide reactivity; you have to write that yourself. Reactivity was the feature that launched modern js frameworks so I think the article really overstates the case.

The article also misses something more important: broad native ES module support in browsers means you don't need a build step (webpack).

The "AI makes it easy!" part of the article makes me want to hurl as usual. And I'll stop short of an accusation but I will say there were some suspicious em dash comparison clauses in there.

I tried Web Components to create a `<passkey>` element to allow Passkey support in forms without having to write javascript as an end-user.

I ran into https://github.com/WICG/webcomponents/issues/814

As long as this is not fixed I can't take Web Components seriously.

I’m an early fan (Polymer, anyone?) but somehow the mindshare is just not there and trying to evangelize it to mainstream was too much. So now it just kinda there for people to slowly discover when they run into niche use cases.

Frameworks provide real value, and one will likely end up using a framework like Lit. As soon as your page logic gets complex enough, you'll need many little things to make it work, and eventually a framework is what you want.

(Ignore me if all you do is readonly pages with no state transition)

The biggest issue is the lack of tooling and the inability to manage a shared state. We actually ended up creating new libraries like Stencil & Lit.

Custom Elements missed the mark with the problem frameworks solve. We don't necessarily need custom HTML, we needed easy way to build and manage the whole data and visual flow locally while treating the backend response as a datasource.

Nowadays, I use web components for one-off, isolated components as a replacement for iframes, but rarely for anything complex.

Web Components are amazing for distributing frontend libraries. But they're awful as building blocks to replace a framework like React, Vue, Svelte or Lit with.

I blame the Chrome people for the misleading naming. The entire term "Web Components" is ridiculous. If only they'd stuck with the technical term, "custom elements", then none of this confusion would've happened. It's pretty obvious to me that custom elements are a great idea for distribution (add a script tag, poof, magic new HTML element exists!), but the term doesn't imply anything about how to best build the internals of your app.

Thing is, Web Components are a needlessly painful abstraction. There's properties and attributes, they're kinda sorta the same but not really and you gotta sync them up manually, the naming is global so you get zero modularity, really it's all a mess. And at the same time, you get no support at all for things like props handling, event calling, data binding; none of the stuff frameworks give you.

But Web Components are also what enabled my company to distribute a single UI library that works with all web frameworks. It's a fantastic technology for that.

tldr:

    - distributing UI components: web components
    - building an app: just pick a framework already

Every time Web Components is being fronted, one has to duly inform the reader that Apple _rightfully_ refuses to implement what in my humble opinion is at least one broken piece of the specification that if implemented -- and it is implemented faithfully by Chrome and Firefox browsers -- in principle breaks the Liskov's Substitution Principle: * https://lists.w3.org/Archives/Public/public-webapps/2013OctD... * https://lists.w3.org/Archives/Public/public-webapps/2016JanM... To be fair, this only concerns so-called "custom elements" that need inheriting existing HTML element functionality, but the refusal is well explained IMO. Meanwhile everyone else is just chugging along, like it tends to happen on the Web (e.g. History API giving way to Navigation API that in large part was designed to supercede the former).

To all of the above I might add that without "custom elements" Web Components is severely crippled as a feature. If I want to sub-class existing functionality, say a `table` or `details`, composition is the only means to do it, which in the best style on the Web, produces a lot of extra code noone wants to read. I suppose minimisation is supposed to eliminate the need to read JavaScript code, and 99% of every website out there features absolutely unreadable slop of spaghetti code that wouldn't pass paid review in hell. With Web Components that don't implement "custom elements" (e.g. in Safari) it's a essentially an OOP science professor's toy or totem. And since professors like their OOP theory, they should indeed take Liskov's principle to heart -- meaning the spec. is botched in part.

I love web components and, for the past few years, I've been building a simple demo app that is, itself, a web component[0]. The main problem I've found with web components is the ecosystem. The reason 1000 different devs can make react/svelte/vue components that all work together (obviously with some exceptions) is because they have the framework as a basis. If you want to use pure web components, you can't rely on a framework for any kind of architectural certainty. You're at the whim of what the other dev needed when they built the component.

And I don't find that bad for web components, as a whole, but if you wanted to build an app, you would most likely just use a web component framework (something that uses a base component and extends the rest from it), in which case you're limited to what that framework provides (and it won't be as robust as any non-wc framework). But if you're just looking to quickly slap in a component that "just works", you would have to do some real diligence to make sure it would fit which just is not a problem for any defined framework.

My approach has been to make a complete suite of CC0 components (which also meant no dependencies that I didn't write myself, so that I could make each dependency CC0, too), and let each component be an entirely standalone library, so that you could treat them like drop-in new html elements, rather than libraries to ingest and work with (in effect, the component should be as self-sufficient as an <input> or a <select> and require no js interaction from the consumer to work; just add the script and use the new tag). Of course, the major downside of that is that each component has to be it's own library which needs competent documentation (at least, I'm not going to remember how 15-20 different components all work in fine detail. I want some docs and examples!), and no other dev has any way of knowing that these components won't require an additional "base" script or component to work.

Overall, though, I'm happy with the results I've got (just finishing up all that documentation, at this point). And I definitely don't mind things like web components "not having reactivity" or "state", because I, personally, don't like being forced to push every piece of data through the rube-goldbergian plinko machine of reactive state. Different paradigms for different purposes and all that. So between not being forced to use it and having the events and attribute observation to be able to use it when I want it, I'm pretty satisfied with the state of web components on that front.

Honestly, the biggest issue I have with web components is how they work with "parts". I had to write a whole little library to make working with parts reliably comfortable for both library dev and consumer devs. I'd love a way to query on the "part" attributes, while within the component's shadow dom. As it stands, the best you can do is `[part="my-part"]`, which has obvious shortcomings if you're trying to use it like a class. Multi-classed elements are easy to select; doing anything complicated with part selectors would quickly spiral into a lot of `[part*="red"]:not([part*="redorange"])`, instead of `.red`, or whatever. The light dom is better because the ::part() selector treats parts like classes, so you can write selectors like class selectors. But, of course, you're limited to the part itself, so every single thing that should be stylable (in a lot of components, every single element; implementing devs should control style and display layout, just not functional layout) needs to have a part. And that's still a fairly superficial problem compared to the issue of not being able to automatically convert all "part" attributes into an "exportparts" value for the parent element. Again, not something that most libraries will need, but when you do need it, it's crazy that I would have to make a porting solution, myself. That's just begging for errors.

In any case, I generally agree with most of what the article has to say. As others have pointed out, some of the examples aren't really "best practices", but the overall point that web components are perfectly capable of building with is a solid one. I do still think that the old adage holds true, though: 'if you don't use a framework, you'll build one'.

[0] https://github.com/catapart/magnit-ceapp-taskboard-manager

(Notes for the demo pages: not production ready; the component will write to an indexedDB instance in your browser; the pages will add to your browser history [an option that is currently on, but is not the default config of the component];)

I used to write all my webapps in pure lit webcomponents but eventually moved onto react

i think now with signals proposal to new ecmascript, one can easily have both web components and reactivity. my main question is, which tool do you use to have normal html syntax highlighting inside web components?

[dead]

The question is no longer whether they work, but why more developers haven’t embraced them.

Anytime it's attempted, someone tries to scare them into thinking that their code will impossible to maintain without a framework to provide "structure"