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...

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.

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...

But beyond that, they’re not really usable without a framework that can deal with state and reactivity across a whole application. And that’s fine! They fill a good niche. But just because the browser provides an API doesn’t mean it should be used whenever possible.

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.

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

Getting them to work well in various react and angular codebases is not easy. New versions of React work well with web components. Old version s of react need web component wrappers. Angular works out of the box with web components (aside from some quirks and sometimes encapsulation issues with the web components). However, web component form controls will not work with angular reactive form controls and require an implementation of the control value accessor interface. So if you're a web component form controls you need some kind of intermediary layer to play well with angular forms.

Problems tend to surface with testing infrastructure as well, especially in older codebases running Jest or other jsdom based testing frameworks that don't recognize the web component apis well (shadowDOM, elementInternals, ect). Upgrading to vitest with browser mode can solve these problems, or writing lots of mocks.

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.

Web Components seem a nice compilation target for other frameworks, but working with them directly is a hair shirt I'm still not willing to wear.

We're putting out Video.js v10 beta in March, rebuilt from the ground up and merged with Media Chrome. We're being really intentional to build an idiomatic React version in addition to WCs, not just wrapped web components, but I'm interested to see if the web component version is actually the more popular flavor.

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

We can now render whatever content we want confidently, inside of other apps. Less than an iframe, but enough isolation (or not if you want) with all of the important benefits of being baked into the current document.

Example: https://kherrick.github.io/block-garden/

Same custom element running inside Angular: https://kherrick.github.io/apps/playground/block-garden

A year ago, I would have groaned hard about Web Components as they require yet another investment to integrate and deal without. Now, just vibe them in after extensive validation.

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.

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 ran into https://github.com/WICG/webcomponents/issues/814

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

If you just want encapsulation you never needed web Components for that.

1: https://lit.dev/

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

Everything here is still true: https://dev.to/richharris/why-i-don-t-use-web-components-2ci...

Or at least, I don't want to use your framework free web components. Because the frameworks handle a bunch of stuff for you, like reactive properties, that you'll surely get wrong if you do it by hand for each and every component.

The biggest problem frameworks solve is data binding and reactivity. Until there's a native solution to that, WCs will need some framework for anything non trivial.

And going with a non-framework approach has the following risk: Of course I might build individual, customized skyscrapers but as soon as I'd like to connect them, I'm in the business of building an ad-hoc framework.

Give me 10mb and an API like service workers have to manage a library of custom elements that can be used on my site as soon as the page loads.

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

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 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

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];)