4 ms·
> 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
by Abishek_Muthian 4y ago
> 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/ https://lit.dev/
- dmitriid 4y ago> 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 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/ 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-ssr-framework/ https://css-tricks.com/using-web-components-with-next-or-any...
- Abishek_Muthian 4y agoThanks 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?
- dmitriid 4y ago> 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-2cia https://dev.to/richharris/why-i-don-t-use-web-components-2ci... [2] https://twitter.com/Rich_Harris/status/1198332398561353728 https://twitter.com/Rich_Harris/status/1198332398561353728, explanation on SVG: https://twitter.com/Rich_Harris/status/1198339672361119745 https://twitter.com/Rich_Harris/status/1198339672361119745