4 ms·

I am not sold on web-components yet. Especially now with @scoped and import{type:css}, I think there's still a lot of merit to rendering an element statically,

I am not sold on web-components yet. Especially now with @scoped and import{type:css}, I think there's still a lot of merit to rendering an element statically, shipping it, and updating it dynamically via modern JS. I'm not sold on how people typically do that, and I think we should keep trying to innovate outside of the typical frameworks like React/Svelte, but I definitely don't see any part of web-components being useful to any type of site I run (and I run several disparate types).

pajamasam 1y ago
> rendering an element statically, shipping it, and updating it dynamically via modern JS Noob question, but what happens behind the scenes in terms of these concepts for web components instead?
vaylian 1y ago
Web components provide a clean abstraction boundary. You can add additional methods to your own tags which can encapsulate the logic for updating the data in the component.
- benatkin 1y ago
  They let you encapsulate the logic pretty much however you want, same as not using web components.
  - vaylian 1y ago
    When you call document.querySelector("something") in the main HTML document, it will not find "something" inside the internal HTML of a web component.
    - benatkin 1y ago
      You can use the shadow DOM outside of custom elements, and can use custom elements without a shadow DOM. Edit: I just added a shadow root to a div in your comment, saving its content beforehand, moved its content inside the shadow root, and added a style with * { all: initial } and your comment text got Times New Roman.
insin 1y ago
Web Components don't solve the problems I do have and add new problems I don't want. Many of the 25 mentions of Shadow DOM in the Components Page and 14 mentions of it in the Styling page are about solving problems you now only have because the site recommended you use Shadow DOM, and the problem Shadow DOM itself is _trying_ to solve is one I don't have in components written specifically for my app, which will only be used in my app.
- d0gbread 1y ago
  Hard agree, from practical experience also. One thing will push you towards shadow dom (slots, for example) then ten things will push you back towards light dom. I don't exactly understand what the spec is aiming to solve with the way things currently are. But I do appreciate no build process.
  - WorldMaker 1y ago
    Given the way most templates about Web Components are going it feels like a dirty secret that you don't need to use Shadow DOM at all when building Web Components and that it actually feels nice to build Web Components without it.
benatkin 1y ago
I think it’s time to go back to Unobtrusive JavaScript. What is needed for this are lightweight libraries or practices you can code yourself. HTMX is lightweight which is nice but it’s like script tags. I would rather the urls and methods go in plain HTML and stuff like hx-target be determined by JavaScript, using data- attributes if needed. That way all the unused HTMX features aren’t included.
- recursivedoubts 1y ago
  see also https://github.com/bigskysoftware/fixi https://github.com/bigskysoftware/fixi
- dleeftink 1y ago
  Shoutout to Facet also[0]. [0]: https://github.com/kgscialdone/facet https://github.com/kgscialdone/facet
derekzhouzhen 1y ago
You can use shadow-dom without using web-component. web-component and shadow-dom are orthogonal to eachother: * web-component is a way to attache javascript to certain elements. There are other ways to do it, but sometime this way feel cleaner, like when you do server-side rendering and not using any javascript framework. * shadow-dom is a way to organize your styles. As you said there are other ways to do it, but I find it useful because it offers full isolation, and is compatible with browsers 3 years back.

pajamasam 1y ago

> rendering an element statically, shipping it, and updating it dynamically via modern JS Noob question, but what happens behind the scenes in terms of these concepts for web components instead?

vaylian 1y ago

Web components provide a clean abstraction boundary. You can add additional methods to your own tags which can encapsulate the logic for updating the data in the component.

benatkin 1y ago
They let you encapsulate the logic pretty much however you want, same as not using web components.
- vaylian 1y ago
  When you call document.querySelector("something") in the main HTML document, it will not find "something" inside the internal HTML of a web component.
  - benatkin 1y ago
    You can use the shadow DOM outside of custom elements, and can use custom elements without a shadow DOM. Edit: I just added a shadow root to a div in your comment, saving its content beforehand, moved its content inside the shadow root, and added a style with * { all: initial } and your comment text got Times New Roman.

insin 1y ago

Web Components don't solve the problems I do have and add new problems I don't want. Many of the 25 mentions of Shadow DOM in the Components Page and 14 mentions of it in the Styling page are about solving problems you now only have because the site recommended you use Shadow DOM, and the problem Shadow DOM itself is _trying_ to solve is one I don't have in components written specifically for my app, which will only be used in my app.

d0gbread 1y ago
Hard agree, from practical experience also. One thing will push you towards shadow dom (slots, for example) then ten things will push you back towards light dom. I don't exactly understand what the spec is aiming to solve with the way things currently are. But I do appreciate no build process.
- WorldMaker 1y ago
  Given the way most templates about Web Components are going it feels like a dirty secret that you don't need to use Shadow DOM at all when building Web Components and that it actually feels nice to build Web Components without it.

benatkin 1y ago

I think it’s time to go back to Unobtrusive JavaScript. What is needed for this are lightweight libraries or practices you can code yourself. HTMX is lightweight which is nice but it’s like script tags. I would rather the urls and methods go in plain HTML and stuff like hx-target be determined by JavaScript, using data- attributes if needed. That way all the unused HTMX features aren’t included.

recursivedoubts 1y ago
see also https://github.com/bigskysoftware/fixi https://github.com/bigskysoftware/fixi
dleeftink 1y ago
Shoutout to Facet also[0]. [0]: https://github.com/kgscialdone/facet https://github.com/kgscialdone/facet

derekzhouzhen 1y ago

You can use shadow-dom without using web-component. web-component and shadow-dom are orthogonal to eachother: * web-component is a way to attache javascript to certain elements. There are other ways to do it, but sometime this way feel cleaner, like when you do server-side rendering and not using any javascript framework. * shadow-dom is a way to organize your styles. As you said there are other ways to do it, but I find it useful because it offers full isolation, and is compatible with browsers 3 years back.