Hacker News

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

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.

I've been building for the web since the 90s and it's always felt a little off how slow the uptake on web components has been. Glenn Maddern's X-GIF talk at JSConf EU '13 opened my mind to expanding the browser beyond its locked-in set of HTML tags. I got super excited and started building with web components v1, but React was so dominant they never really got traction. And to be fair they had real problems too (not easy to create without something like Lit, complex async lifecycles, reactive frameworks really don't like other things having state). Around 2020, after almost a decade building Video.js and being tired of trying to make the player work with every single framework, I started building Media Chrome (https://www.media-chrome.org/) as web components. It's been out almost six years and if you look at the npm stats there's been a real spike in just the last year, even the last few months to over 1M weekly downloads. I don't know what's driving that but it's cool to see.

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.

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 a great way to implement things that the browser should have already implemented, like accordions, combo boxes, and date pickers that don’t suck. It’s been a pleasure to use them in a mostly static, content-heavy Astro site.

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.

Even at only v1, along with the "don't break the web" mentality, Web Components are an extremely important stepping stone. We should cheer the implementers of these proposal on and help!

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

So, I'm going the direction of Web Components because Claude can pump them out fast. They are easy to test and well isolated, and claude can compose them very well which further helps to keep context well focused within a hierarchy.

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.

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

The thing I enjoy the most about writing UIs with Vue 3 is that I'm not forced into JavaScript's insane OOP mechanics, and can use plain old functions without concerning myself with incantations like `this.foo.bind(this)`. Web Components embrace JS's OO system whole-hog, and well, they can keep it. I'm also not too big on having to deal with things like "shadow DOM", which to me seems like the kind of implementation detail frameworks are supposed to abstract away in the first place.

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.

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.

In my experience as a web component library builder, writing and maintaining web components is the easy part.

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.

Web Components are bad. Lit in particular is one giant memory leak. No tooling exists for making use of server-rendered Shadow DOM, which means users pay CPU cycles for client-side rendering.

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

Renaissance? Yup, checks out. I've been waiting for Web Components to become a thing for a loooong time. The (European) Renaissance took two-three centuries - from Petrarch and Giotto to Leonardo, Michelangelo, and Raphael. I suppose we have to wait for another hundred years or so, and in couple of generations we could finally say: "web components is a thing". My grandchildren will laugh at my React-based code, that will happen someday. Right now, there's shit to ship.

Wow, XSS just waiting to happen.

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

I don't understand takes like this. Web Components don't even compete with modern frameworks and solve totally different problems. Reactivity and data binding are not features of web Components that I have seen.

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

Web components are a good tool for building literal components (buttons, sliders, etc). From experience, I can say they're not a great tool for building the higher level things you build in a typical web app. The output they produce ends up being such a painful mess of shadow dom everything that it makes using other tools with the website painful

You really really do want to use a framework (such as Lit) if you're writing web components.

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.

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.

I think lit[1] is a good compromise between vanilla and framework bloat. It IS a dependency but a very lightweight and useful one. And it can act as a layer in between whenever requirind a specific framework.

1: https://lit.dev/

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've been using custom elements and web components in production since 2016. The reality is that these don't even solve half the problem.

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.

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 love web components. The one thing I really wish browsers supported though was a per-site custom element registry that persisted across page loads.

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.

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.

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)

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.

When presented with a choice, I'd prefer to pick something where I know that the sky is the limit in terms of features.

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.

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.

While the topic of this article is interesting for me, the fact that it was output by an LLM by itself makes it less trustworthy than if a human wrote it, taking into account the disadvantages of both.

the first time I wrote a custom HTML element was the last time I ever reached for a React framework

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

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"

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.

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

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?