Hacker News Reader

Comment by earthboundkid | Hacker News Reader

No, they just lock you into one framework per component. I don't know why people say obviously false stuff like this about web components besides they just really, really want it to be true. Yeah, if you're willing to have the same framework on the page ten times, you can just chuck them all in separate script tags using the custom element API. But if you care about making a performant page with progressive enhancement, etc. this is a bad strategy.

Even the name "web components" is basically just marketing fluff. When people say "web component", they mean using two particular DOM APIs: customElement and shadow DOM. Those are both pretty niche APIs. There are some cases where they are helpful, but 99% of the time, they don't add much to a project versus good old querySelectorAll and normal CSS.

View on HN

Author here — I'm not sure what you mean by "lock you into one framework per component". The point is that you can encapsulate framework code within web components, not that every component you write should be a web component.

Let's say you're writing a Vue app and you really want to use a library that's only available as a React component. You can wrap that library in a web component and use it in your Vue app just like you would any other HTML element. The rest of your app can continue being Vue, using normal Vue components.

except you can't use it as a normal component, you can't adjust its CSS normally, you have to `&::part()` your way around and hope for the best. Accessing through refs is a complete blackbox. I work with web components daily and it is a hindrance to my daily work, it is very common for people at my org to just re-write a component instead of using its web component version.

I also wonder about this. The webcomponent make the style completely immutable unless you add part selector specifically… how on the earth this is even useful? Imagine using an ui library that you can't change the style at all. That sounds like a total joke to me. That isn't even a sane default that is useful to most web folks that make page base on layout that designers gave.

I find it very useful for embedding interactive demos on my blog that are mostly independent of the styles for the rest of the site (for example, the article here). But for what it’s worth, there is discussion of an “open-stylable” shadow DOM mode that addresses those concerns: https://github.com/WICG/webcomponents/issues/909

Shadow DOM was a mistake. It's a 0.1 version that was unfortunately pushed out as a completed standard. Basic stuff is missing like your link. The entire thing should be deprecated and we should start from scratch.

If you want to embed something that doesn't use your page's styles, we already have iframes. Shadow DOM is just a half-assed recreation of that.

How would you build, say, a component library like Shoelace [1] using iframes?

[1] https://shoelace.style/

You could use srcdoc="..." to simulate a component, except that iframes don't have automatic height adjustment, which is the thing they should actually fix.

In any event, shadow DOM is just a worse version of scope selectors. There's not really a good use for it now that you can just do a style reset on a donut selector inside an import layer. It can all be done declaratively with CSS instead of using an imperative JS API that has a ton of gotchas.

There are a lot of things you can do with shadow DOM that you can’t with iframes or scope/donut selectors:

- transclude other elements (technically you can with iframes, but hopefully it’s clear why making something like this breadcrumb component would be extremely awkward [1])

- control and react to the display of child elements via <slot>s

- call methods on custom element objects

etc etc. It’s fine if it doesn’t solve any problems you personally have, but that doesn’t mean it’s not useful.

[1] https://shoelace.style/components/breadcrumb

Transclusion can totally be done with CSS now. That’s a donut selector.

The other things are just plain old JavaScript and have nothing to do with Shadow DOM. Yes, they can be done with customElement, but they can also just be done without it.

I think I’m going to bow out because it’s clear this discussion isn’t going anywhere, but you should look up what transclusion means because it makes no sense to say that you can do it in CSS.

Transclusion means that .a in this can escape the Shadow DOM: <my-element><div class="a">Transcluded content</div></my-element>

To do the same thing in CSS you would do <div class="myelement"><div class="slot"><div class="a">Transcluded content</div></div></div> @scope (.myelement) to (.slot) { /* rules that apply to .myelement but not .a */ }).

You wouldn't, but shadowroot is bad design for that. What's wrong with bootstrap or any other number of of existing frameworks? I don't want to include a button and have it stick out like a sore thumb because it ignores my page's styles. ::part() is a stupid hack to make up for a bad approach.

If you want to include something "as-is" (i.e. the demos you mention), use iframes. If you want to include a component like a button, use any of the existing frameworks that work just fine. Trying to build a button that pretends to be a browser-native component but actually isn't is a terrible idea.

That sounds awful to be honest. A recipe for total loss of standardization within an org.

Any sufficiently large org already has all the technologies.

The biggest problem of web component is that it don't support most state injection(for things that rely on contexts, for example: tabs) and template instantiation(render function of react or scoped slot in vue for example), which literally every current popular web framework does. You may pass string or number as string to it. But anything more complicate that can't be easily serialized? Good luck.

You may add another layer of abstraction on the top of it. But that only make you another framework (like polymer) instead of actually using web components.

In other word. Web component is useful to encapsulate an 'app' (for example: a interactive map viewer that accept an address) inside another app. But is mostly useless to encapsulate anything other than a simple ui/input component. There is basically 0 functionality to inter-blend between parent and child components of different frameworks.

Reply on news.ycombinator.com