> why you put SSR and web components in the same sentence

Web components are a browser standard; so anyone thinking about the long haul for their web product would be well advised to think about web components as well.

> web components are literally incompatible with SSR

Declarative shadow DOM is an emerging browser standard that is literally compatible with SSR, and is already supported by Blink-based browsers.

> Web components are a browser standard; so anyone thinking about the long haul for their web product would be well advised to think about web components as well.

It doesn't make it

1. a good standard,

2. a requirement, and

3. a viable standard to support

There are countless issues with web components none of which are on any path to solution, they keep valiantly solving issues that only arise from introducing web components in the first place, and there are multiple well-documented and discussed reasons why the absolute vast majority of frameworks (including the new ones) don't use them as their foundation.

> Declarative shadow DOM is an emerging browser standard that is literally compatible with SSR

1. It's only "emerging"

2. As far as I understand, there are still multiple unresolved issues

3. The fact that it's available in Chrome (don't insult us by using the vague Blink-based browsers) means literally nothing. Because Chrome are well known for shipping half-baked Chrome-only non-standards just because they feel like it

(Don't also forget how horrendously bad the whole API is https://twitter.com/WebReflection/status/1526186094232064000)

> The fact that it's available in Chrome (don't insult us by using the vague Blink-based browsers) means literally nothing. Because Chrome are well known for shipping half-baked Chrome-only non-standards just because they feel like it

Great example is Custom Elements V0: they shipped it, forced a Youtube re-write in it (well, in Polymer), literally no one else implemented it, they had to wait ~7 years to remove it from the browser because they had to wait for Youtube to re-write everything again in V1.

Great standards, and a bet on the future, I'm sure.

I wanted to believe it as well, but the fact is their implementation is so clunky and lackluster they are more trouble than they are worth.

> Bo idea why you put SSR and web components in the same sentence

A typical JS framework fence sitter would build SSR first applications and might likely think about using a light weight framework like Svelte for a client rendered 'feature (or) two' like I did.

> There are multiple documented downsides, including by Rich Harris, the author of Svelte

In link [2] of my parent comment I've mentioned those, I've no technical contention on his PoV but that 'Custom Element' feature is buggy, Is not made clear upfront and that there's no intention to fix it.

> As long as you pretend you need web components for SSR, no framework will be right for you, including web components themselves.

What about web components first framework like Lit[1]? I'm not stating it as a fact, But asking?

[1] https://lit.dev/

> SSR first applications and might likely think about using a light weight framework like Svelte for a client rendered 'feature (or) two' like I did.

Rich Harris called this "transitional apps" :) See this excellent talk: https://www.youtube.com/watch?v=860d8usGC0o

There's now active work to finally let you build whatever you need from a single code: be it MPA SPA, or anything in between, seamlessly. Including things like "everything is SSR'ed except this specific part of the page". Svelte, Solid.js, Astro are all rapidly moving the state of the art towards that goal.

> Is not made clear upfront and that there's no intention to fix it.

IIRC the idea is to remove web components from the core eventually, and have them as a third/first-party add-on. Can't find the relevant tweets right now, so don't quote me on that :D

> What about web components first framework like Lit[1]?

Their SSR support is listed as experimental: https://lit.dev/docs/ssr/overview/ with multiple issues (see the end of the page).

There's a reason for that: web components in general cannot be SSR'ed. That is, you cannot take a random web component and have it SSRed. You have to do very specific manual hacks or very library/framework-specific/bundler hacks to make them work. See this excellent article for details: https://css-tricks.com/using-web-components-with-next-or-any...

Thanks for the resources, Wouldn't rehydrating the specific page which uses web component eliminate the need for explicit SSR support in the JS framework and thereby it comes down to whether the framework has good support web-components or not in the first place?

> Wouldn't rehydrating the specific page which uses web component eliminate the need for explicit SSR support in the JS framework

Erm.... No. If you don't have SSR then it doesn't matter if it's web components or not: they will be instantiated at runtime.

> it comes down to whether the framework has good support web-components or not in the first place?

All of them have decent support for web components (at least for "consumption").

The reasons they don't support them as a foundation (and at most emit web components if you tell them to) is that they don't want to deal with all the stuff like no SSR support, the need to still have all the layers above for things like lazy loading, progressive enhancement and a whole laundry of issues that none of the non-web-component frameworks have: [1][2]

[1] Why I don't use web components https://dev.to/richharris/why-i-don-t-use-web-components-2ci...

[2] https://twitter.com/Rich_Harris/status/1198332398561353728, explanation on SVG: https://twitter.com/Rich_Harris/status/1198339672361119745