Ask HN: Using Web Components in 2022? | Hacker News Reader

Ask HN: Using Web Components in 2022?

9 pointswizzzzzy9 comments

I'm starting a new client project which more or less boils down to a typical brochure website. For the last few years however I've mostly worked on React SPAs. During this time I've really enjoyed the React component model and certain aspects of CSS in JS which I feel I'm going to miss when working on the new project. As a result I've been doing some cursory exploration into web components (specifically Lit) as a means of replicating some of the benefits of React that I've grown accustom to but in a more 'traditional' environment. I'm curious to know however if anyone has experience of Web Components / Lit and if this a valid option in 2022.

View on HN

For all practical purposes the various component systems (react, angular, vuejs, svelte) all have the same abstractions, and they are quite powerful. The front end wars are over, the component abstraction won.

But the browser native solution, "web components" proper, we have found do not have the same capabilities.

This conclusion comes from a team I lead that produces components for internal consumption by our product teams. We generate Angular and React components from our own DSL. When we considered creating web components we found they were limited in the manipulation of child content (in angular terms: projected content). There were numerous other nits that kept coming up that I don't remember.

It seems to me the web component idea itself is a zombie. This may be overstating the case because my perspective is about supporting hundreds of teams, but I sense it has no future.

So your suggestion is to create some sort of DSL then publish your components in Angular, React, and every other library that's requested?

No. Just offering the perspective from a place of having done so myself, that web components are not as capable as the big 4 of react, angular, vuejs and svelte. I'd stick with one of those four for a single project,

YES! I liked React components too but wanted something simpler so on my current project I've been using native browser Web Components/Custom Elements without any framework -- in fact, my project has zero dependencies on the client-side. It does need a few globally installed modules (typescript, webpack/webpack-cli, nodemon).

Requiring that javascript is enabled in the browser isn't a factor because my project relies on WebRTC, which requires javascript anyway. Its main value prop wouldn't exist with javascript disabled, so I'm just going to ignore that criticism.

To work across Chrome/Firefox/Safari, I avoided templates/slots by attaching the `ShadowRoot` and setting its `.innerHTML` to the result of a function that returns the html template literal string (where the function can fill variables in that string). I haven't tested this on Edge, but it works fine natively on the other browsers without any polyfills.

I love using Typescript without any client-side framework, but you might have different constraints than I do. Particularly when it comes to job search -- it seems that almost any front-end webdev position requires React/Angular/etc so you might find that it's a career-limiting move to go straight to plain Web Components as I did. I don't care because my main background is in mobile not web.

Oh BTW, if you do this, there is one nasty Safari bug I ran into which needed a simple workaround. If you have many copies of a particular component on a page, and that web component uses SVG, then the elements within the SVG need to have unique IDs. This is a Safari-only bug that's related to SVG, not the web component API.

For example, say you use a svg button component several times on a page, and there's a filter in the SVG that you use to change the appearance of the button when it's disabled. If the filter tag doesn't have a unique ID, and one of the buttons is disabled while all the other buttons are enabled, then all the buttons will become disabled if you modify just one of them, because they're all referencing the same filter.

It's very easy to make the IDs unique by using a sequence number (as a member of the component class), incrementing the sequence number in the component constructor, and appending that sequence number to the ID every time you call the template function.

After I fixed this problem in my code, I found out that the css-tricks guy had also run into it and he did a whole write-up about it, but he was using React not Web Components: https://css-tricks.com/heres-how-i-solved-a-weird-bug-using-...

My experience with web components has been great if you are doing SPAs or if you can load the web components dynamically/bundle them. However, when doing SSR it was hit and miss because of the need for a window or document object to be present which doesn't exist on the server during SSR. For client-side web development I would say they are good but for hybrid client/server side web development they don't work as I thought they would. The real advantage I see with web components is that regardless of web framework (react, vue, svelte, etc.) you get components/elements that can be plugged in and just work (YMMV) so it makes them framework agnostic in a sense. That's the selling point in my opinion. That and the shadow-dom but that is more of a styling pro/con depending on your point of view.

Neither of them work with javascript disabled, do they?

Lit is a Tool, not the Technology

Yeah you're right, I just meant that Lit was the framework I'd been looking at specifically as a means of building Web Components

Reply on news.ycombinator.com