hckrnws
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...
I've written quite a few web components that were more or less standalone. I've looked at lit quite a bit but never fully understood the "why". Could someone share their own personal experience with why they needed lit? What does it offer that can't be done with standard spec web components?
For me, a big draw of web components is that there's no `npm install` needed. I prefer to ship my components as plain JS files that can either be hot linked from a CDN or downloaded and served locally. Call me paranoid but I just don't fully trust node modules to be clean of bloat and spyware and I just don't want to have to regularly deal with updating them. I'd prefer to download a web component's static JS file a single time, read through it, and forget it. Maybe down the line I might revisit the source for the component as part of standard maintenance.
For example, I made a simple like button component[1]. Later, my friend made a cool component for showing a burst of emoji confetti[2]. I decided to optionally pull it in if an attribute was set on the like component. I downloaded his source and hosted from my own domain. However, there was actually a bug in his code that caused the confetti to "rain" if you spammed the like button a few times quickly. He fixed that, but I actually kind of liked it so I just didn't update the source for the confetti component.
[1]: https://catskull.net/likes [2]: https://github.com/samwarnick/confetti-drop
> I've looked at lit quite a bit but never fully understood the "why".
Because people don't want to write hundreds of lines of useless boilerplate by hand.
Web Components API is verbose enough that you want to handle it with at least some abstraction. And at one point it was explicitly marketed as aimed at library/framework developers.
The cycle isn't short like people continue to say each year. I use react since 2014 and it hasn't changed much in 6-7 years.
I just built a script tag based reusable library for our company with react as the only dependency and thanks to stuff like shadow Dom and dialogs I get a much higher quality dev experience than plain js.
Best practises have changed dramatically in React since 2014 though. It’s easy to say “oh you don’t have to use hooks, you can keep using class components” but that’s not really true when the entire ecosystem is pivoting.
My bigger problem with React is that it ends up being used as a form of vendor lock in. Once your entire page is in the React VDOM it’s very, very difficult to pivot to a different framework piece by piece. That’s a core strength of web components.
Class components still work, and you can still use function components with hooks inside class components and vice versa.
In the parent comment's case of not having other dependencies, whatever the React ecosystem does isn't relevant if you aren't using any React libraries, which aren't really necessary anyways, especially nowadays when the LLM can reimplement what you need for you.
Nothing has changed about react-dom that prevents you from using React piece by piece—its docs still recommend attaching to a #root node even for single page apps.
Including web components in a React app is very seamless, and embedding non-React-controlled elements inside React is not uncommon (e.g. canvas, Monaco, maps), though for common use cases there's usually convenience libraries for React that wrap around these.
I think React originally started with the opposite intent: a library where you can mount a component onto selected elements of the web page. The lock in only happened when React was used to develop SPAs, which effectively meant that React takes over the document root. With that came state management, and frameworks that managed the complexity of state were not far behind.
Indeed. I've gradually adapted a server rendered jquery and HTML site to react by making react render a component here and there in react and gradually convert the site. Works great.
React state management has changed a lot.
React DOM/views have not significantly changed in 12 years.
Our 10 year React projects that used mobx have not changed very much.
Savage take: I found React when it came out and I thought “wow you made this gorgeous DOM library and then you bolted on this messy ugly wart for state.” Then hooks came out and I’m like… this is a good electrician pretending they can also do plumbing.
it's also impossible to look at the DOM and figure out what the hell is going on with React.
React has excellent dev tools of its own that cover this.
I have those dev tools installed. I wouldn't call them "excellent".
Agreed I might have gone too far with "excellent". :) I think they do a good job though at operating at the level of abstraction React lives at, which generally requires less detail to live in the DOM (e.g. ids/classes used only for JS bindings compared to classic jQuery soup).
I have react projects from less than 6-7 years ago that are bit-rotted because of changes to react. I have wanted to add features but can't because I don't have the time to fix everything that rotted.
To be clear, it's not 100% react. It's the entire ecosystem around it. Want to take wigdet-x v3 for bug fixes. It requires newer react, which may or may not be compatible with widget-z I'm using. Newer react requires newer tools which aren't compatible with the configuration that was created by create-react-app from 2 versions ago. etc...
> I have react projects from less than 6-7 years ago that are bit-rotted because of changes to react. I have wanted to add features but can't because I don't have the time to fix everything that rotted.
That's what AI is for. It makes previously unfeasible projects feasible again
I thought so too but it failed for me. Maybe I'll try again
What model did you use? Curious if something like Opus 4.6 does a better job.
Exactly what are you using in React land that has lasted for 6-7 years. No components to hooks transition? No styling library changes? No state management changes? No meta framework changes? The React ecosystem is the least stable thing I have ever worked with.
Hooks were introduced in 2019. so, seven years ago.
Even only looking at React provided hooks, they added a lot over years and best practices around things like useEffect have changed a lot.
If you have a complex app from 2019 that you haven't updated, it is virtually guaranteed that it has memory leaks and bugs.
I don't really agree that "best practices around useEffect have changed a lot". It's more that that particular hook was used a lot when it didn't need to be so the team finally wrote some guidelines.
For state management, you might be interested in looking at Lit State. It's a very lightweight state management lib written specially for Lit, with the same mindset. With it you won't have to pass props everywhere all the time.
Hey, cool to see you here on HN. I was recently looking through your codebase to see how you handle automations. It looks like you are relying on asyncio? I was wondering how you came to this decision and if you ever considered alternatives like a APScheduler or any other job library?
> Not being tied to the JavaScript industry upgrade cycle (which is short!),
> We currently use Lit for the framework on top
These two are contradictory statements.
1. lit is both newer than React, and started as a fully backwards incompatible alternative to Polymer
2. Despite being acrively promoted as "not a framework just a lib" it's rapidly sucking in all the features from "fast moving js": from custom proprietary syntax incompatible with anything to contexts, a compiler, "rules of hooks" (aka custom per-dieective rules) etc.
> We're currently on material components and migrating some to Shoelace.
Again, this is exactly the "fast js churn" you're talking about.
Lit is fully compatible with Polymer (and any other web components).
The output of lit is.
Not lit.
Stop pretending this isn't the case
I can't even tell what you're arguing.
Lit helps you write web components.
Those web components are interoperable with other web components made with Polymer, Stencil, FAST, etc...
Do you understand the difference between consuming and authoring?
I know you do, you just chose to pretend there is none.
I still don't know what you're arguing.
Is it that Lit gives you a different way of authoring web components than the raw APIs? Yes, that's entirely the point. It's a library that gives you better ergonomics.
Is it that from the outside the components aren't "Lit", but consumed as standard web components? Again, yes, that's entirely the point.
> Is it that Lit gives you a different way of authoring web components than the raw APIs?
than the raw APIs, than Polymer, than Stencil, than...
> Is it that from the outside the components aren't "Lit", but consumed as standard web components? Again, yes, that's entirely the point.
No. That is literally not the point. Which is extremely obvious from what I wrote in my original comment: "lit is both newer than React, and started as a fully backwards incompatible alternative to Polymer"
Again, at this point I literally couldn't care less for your obstinate willful avoidance of authoring, and of your pretending that only the output matters. (And other lies like "lit is native/just html" etc.)
> than the raw APIs, than Polymer, than Stencil, than...
Yes, and? Those are all different opinions and options on how to author web components.
> No. That is literally not the point. Which is extremely obvious from what I wrote in my original comment: "lit is both newer than React, and started as a fully backwards incompatible alternative to Polymer"
It's extremely hard to tell what your point is. Lit's newer than React? Yes. Lit started as an alternative to Polymer? Yes. Lit is "fully backwards incompatible [with] Polymer"? No, Lit and Polymer work just fine together because they both make web components. We have customers do this all the time.
I don't avoid authoring, authoring is the main point of these libraries. And what you build is just web components. That's like... the whole idea.
Can you even communicate what this complaint actually is?
> Lit started as an alternative to Polymer? Yes. Lit is "fully backwards incompatible [with] Polymer"? No, Lit and Polymer work just fine together because they both make web components.
Keyword: make.
Again: you keep pretending that authoring web components is an insignoficant part of what people do.
At this point I am fully disinterested in your pretence.
> I don't avoid authoring, authoring is the main point of these libraries.
Yes yes. When authoring web components Polymer is fully compatible with lit.
(Funny when even lit's own channgelogs talk about backward incompatible breaking changes between versions, but sure, sure, Polymer you can just drop into the authoring flow, and everything will work lol).
But as I said, I am completely disinterested in web component salesmen at this point.
Adieu.
> Home Assistant [1] has been written using web components and it has been great.
That could explain why the percentage slider is not showing a current value tooltip when sliding it :P
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.
> 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.
You could say the same about the DOM itself. That’s why frameworks were created in the first place. The Custom Element API is complex. The DOM is complex. It’s just that we’re used to the latter and not the former.
[dead]
I love web components, but the fact that there's plenty of shadow-dom piercing properties defeats their purpose of "author them once, reuse them in different applications".
One very common pitfall I encounter is the html's own base font size, since it impacts all the calculations in your webcomponents. Use a webcomponent with a font size of 12/14/16 and you get completely different behavior.
If they were truly isolated they would really scale, but they don't.
Not to nag, but this seems like a design error? WC font settings should be inherited and relative, rather than any specific pixel size. Designs should be robust enough to support overflowing text, should the user increase scale/zoom/etc.
Admittedly, I might not be understanding your problem well enough, so sorry in advance if I've mischaracterized the issue.
Shouldn't you be using relative units like rem anyways?
Yes, which makes it very difficult to make stuff work okay cross application at changing of base font and user's zoom.
Yes. But does my target market even know how to change those things?
Web components are just a way for developers to build their own HTML elements. They're only a "framework" in as much as the browser is already a framework that wires together the built-in HTML elements.
I don't see any reason to lock away the ability to make nodes that participate in the DOM tree to built-in components only. Every other GUI framework in the world allows developers to make their own nodes, why shouldn't the web?
> too many mechanics and assumptions backed in, rendering them unusable for anything slightly complex.
Do you have any concrete examples there? What "mechanics" are you referring to. Given that very complex apps like Photoshop, Reddit, The Internet Archive, YouTube, The Microsoft App Store, Home Assistant, etc., are built with web components, that would make the claim that they're unusable seem silly.
With your other specific complaints about the community, I think I can guess you are. That person come into our discord server, was so mean and rude to everyone that they had to be told by multiple people to chill out. Had one very specific proposal that when multiple people thought it was a bad idea, threw a fit and said we never listen. You can't just come into a place and behave badly and then blame the community for rejecting you.
> Do you have any concrete examples there? What "mechanics" are you referring to
Try the 2022 Web Components Group Report. Including things like "most these issues come from Shadow DOM".
> Given that very complex apps like Photoshop, Reddit, The Internet Archive, YouTube, The Microsoft App Store, Home Assistant, etc., are built with web components, that would make the claim that they're unusable seem silly.
Trillion dollar corporations also build sites in Angular, or React, or Blazor, or...
So you're saying that the web components community ignores the issues with web components by... writing a report on the issues with web components?
I still don't know what "mechanics and assumptions" are baked according to the OP.
So you're deflecting from the original point raised.
Anyway, yes. Web Component "community" was fully and willfully ignoring most issues that people (especially framework authors) were talking about for years.
At one point they managed to produce a single report (very suspiciously close to what people like Rich Harris had been talking about since at least three years prior for which he got nothing but vile and bile from main people in the "community"), and then it went nowhere.
> I still don't know what "mechanics and assumptions" are baked according to the OP.
Again: you do, people who wrote the report do, but you all keep pretending that all is sunshine and unicorns in the web component land.
While the report very explicitly calls out a very major behaviour baked in, for example. And calls out a bunch of other issues with behaviours and mechanics. While web components need 20+ specs to barely fix just some of the assumptions and baked in mechanics (that literally nothing else needs, and most of which exist only due to web components themselves).
Anyway, I know you will keep pretending and deflecting, so I stop my participation in this thread.
Adieu.
Ideally, good ideas battle tested in various frameworks, would make it into the browser over time.
For example with signals https://github.com/tc39/proposal-signals
I agree that the original 4 parts of the web component spec ( custom elements, shadow dom, templates, modules ) had varying levels of battle testing and perhaps the most valuable ideas ( custom elements and ES modules ), were those which did have the biggest precedence.
> 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.
This feels a bit deflective from the very real issue of in page framework interoperability - which is different from dev's taking to each other and sharing ideas.
What does battle tested really mean in numbers?
When people say battle tested what they are really doing is looking for bias confirmation. Its no different than when they say software becomes more durable due to community validation.
The only way to be sure is to actually measure things, with numbers, and then compare those numbers to some established baseline. Otherwise its just a guess. The more confident the guess becomes the less probable from the average it becomes. This is how rats out perform humans in weighted accuracy tests in clinical trials.
> What does battle tested really mean in numbers?
Not sure what you mean - are you asking number of users, length of time etc?
All I'm saying with this is that ideas which have actually been implemented, used and evolved, are much less likely to have rough edges than something that's never left a whiteboard or spec document. I wasn't expecting that to be controversial.
This stuff is difficult - if I remember correctly the original web components vision was a completely self-contained package of everything - that didn't survive contact with reality - however the things like custom-elements, templating and ES modules are, in my view at least, very useful - and I'd argue they are also the things that had the most precedents - because they were solving real world problems.
That is an irrational comparison. There is no comparison between components and something imaginary or theoretical. The comparison is between components and not imposing components into the standards, which are both well known conditions.
People don't need components. They want components because that is the convention familiar to them. This is how JavaScript got classes. Everybody knew it is a really bad idea to put that into the standards and that classes blow out complexity, but the noise was loud enough that they made it in for no utility reason.
> People don't need components.
The idea that people don't want some sort of improved modularity, encapsulation, reusability, interop etc I think is wrong.
We can argue about whether components as proposed was the right solution, but are you arguing that templates, custom elements and modules have no utility?
Templating, for example, has been implemented in one form or another countless times - the idea that people don't need that seems odd.
Same goes for a js module system, same goes for hiding markup soup behind a custom element.
That completely misses the point. You are mistaking your preference for some objective, though unmeasured, benefit.
I could understand an argument from ignorance fallacy wherein your preference is superior to every other alternative because any alternative is unknown to you. But instead, you are saying there is only way one of doing things, components/modularity/templates, and this is the best of that one way's variations, which is just a straw man.
You really aren't limited to doing this work the React way, or any framework way. If you want to continue doing it the React way then just continue to use React, which continues to evolve its own flavor.
> The idea that people don't want some sort of improved modularity, encapsulation, reusability, interop etc I think is wrong.
And web components are an extremely shitty half-baked near-solution to any of those.
Still not sure what you are attacking - is it just custom-elements or does that include js modules etc?
We're in the discussion under an article about web components. So, web components. Which I literally explicitly called out in my comment.
You can interoperate between frameworks the same way you interoperate between web components-- with events and attributes.
> agree that the original 4 parts of the web component spec ( custom elements, shadow dom, templates, modules ) had varying levels of battle testing
What battle testing? Literally nothing in Web Components was ever battle-tested before release. You wouldn't need 20+ specs to paper over the holes in the design had they actually veen battle-tested.
We have been using the isolation stuff in Web Components to make React applications that our partners can embed in web pages regardless of what other CSS and JS they use. I don’t know if I’d want to make an application with 100 tiny web components at the level of individual buttons and such that work together but self-contained widgets that pop into a web page look great to me.
We basically tried wrapping an entire registration app into the Shadow DOM just for a hopeful kick but it came with weird accessibility quirks, arrow keys not always working to go through selections, and some overlays acting strangely. We were using Shadcn which is powered by Radix Primitives, however, and a setup they probably weren't expecting or testing their code to be in.
But for smaller things like chat widgets or players I think it's a great solution.
We had overlay problems with a fancy <Select> control, also systems like Emotion can have trouble, or anything that is portalized or computes coordinates for absolute positioning. We were able to fix all the ones that affected us.
Funny we have been using the HTML <dialog> because you can't really pass accessibility reviews if you use the modal dialogs that come with MUI, Reactstrap, etc. Only <dialog> really inerts the whole page but you run into very similar problems getting components to work properly inside them which we were able to solve for all the components we use inside dialogs, but I think it's an absolute shame that this has not been adopted by MUI or anything I can find in npm -- what I hate about accessibility is that I feel like I'm held accountable and my organization is held accountable but not the people who write trash specs, make trash screen readers that crash my computer, vendors of React components, etc.
Agree. web components are not a 1 to 1 replacement for a component based framework. There was a lot of promise but the implementation is lacking.
Wow, this is a weird a comment. Who are "they"? You sound like you think there's some giant conspiracy against JS frameworks. Is the Illuminati behind this? I kid, but a browser feature is kind of what it is. It can take years for features to make it into enough browsers to make them usable. It's quite a bit different than the fluidness of a JS framework.
This discussion comes up all the time and I always have the same response: not everyone needs a full-on framework for what they're doing. They also may need to share that code with other teams using other frameworks or even third parties. The post even mentions that web components may not be a good fit for you.
Its not a conspiracy. It is just group behavior following a trend as loudly as possible.
Web components are a trend? I've been using them for close to 10 years and they're still not anywhere close to mainstream. Loudly as possible? They've quietly just kind of been there for years.
I think we have a generation of developers that only know React and they're so engrained with it they simply cannot imagine a world without it. If you really can't find a use case for web components then you're living in a bubble.
We have been through all this before with jQuery. The generation of JavaScript developers at the beginning on React only knew jQuery and they really wanted to shoehorn all the jQuery nonsense into the standards. From their perspective it makes complete sense because that is the only one way to do things. They got querySelectors into the DOM.
Now we are seeing the exact same thing again. People only know React, so they want the standards to look like the only one thing they know. That doesn't make it a good idea. Every time this comes up we exchange simplicity and performance for easiness and temporary emotional comfort. Its only a temporary win until the next generational trend comes along.
> If you really can't find a use case for web components then you're living in a bubble.
There's a very tiny use-case for web components. And even there it's riddled with a huge amount of potential (and actual) footguns that "in the bubble" devs have been talking about for a decade at this point, and some which were finally acknowledged: https://w3c.github.io/webcomponents-cg/2022.html (no updates since)
> There's a very tiny use-case for web components.
That's weird, we've been using them at my company for a number of years and there's plenty of other examples of them being adopted elsewhere too. This continues to read as, "it's not React, so it's bad."
There are companies that still use jQuery, or Angular, or Ember, or vanilla JS, or Blazor, or...
Just because tech exists and is usable doesn't mean it doesn't have a list of issues and footguns a mile long, some of which are explicitly recognized by the Web Components Working Group. And which still need 20+ various specs to paper over.
> Who are "they"? You sound like you think there's some giant conspiracy against JS frameworks.
Yes. There is. The main developers and proselityzers were completely insanely biased against web frameworks (especially React).
It wasn't even a conspiracy. All you had to do was to follow Alex Russel (the person who introduced the idea of web components in the first place) and see his interactions with framework authors and his views towards web frameworks.
The new people in the space driving the specs are hardly any better. E.g. their reactions to Ryan Carniato's rather mild criticism of Web Components is just filled with vile, bile, and hate.
They literally refuse to even admit they have a problem, or want to look at any other solutions than the ones they cook up.
> but a browser feature is kind of what it is. It can take years for features to make it into enough browsers to make them usable.
Strange, browsers push dozens of specs for web components without ever taking any time to see if the yet another half-baked "solution" is actually workable.
Some links to examples of the sort of behaviour you're describing would be really helpful here (I say this as someone who is sympathetic - I work with on a web component/Lit codebase in my 9-5 and I'm not a fan, compared to the React workflow I had in a past life).
Unfortunately, as most of them left Twitter they also temoved all their accounts, so you can only see responses from framework authors like Rich Harris.
But here's a very on-brand toot from Alex Russel: https://toot.cafe/@slightlyoff/113222280712758802
This is the article he's reacting to: https://dev.to/ryansolid/web-components-are-not-the-future-4...
---
Or here's Lou Verou (a TAG member) calling it hate (this is the mildest reaction, btw): https://x.com/LeaVerou/status/1840134654852247765 and uncritically reposting a bullshit article calling it excellent https://x.com/LeaVerou/status/1839736908370587947 (see reaction by Vue author: https://x.com/youyuxi/status/1839833110164504691 and https://x.com/youyuxi/status/1839834941884121363)
Note that Lea Verou also says that people decided to fix some things around web components after her post in 2020: https://lea.verou.me/blog/2024/wcs-vs-frameworks/
Here's Rich Harris (author of Svelte) in 2019: https://x.com/Rich_Harris/status/1198332398561353728
Here's the 2022 Web Components Group report: https://w3c.github.io/webcomponents-cg/2022.html. Notice similarities?
Literally everything web framework authors have been saying for ever has been completely ignored in favor if the in-group/tribe.
Literally nothing has changed. Nothing at all.
Yes Microsoft DHTML and behaviors were this and represented tremendous lock-in. Plus, they were terrible. Those who don’t know their history are truly doomed to repeat it.
> Web Components have too many mechanics and assumptions backed in, rendering them unusable for anything slightly complex.
Does not line up with my experience (the past 8 years or so of working with native web components, Polymr and the Lit library) at all. You can build staggeringly complex views using nothing but web components, I’ve done it, I am doing it, and inshallah I will keep doing it.
What in particular do you believe web components are unusable for? What do you count as crossing the line into ‘slight complexity?’
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...
> For whatever reason, most webcomponent tutorials start with rendering things in their shadow DOM, not the main DOM
Yeah this a thing that turns lots of people off from using and it's usually presented as "of course you want this". And it's a real practical limiter to using for normal apps (I get embedded standalone widgets)
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.
Accordions: just use `<details name="accordion-name">` and style it however you like. No need for JS or Web Components any more for an accordion.
Combo Boxes and Date Pickers: CSS Form Control Styling Level 1 [1] will be a massive game changer. `appearance: base` will make it easier to style every part of a browser's form input with just CSS as they start with fewer opinions on how it should be styled (less trying to be platform-specific, more web platform generic) and have more CSS selectors for their component parts. Yet they will still have all the accessibility of native form controls. Really hoping that draft moves forward this year.
I didn’t know about the `name` attribute on `<details>`, thanks for pointing that out!
Stylable form controls are definitely a step in the right direction. It really should not be taking this long though. In the meantime, developers have been building broken, half-assed, inaccessible inputs just to satisfy aesthetic requirements.
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.
Yes. You can tell the author either doesn't have experience using web components in a non trivial page, or they are intentionally hiding the complexity. Realistically, you don't want to make pure web components. You want to use a framework to build it for you.
Put it another way, you can make a page out of web components without using a framework, but you are not going to convert a React page with that approach.
you have `observedAttributes` and a callback to react whenever they change. That is basically it.
You can use lit-html to get declarative reactivity, but then it's just basically react again.
On the inside, but not on the outside. Web Components standardize the interface for components to interact like MCP standardized the protocol but the server itself can be in and language. You can't just mix Solid, React and Vue components together but you can use any web component in a Lit app.
Do you still have to pass every args as json/strings or has there been an improvement on that front?
This has never been the case. Custom elements are DOM Elements and so are just JavaScript objects. Just like you can do aEl.disabled = true, you can set any prop to any type of value.
I think they mean in the markup via <some-tag data={anObject}> ala React, svelte, etc.
It's still exactly like that.
> 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.
This is the truth that a lot of web component advocates gloss over on purpose. They know this, just like they know that there's no decent templating solution either as tagged template literals still need escaping. Then there is efficient DOM updates, etc. (aside, I got Claude to write a web component recently, and it's code had every single keystroke assigning the same class to the element)
There are many features like this, and when you finally get them to admit it, they just say "write your own"!. Well guess what, frameworks already provide all of this.
The really funny part is that Stencil, one of the popular tools for writing web components actually does provide all of the above! Their web components have exactly the same type of features you'd expect in any other framework *because it IS a framework*.
Which again highlights how stupid the discourse is here. It's not "independence" of frameworks, your components will still depend on a framework of some kind, be that Stencil or Lit or whichever thing YouTube uses now or your own supporting code to get back even half the features you get elsewhere.
It all starts to make sense when you realise that the Chrome developers hated frameworks because they didn't understand them, pushed for web components, not realising frameworks dealt with all of the above.
https://youtu.be/UrS61kn4gKI?t=1921 32:00 (but the whole video is valuable and I wish everyone on both sides of this debate would watch the whole thing).
I think the only thing I like about web components is they scope "this" to the element it owns.
Not that votes matter on HN, but I do find it typical of the type of discourse around Web Components I dislike. My comment had +3, now it has 0. It seems no one is able to admit WC's have big problems.
> 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.
Redux really should have just been events up and new data down.
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.
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.
It's not actually in some capsule separate from the page, though. CSS variables leak in to it from the "light"/regular DOM. You can query elements in it from the host with `shadowRoot.querySelector()`.
The elements also inherit styles from parents: https://open-wc.org/guides/knowledge/styling/styles-piercing...
You can do a closed root but last I checked that had profound accessibility issues.
(As an aside this is why the linked article is incorrect in saying this: "global styles don’t leak in (unless you explicitly allow them).")
> CSS variables leak in to it from the "light"/regular DOM.
> You can query elements in it from the host with `shadowRoot.querySelector()`.
> The elements also inherit styles from parents
Why do people keep talking about those things as if they were problems?
They ain't! Long live the cascade!
But when the desired outcome is "complete separation from the surrounding page," those are pretty serious problems!
I'm certainly feeling like Shadow DOM is the new iframe and mostly useful for ad networks and "embeds" which are not things I'm generally building with Web Components. It's interesting how many developers seem enamored with Shadow DOM, but for me the sweet spot is keeping all of a Web Component in the "Light" DOM, let CSS do its cascading job, and let my Web Component adapt to the page hosting it rather than be a lonely island of its own style.
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.
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.
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
Wow, XSS just waiting to happen.
<h3>${this.getAttribute('title')}</h3>It looks similar to Lit code, but it's not Lit, so yes, it is XSS waiting to happen all right. If it were Lit it would be escaped. It would start with html` which evaluates to a TemplateResult and the render() function only accepts a TemplateResult.
How? If the attribute is not trusted doesn’t that mean the dom is already compromised?
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
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.
Screenshots look great, anyway!
I liked your choice of tab-picker.
Thanks
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.
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.
I started experimenting with custom HTML elements for my dashboard project THINK (live at https://think.iotdata.systems) and I’ve been really surprised by how much functionality you can get with just vanilla web components. The source is on my GitHub, and I’ve been documenting my other projects and work at https://marchildmann.com if anyone’s curious what else I’m building.
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.
This so much, automatic "data struture state -> visual state" without manual synchronization code to update the visual state is the main reason why frameworks are useful, not for components.
BUT, these frameworks are most useful for actual "applications". So much of web development is "merely" focused on making beautiful "pages", and a framework can very well be overkill in those scenarios.
People "going back to basics" really need to learn to evaluate when what you are doing (or how much) falls into each camp.
I have heaps of experience with Stencil and it works great until a certain size indeed. It is a great way to ship web components quickly.
Coding agents will allow us to write plain JS way more quickly but it still takes a bit more time by humans to read compared to reading something that was written with in a framework.
Until the day that I don't have to do reviews of my AI generated code, or some sort of pseudocode abstraction layer becomes available, I think there is still a place for frameworks and libraries to create web components like Stencil.
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 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.
Why would you want your face to submit a form? How could it even be selected by default? Is this an April Fools joke?
Say you want to have a custom button element. You cant give it a `type=submit` whilst you can set that on <input> and <button>
Also if you have a face that wraps a button of type submit. The submit doesn't propagate due to shadow dom
Does "face" have some sort of special meaning in this context? I thought it might be related an open web implementation of Face ID.
From the title of the issue: “Form-associated custom elements”. They are talking about the mechanism by which a custom element can have its value included when you submit a form. Here’s the spec.:
https://html.spec.whatwg.org/multipage/custom-elements.html#...
https://html.spec.whatwg.org/multipage/form-control-infrastr...
https://html.spec.whatwg.org/multipage/form-control-infrastr...
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.
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.
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)
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.
> My grandchildren will laugh at my React-based code, that will happen someday.
I assure you that is happening today, not by your grandchildren, but it's happening.
hon, this has been "happening" at the time when I grew out of my jquery pants, and still was happening when I was going to my backbone.js induced ptsd therapy sessions; Angular has shipped 20 major versions and React made six rewrites, Next.js switched to rust-based compiler and added the app router, making 15 major revisions - and "web components" still yet "happening". It feels when I finally have grandchildren, it is still be only "happening"... Where's the darn promise? Where the heck is the fame and riches? I've been hearing about this shit for almost two decades now. And have not witnessed it. I hope, it is truly around the corner, but I just fail to see it coming.
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.
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...
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'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.
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.
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.
Static bundle + caching can be chosen by the site/app author.
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.
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"
Because people are discussing different things.
We need to talk more about pages vs applications, web compnents are an excellent choice for making pages more maintainable, but without support for somehow automating translion of internal state (often data in a machine suitable format produced by an API) to visual state (for human consumption where said data might be scattered or otherwise recomputed) then you do run into the "maintainability" issues as soon as the visual state needs to be updated by user updates to the more machine near data model.
I see it a lot with people who ask for help about learning python.
According to the people "helping" them, before writing any line of code you should learn about ruff, uv, pip, venv, black, isort and so on… I guess most people aren't good at imagining other situations than their present one.
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.
the first time I wrote a custom HTML element was the last time I ever reached for a React framework
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 alreadyI 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];)
> in which case you're limited to what that framework provides (and it won't be as robust as any non-wc framework).
Is there something inherently wrong with wc that stops robust frameworks being built on top of it? Have you tried actual framworks built on wc like Lit for example.
No, I'm saying that if you use a non-wc framework, it will be more robust than any wc framework. Not because it's non-wc, but because it's more mature. Lit is mature, but it's not more mature than React, and it definitely has less contribution to it than react.
It's definitely possible to make a comprehensive web component library. Something that could compete with React. But, as far as I know, it doesn't currently exist (and would be a huge task to achieve with... no discernible reason to do it?).
Sorry but you're mixing up terms. A "web component library" would be something not compete with React, because React is a web component framework. The frameworks is whats used to build the component libraries e.g I think material design has one built on top of React.
I'm sorry you're having a hard time understanding. "library" just means "package of code". A framework - of any kind - is a library. Not all libraries are frameworks, but a web component framework would absolutely be a library. And since it is a library of web components, it can be called a "web component library", correctly. A library of react web components is also a web component library, for the same reasons.
I'm not mixing anything up, and I'm not being unclear. I could have used the same terms, but that I didn't does not make me incorrect. You're just splitting hairs. I'm sorry that seemed like it was worth your time.
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?
Personally, I'm still using JSX/TSX to template my Web Components. (I'm not using React, I'm using the non-Virtual DOM approach with Butterfloat [1], but there are other small JSX template language options like Preact and snabbdom out there as well and also other non-Virtual DOM approaches.)
I like the type safety of TSX as well as the syntax highlighting. (As may be obvious with Butterfloat, I also prefer the power of RxJS over signals, but that's a longer conversation.)
I used to write all my webapps in pure lit webcomponents but eventually moved onto react
Can you explain what made you move? I'm about to start a project and was looking at lit to do it.
I was a huge webcomponents evangelist and tbh i wanted to vomit for the first few months of react just based on the fact how antithetical to web standards it is. But I wasn't able to pay the bills with lit work. And now the react ecosystem is much more comprehensive even compared to the polymer/bower days. I'm happy I did webcomponents and can go back to it if I need anything significantly lightweight.
[dead]
Crafted by Rajat
Source Code