4 ms·

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 real

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.

jakelazaroff 3y ago
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.
- jdmg94 3y ago
  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.
  - mmis1000 3y ago
    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.
    - jakelazaroff 3y ago
      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 https://github.com/WICG/webcomponents/issues/909
      - EnergyAmy 3y ago
        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.
        jakelazaroff 3y ago
        How would you build, say, a component library like Shoelace [1] using iframes? [1] https://shoelace.style/ https://shoelace.style/
        earthboundkid 3y ago
        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.
        jakelazaroff 3y ago
        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 https://shoelace.style/components/breadcrumb
- Devasta 3y ago
  That sounds awful to be honest. A recipe for total loss of standardization within an org.
  - recursive 3y ago
    Any sufficiently large org already has all the technologies.
- mmis1000 3y ago
  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.

jakelazaroff 3y ago

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.

jdmg94 3y ago
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.
- mmis1000 3y ago
  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.
  - jakelazaroff 3y ago
    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 https://github.com/WICG/webcomponents/issues/909
    - EnergyAmy 3y ago
      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.
      - jakelazaroff 3y ago
        How would you build, say, a component library like Shoelace [1] using iframes? [1] https://shoelace.style/ https://shoelace.style/
        earthboundkid 3y ago
        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.
        jakelazaroff 3y ago
        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 https://shoelace.style/components/breadcrumb
Devasta 3y ago
That sounds awful to be honest. A recipe for total loss of standardization within an org.
- recursive 3y ago
  Any sufficiently large org already has all the technologies.
mmis1000 3y ago
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.