How we use web components

I've used it (as side project) for a fairly interactive application (https://audiotrails.io). I'm also in the middle of rewriting it with htmx, which offers more features & a larger mindshare/future outside of the Rails community. In addition, I used Stimulus (with turbo) and Alpine (with htmx) where more intricate JS actions where needed, for example the audio player, with Tailwind for the CSS, and Django backend.

I can offer some comparisons with Vue which I have more experience with. I'd describe myself primarily as a backend developer with some frontend experience.

In both cases I found it much more productive than building the traditional SPA. Building an SPA feels very much like building two applications: your backend API and the frontend app. This might make sense where you have a team of specialists, or multiple frontends (i.e. IOS+Android+web). If you're a sole developer it's important to acquire "superpowers" that give you a productivity boost to compensate for your limited time and expertise, and Hotwire and htmx feel very much like superpowers. Combined with a compatible JS library like Stimulus or Alpine I didn't feel like I hit too many walls compared to Vue. This made it easier to focus on the UI and backend logic and kept maintenance to a minimum.

That said, the more interactive parts did require some lateral thinking where Vue would have likely been easier in terms of the mental model, for example keeping an audio player open during page navigations and maintaining state without full page refreshes (i.e. to prevent the player restarting). Another thing I missed where the sheer ease of building and re-using components in Vue, and Django templates and tags feel quite clunky in comparison (some other frameworks like Laravel have perhaps a better template component model). Overall though it was so much easier to build a traditional web application compared to the complexity of an SPA.

Comparing Hotwire to htmx: Hotwire required more server work when doing atomic changes (HTML fragments returned from AJAX requests). There's an existing Rails gem which does most of this, I had to write my own Django package. There's an expectation that it should be used with websockets, but really that's optional. In most cases though Turbo Drive works pretty much like Turbolinks: once you install it, it will provide SPA-like page transitions for free. Htmx feels a bit less polished, and the learning curve is a bit steeper, but has much more in the way of features and extensions and doesn't require as much rework in the backend. There's an hx-boost feature that works similar to turbo drive but I found it's easier to use htmx' low-level options to manage different sections of the site as appropriate.

Take a look at CSS shadow parts. It allows you to mark which part of the shadow dom are stylable which you can then access using the ::part() pseudo element.

Another handy thing to know is that exportparts reexports parts from a nested web component, and CSS --custom-properties will cascade down into the shadow dom

https://developer.mozilla.org/en-US/docs/Web/CSS/::part

Interesting! I had not considered that.

I don't suppose you know if there's any performance impact there—e.g. even if it's not downloading it, is there overhead from processing the file once per component?

I didn't know about that and it is certainly interesting, however for my particular use case it wouldn't have worked unfortunately. I was using Tailwind, so rather than targeting specific components from a global style sheet, I was trying to use the utility classes from the global sheet inside a web component.

In some ways, it still isn't great. You can't create font rules in CSS in shadow DOM; they are ignored.

WC + Shadow DOM are great for using 'new' components in, say, a legacy web application that has leaky style rules (e.g., the main app has style selectors like `button`), which would bleed into your new component.