Hacker News Reader

Comment by Rodeoclash | Hacker News Reader

I wouldn't mind a sanity check on using Web Components in this context:

We have a bunch of sites written in different frameworks (React, Rails + Hotwire, Phoenix + Liveview) that we'd like to have a shared set visual components between them. Think things like:

- Buttons - Text spacing - Layout cards - Headers

Pretty low level stuff, the most dynamic behaviour might be something like showing / hiding content in an FAQ.

Web Components seems like a reasonable fit to encapsulate the design elements and reuse them across all these different frameworks (probably coupled with Tailwind CSS on each site to enforce consistent colours + spacing).

View on HN

Web components are really only useful for stuff that's dynamic, like a sortable table that fetches data from an AJAX request. They require javascript and have no fallback or graceful degradation in functionality at all, which means using web components for all your bog standard buttons, text content, headers, etc. could be a very bad idea (not to mention it would trash the SEO and potentially accessibility of your site).

IMHO you probably want to look at design tokens or other ways to centralize your visual styles--it's really more of a workflow problem and not just something to throw more javascript at with web components.

> we'd like to have a shared set visual components between them

I think what gp wants is css!

Well, ideally css which belongs to the component that is using it. CSS modules and other encapsulation techniques have been pretty beneficial. I'd like to keep that going vs. trying to manage the "cascading" part of stylesheets over multiple sites.

> They require javascript and have no fallback or graceful degradation in functionality at all

This is false. Use <template> and <slot>. First-class progressive enhancement.

Have you ever seen an example of this in the wild?

Sometimes, but not enough. Everyone tries to write web components like it's "Open Standards React Lite". And the results are as poor as expected.

Web components are superficially similar to React/Angular/Vue, but very different in practice. Different strengths. Different use cases. Different opportunities. Like the post says, the web components community has been terrible at articulating and marketing these differences.

Ehh slots have issues too, particularly that if you use them they punch through and totally ignore your shadow DOM to inherit the main body styles. Sometimes you want this behavior and sometimes you don't, but either way you only get it and have no control over the elements passed in the slots. They defeat the whole point or just greatly complicate the idea of encapsulating your element's visuals in one component.

I'm truly skeptical there is much to be gleaned accessibility-wise from templates if JS is disabled. There's no way to know how and where the template was meant to be instantiated in the DOM and accessibility tree without JS.

Web components are treated like HTML elements. You can nest and combine them with semantic elements and attach attributes to them.

Say you have a component that does something with titles (h1 etc.), then you would wrap the semantic element with a web component.

You do the same with buttons, text or input fields etc.

This way you 100% retain the semantic structure (before loading JS). And it’s possible to progressively enhance the DOM if that is a goal.

Reply on news.ycombinator.com