3 ms·

One thing about web components that I've appreciated is that they can work without JS enabled (at least in theory). I've done this a few times for progressive e

One thing about web components that I've appreciated is that they can work without JS enabled (at least in theory). I've done this a few times for progressive enhancement. Broadly I agree with Nolan, though. Web components have enough rough edges that they're not going to take over the world in the current state. But, they are pretty nice for certain use cases. I'm not sure what he means by not playing well with server side rendering though. I've been doing that without issues.

mariusor 2y ago
> they can work without JS enabled (at least in theory). I wonder what makes you say that. All that I've seen seems to indicate[1] that Javascript is needed in order to register the template with a specific tag. [1] https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_templates_and_slots https://developer.mozilla.org/en-US/docs/Web/API/Web_compone...
- debugnik 2y ago
  Allegedly, declarative shadow DOM lets you declare the template next to the prerendered slot, without JS.
  - mariusor 2y ago
    Where is this "alleged" though? From one of the paragraphs behind my link: > This won't appear in your page until you grab a reference to it with JavaScript and then append it to the DOM
    - debugnik 2y ago
      Your link isn't showing the declarative shadow DOM, this does: https://web.dev/articles/declarative-shadow-dom#how_to_build_a_declarative_shadow_root https://web.dev/articles/declarative-shadow-dom#how_to_build... And the example below that one shows how to hydrate declarative shadow roots with JS custom elements, so the path to progressive enhancement should be clear. I say alleged because I haven't had the chance to try it beyond a toy example.
      - mariusor 2y ago
        I'm not sure what you meant when you said "without JS". To actually use templates you need JS. Yes you can declare them, but what's the point?
        debugnik 2y ago
        You've ignored the part where the declarative template is immediately attached to its parent as a shadow root by the parser, and its siblings become the slot children. You don't need to instance or register anything with JS there, just copy-paste the template (admittedly lame, but kinda the same repetition as SSR today, just less involved and with a shadow root).
  - nsonha 2y ago
    that's just wrong
    - debugnik 2y ago
      What, exactly, is wrong? I need actual replies to continue a discussion. This is a declarative shadow root [1]. The template goes next to its slot contents, so you can render both separately on the server and let the HTML parser attach the shadow root, without JS, then use JS custom elements to progressively hydrate it. [1]: https://web.dev/articles/declarative-shadow-dom#how_to_build_a_declarative_shadow_root https://web.dev/articles/declarative-shadow-dom#how_to_build...
      - nsonha 2y ago
        sorry I did not know about `shadowrootmode` but your original comment was just a single statement with a very specific claim. Now you are right about that you can use template without js. But I have to ask: what is the point of declarative shadow root? The point of template is to be reused instead of being used once at the same place that it's declared. This seems like adding more markup and introducing shadom dom for absolutely no reason. You may as well just write the markup directly .
        debugnik 2y ago
        The name of the template tag is misleading, I agree: It separates the shadow DOM elements, the "template", from the light ones, the children slots. Different server-side instances of the same components won't necessarily render the same shadow tree, so client-side reuse was out of the question for declarative shadow DOM. But unlike client-side template, you get to paint components much sooner, during the parser, or even without JS enabled. As for why a shadow root instead of the markup directly, well, that's kinda like asking why use web components at all, which I thought was part of the premise of this reply chain. Even without JS, the shadow DOM gives you scoped CSS and isolates the shadow elements from outer DOM and CSS selectors. And custom elements, the other half of web components, can be used in HTML before defining them in JS, at which point you get to enhance the entire page at once, so now you can progressively enhance properly isolated components possibly written with different frameworks.
- DonHopkins 2y ago
  Using HTML and CSS to make web interfaces without JavaScript is like using concrete to make garden gnomes without rebar, while the rest of the adult world is more concerned with using pre-stressed concrete with rebar to make skyscrapers and superhighways. Sure it's a marginal whimsical decorative use case, but not an important or interesting one. Most people who think turning off JavaScript is an important use case are only inflicting it upon themselves (and aggressively evangelizing that other people do it too) as performative luddites, to feed their martyr complex, so they have something to whine and complain about how the web is so unfair and out to get to them, and have exactly zero customers or products to support.
  - mariusor 2y ago
    You seem to be quite careless about whom you offend, but I'm not a fan. Please quit it, the only one whining right now seems to be you.
    - nsonha 2y ago
      really I feel the same as them
charrondev 2y ago
How is this supposed to work? With reactJS I know I can server render a component or template and I’ll say JSX makes a pretty good tempting language. With web components as far as I understand there is no good templating language built in anyways (so you have to bring your own) I’m not aware of a standard mechanism in which I can take some chunk of JS for a component associated with a tag and have it render out HTML that does not require JS to run.
nolanl 2y ago
Author here. I cover this in another post [1], but basically the interop benefits you get on the client just aren't there (yet) on the server. My north star: > Maybe in the future, when you can render 3 different web component frameworks on the server, and they compose together and hydrate nicely, then I’ll consider this solved. [1]: https://nolanlawson.com/2023/08/23/use-web-components-for-what-theyre-good-at/ https://nolanlawson.com/2023/08/23/use-web-components-for-wh...

