[atarian]

I think web components were almost a good "built-in" way of doing React/Vue. Where it lost me was the Shadow DOM. I get that it's supposed to encapsulate the contents of a component and restrict JS/CSS to itself, but it's overkill IMO. It's basically like having a bunch of iframes and makes it much harder to query things, which is very much unlike the rest of the DOM. I don't need guard rails to tell me how to do encapsulation.

[spankalee]

Encapsulation might be overkill for a single developer, but it very much matters for teams and using third-party components.

If you want to drop in a calendar component into your page from npm, it helps if that component's styles don't leak into the page, and if page scripts don't accidentally mess with component internals.

[lcnPylGDnU4H9OF]

> makes it much harder to query things

This seems overstated. It’s different but not really harder.

  document.querySelector('my-lit-element').elementIWant;

  class MyLitElement extends Lit {
    get elementIWant() {
      return this.renderRoot.querySelector(...);
    }
  }

Though, maybe one doesn’t like querying twice. I’m not sure of performance implications there, to be honest, but I’d expect it to be negligible in most cases.

[benno128]

I think framing it this way can lead to real gripes with the interface. Web Components are a great way to build individual components that can be reused across an app, website, or shared as part of a library. They are like helper functions for HTML.

They don't work as well for building apps, sure you can do it, but tools like React/Vue/Svelte are much better at building a whole app experience. Particularly when you consider meta-frameworks and the ecosystem around them.

[no_wizard]

I remember when the language was Web Components would replace frameworks, this was something the people pushing the standards were actively championing at the time and was really one of the main goals of Polymer as well.

They could work well for building apps if the ecosystem was more invested in giving developers what they actually want in a timely manner. (Looking at you template instantiation)

The problem with using them for component libraries is that you break your rendering paradigm of the framework you're using, and that can lead to situations like trying to add event handlers to child components impossible for instance, or having to over-use refs

[troupo]

> I remember when the language was Web Components would replace frameworks, this was something the people pushing the standards were actively championing at the time and was really one of the main goals of Polymer as well.

The language is still there. If anything, it has become more aggressive. Now lit (and stencil) are "standard-based" and "future-proof", and "they are not frameworks", unlike all those non-standards-based framework abominations. (at this point most people roll their eyes).

> They could work well for building apps if the ecosystem was more invested in giving developers what they actually want in a timely manner.

The problem is that none of the people involved in the development of web components ask what developers want. If they ever ask, any answers (including answers from other framework authors and contributors) are ignored, derided, and misconstrued.

There's a reason even people and frameworks who really advocated for web components in the very beginning (Vue, Svelte, Solid) are completely against them now.

[mst]

I believe the VSCode UI components that are designed to be used both internally and by extensions have React wrappers pre-built - see https://github.com/microsoft/vscode-webview-ui-toolkit/blob/... - and the source code to said wrappers might be an interesting read.

[akiro]

Shadow DOM is native web feature. If you don’t like it you can simply not use it. Lit does not force you to use Shadow DOM

[troupo]

> Shadow DOM is native web feature.

Doesn't mean it's a good feature. This is recognised even by people who push them: https://w3c.github.io/webcomponents-cg/2022.html

--- start quote ---

It's worth noting that many of these pain points are directly related to Shadow DOM's encapsulation. While there are many benefits to some types of widely shared components to strong encapsulation, the friction of strong encapsulation has prevented most developers from adopting Shadow DOM, to the point of there being alternate proposals for style scoping that don't use Shadow DOM. We urge browser vendors to recognize these barriers and work to make Shadow DOM more usable by more developers.

--- end quote ---

[acedTrex]

poorly designed web components are so painful because of that

[e111077]

Yeah, this is not an issue for very well-designed WCs like https://shoelace.style or in cases where it's not necessary like https://modelviewer.dev/

[arcanemachiner]

I dabbled with Custom Elements a while back, which IIRC was essentially the same thing as web components, but without the shadow DOM.

[WickyNilliams]

They are two names for the same thing. A Web component _is_ a custom element.

[JohnMunsch]

It's trivial to turn it off in Lit if you don't want to use the Shadow DOM.