4 ms·

Maybe, but while I love UI components, I really dislike that "web components" conflate and combine multiple things like custom elements, and shadow DOM, etc. S

by gedy 3y ago

Maybe, but while I love UI components, I really dislike that "web components" conflate and combine multiple things like custom elements, and shadow DOM, etc. So working with them in real apps, you get a mess of opinions and assumptions like completely isolated styles (no I don't want this! let me use my site's Bootstrap theme!), etc. Also dealing with string-based attributes/props is a pain. I greatly prefer React/Svelte/Vue for not having to deal with all this.

zaphar 3y ago
It's an umbrella term for a set of technologies. Each of them can be used in isolation from the others if you want though. You don't have to use shadow DOM if you don't want it. You don't have to use custom elements if you don't want to either. You are correct though that almost every tool that works with them sort of assumes you are going to use both.
- tuzemec 3y ago
  I kinda like this approach. You can change the combination of used APIs for different cases. "Widget" that you provide for partners to put on their web pages? Of course you'll use shadow DOM, because you don't know the page context, surrounding styles, etc. A component to share on different parts of your site - you can skip the shadow DOM, because you share common styles everywhere, and probably you want to inherit some of them.
  - zaphar 3y ago
    I think in terms of the implementation keeping them separate and composable is very useful. I think the marketing around it could have emphasized it a little more but that's water under the bridge really.
jjcm 3y ago
It's fairly easy to choose between style isolation and no style isolation though. Just change the `this.shadow.innerHTML` in the render to `this.innerHTML`. The encapsulation aspect provides some really nice benefits in many scenarios, so having the option of this is quite nice. A classic example of why this is beneficial is when creating design system components - you typically want these to not be affected by styling on the page, and if you do want them to be styled, you only want them to be styled in specific ways which you can build in via css custom property values (see the accent example the author provides).
- gedy 3y ago
  > you typically want these to not be affected by styling on the page, and if you do want them to be styled, you only want them to be styled in specific ways which you can build in via css custom property values Ironically, this proves my point about opinions a bit - our design system is themeable and needs to cover a number of technologies and we want to inherit the app's CSS, not embed the styles or have to specify colors on every component.
  - jjcm 3y ago
    There's a strong difference between styles and themes. Theming is quite easy with web components, as long as you have a semantic layer to your design tokens. Since custom properties do cascade, it's quite easy to automatically switch themes while still preventing css-selector clobber issues with styles. If you're curious on this approach, my site non.io has light/dark theming via this method, and Figma's light/dark mode was loosely based on this approach.

by gedy 3y ago

zaphar 3y ago

It's an umbrella term for a set of technologies. Each of them can be used in isolation from the others if you want though. You don't have to use shadow DOM if you don't want it. You don't have to use custom elements if you don't want to either. You are correct though that almost every tool that works with them sort of assumes you are going to use both.

tuzemec 3y ago
I kinda like this approach. You can change the combination of used APIs for different cases. "Widget" that you provide for partners to put on their web pages? Of course you'll use shadow DOM, because you don't know the page context, surrounding styles, etc. A component to share on different parts of your site - you can skip the shadow DOM, because you share common styles everywhere, and probably you want to inherit some of them.
- zaphar 3y ago
  I think in terms of the implementation keeping them separate and composable is very useful. I think the marketing around it could have emphasized it a little more but that's water under the bridge really.

jjcm 3y ago

It's fairly easy to choose between style isolation and no style isolation though. Just change the `this.shadow.innerHTML` in the render to `this.innerHTML`. The encapsulation aspect provides some really nice benefits in many scenarios, so having the option of this is quite nice. A classic example of why this is beneficial is when creating design system components - you typically want these to not be affected by styling on the page, and if you do want them to be styled, you only want them to be styled in specific ways which you can build in via css custom property values (see the accent example the author provides).

gedy 3y ago
> you typically want these to not be affected by styling on the page, and if you do want them to be styled, you only want them to be styled in specific ways which you can build in via css custom property values Ironically, this proves my point about opinions a bit - our design system is themeable and needs to cover a number of technologies and we want to inherit the app's CSS, not embed the styles or have to specify colors on every component.
- jjcm 3y ago
  There's a strong difference between styles and themes. Theming is quite easy with web components, as long as you have a semantic layer to your design tokens. Since custom properties do cascade, it's quite easy to automatically switch themes while still preventing css-selector clobber issues with styles. If you're curious on this approach, my site non.io has light/dark theming via this method, and Figma's light/dark mode was loosely based on this approach.