mariusor 2y ago

> they can work without JS enabled (at least in theory). I wonder what makes you say that. All that I've seen seems to indicate[1] that Javascript is needed in order to register the template with a specific tag. [1] https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_templates_and_slots https://developer.mozilla.org/en-US/docs/Web/API/Web_compone...

debugnik 2y ago
Allegedly, declarative shadow DOM lets you declare the template next to the prerendered slot, without JS.
- mariusor 2y ago
  Where is this "alleged" though? From one of the paragraphs behind my link: > This won't appear in your page until you grab a reference to it with JavaScript and then append it to the DOM
  - debugnik 2y ago
    Your link isn't showing the declarative shadow DOM, this does: https://web.dev/articles/declarative-shadow-dom#how_to_build_a_declarative_shadow_root https://web.dev/articles/declarative-shadow-dom#how_to_build... And the example below that one shows how to hydrate declarative shadow roots with JS custom elements, so the path to progressive enhancement should be clear. I say alleged because I haven't had the chance to try it beyond a toy example.
    - mariusor 2y ago
      I'm not sure what you meant when you said "without JS". To actually use templates you need JS. Yes you can declare them, but what's the point?
      - debugnik 2y ago
        You've ignored the part where the declarative template is immediately attached to its parent as a shadow root by the parser, and its siblings become the slot children. You don't need to instance or register anything with JS there, just copy-paste the template (admittedly lame, but kinda the same repetition as SSR today, just less involved and with a shadow root).
- nsonha 2y ago
  that's just wrong
  - debugnik 2y ago
    What, exactly, is wrong? I need actual replies to continue a discussion. This is a declarative shadow root [1]. The template goes next to its slot contents, so you can render both separately on the server and let the HTML parser attach the shadow root, without JS, then use JS custom elements to progressively hydrate it. [1]: https://web.dev/articles/declarative-shadow-dom#how_to_build_a_declarative_shadow_root https://web.dev/articles/declarative-shadow-dom#how_to_build...
    - nsonha 2y ago
      sorry I did not know about `shadowrootmode` but your original comment was just a single statement with a very specific claim. Now you are right about that you can use template without js. But I have to ask: what is the point of declarative shadow root? The point of template is to be reused instead of being used once at the same place that it's declared. This seems like adding more markup and introducing shadom dom for absolutely no reason. You may as well just write the markup directly .
      - debugnik 2y ago
        The name of the template tag is misleading, I agree: It separates the shadow DOM elements, the "template", from the light ones, the children slots. Different server-side instances of the same components won't necessarily render the same shadow tree, so client-side reuse was out of the question for declarative shadow DOM. But unlike client-side template, you get to paint components much sooner, during the parser, or even without JS enabled. As for why a shadow root instead of the markup directly, well, that's kinda like asking why use web components at all, which I thought was part of the premise of this reply chain. Even without JS, the shadow DOM gives you scoped CSS and isolates the shadow elements from outer DOM and CSS selectors. And custom elements, the other half of web components, can be used in HTML before defining them in JS, at which point you get to enhance the entire page at once, so now you can progressively enhance properly isolated components possibly written with different frameworks.
DonHopkins 2y ago
Using HTML and CSS to make web interfaces without JavaScript is like using concrete to make garden gnomes without rebar, while the rest of the adult world is more concerned with using pre-stressed concrete with rebar to make skyscrapers and superhighways. Sure it's a marginal whimsical decorative use case, but not an important or interesting one. Most people who think turning off JavaScript is an important use case are only inflicting it upon themselves (and aggressively evangelizing that other people do it too) as performative luddites, to feed their martyr complex, so they have something to whine and complain about how the web is so unfair and out to get to them, and have exactly zero customers or products to support.
- mariusor 2y ago
  You seem to be quite careless about whom you offend, but I'm not a fan. Please quit it, the only one whining right now seems to be you.
  - nsonha 2y ago
    really I feel the same as them

charrondev 2y ago

How is this supposed to work? With reactJS I know I can server render a component or template and I’ll say JSX makes a pretty good tempting language. With web components as far as I understand there is no good templating language built in anyways (so you have to bring your own) I’m not aware of a standard mechanism in which I can take some chunk of JS for a component associated with a tag and have it render out HTML that does not require JS to run.

nolanl 2y ago

Author here. I cover this in another post [1], but basically the interop benefits you get on the client just aren't there (yet) on the server. My north star: > Maybe in the future, when you can render 3 different web component frameworks on the server, and they compose together and hydrate nicely, then I’ll consider this solved. [1]: https://nolanlawson.com/2023/08/23/use-web-components-for-what-theyre-good-at/ https://nolanlawson.com/2023/08/23/use-web-components-for-wh...