Using Web Components in 2022?

Question

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.

KenPainter · Accepted Answer

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.

tompark · Answer

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.

tmm84 · Answer

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.

thedevindevops · Answer

Neither of them work with javascript disabled, do they?

dannye · Answer

Lit is a Tool, not the Technology