DEV Community

Cover image for Server Side Render Web Components

Server Side Render Web Components

Stephen Belovarich on February 21, 2020

This post is outdated. Check out the latest, greatest way to server-side render Web Components in this post: Server Side Rendering a Blog with Web ...
Collapse
 
dfabu profile image
Dan Fabulich

@skatejs/ssr does something kinda quirky and wraps the Shadow DOM content in a shadowroot tag.

That's alright, because the client side router kicks in immediately, replaces the element in the same container and renders the appropriate shadow-root in DOM.

That's not what SSR means. SSR means that server-rendered HTML gets hydrated, without modification, to add interactivity. You're rendering a server-rendered page and then blowing it away and replacing it with a client-rendered page, undermining your performance gains.

P.S. I pulled down the feature/router branch and ran it with JS disabled. The page is blank. This isn't SSR… not even close.

Collapse
 
steveblue profile image
Stephen Belovarich • Edited

Server side rendering means generating html on the server, that is all. What you are describing is how server-side rendering works in React, but how server-side rendering is handled in React does not define how server-side rendering is done everywhere.

The Lighthouse score on my personal site which uses a modified version of this SSR technique would disagree with your performance assessment. The site only takes a slight hit to performance because of the cheap server the site is hosted on, otherwise it would be 100%.

When you pulled down the branch, did you also run the node server? Something sounds amiss.

Collapse
 
steveblue profile image
Stephen Belovarich • Edited

Pulled down the feature/router branch and noticed a bug with Parcel. I also updated the example so it should work out of the box now. Example is a year old, just needed a little maintenance. There seems to be some issues with styling, but that could be fixed.

Collapse
 
64bitdev profile image
64BitDev • Edited
Collapse
 
steveblue profile image
Stephen Belovarich • Edited

Yes, Declarative Shadow DOM is still only available in Chrome AFAIK.

Thread Thread
 
steveblue profile image
Stephen Belovarich • Edited

Although if I were to SSR WC today I would use Declarative Shadow DOM and tooling provided by Lit, polyfill the rest of the browsers.

Collapse
 
steveblue profile image
Stephen Belovarich

New blog post here uses @lit-labs/ssr instead, way better solution IMHO.

dev.to/steveblue/server-side-rende...

Collapse
 
steveblue profile image
Stephen Belovarich • Edited

Good catch! That's a bug in the library I used for WC Readymade. It can be replicated when there are no styles specified. Not a bug in SSR. Styles are rendered fine. Maybe I’ll update the example in the near future to demo styling too.

Collapse
 
steveblue profile image
Stephen Belovarich

Updated with fixed example.

Collapse
 
obonyojimmy profile image
jimmycliff obonyo

Superb article , i use github.com/popeindustries/lit-html... to ssr webcomponents , cleanly works on all environments browser, server even sw.

Collapse
 
ovieduke profile image
Duke Ovie

Thanks @steve for a great writeup.

Collapse
 
tojacob profile image
Jacob Samuel G.

I learned a lot. Thank you.

Collapse
 
sayakb profile image
Sayak Banerjee

Wonderful article @steveblue . I am trying to get this working with LitElement but I'm unable to pre-render the shadow DOM. Do you think it is possible to achieve that?

Collapse
 
trusktr profile image
Joe Pea

Lately Lit SSR is achieving new ways to do SSR:

lit.dev/docs/ssr/overview/

Collapse
 
steveblue profile image
Stephen Belovarich • Edited

Yeah, I've been meaning to make a follow up blog post. I also have a workshop in the works for SSR with @lit-labs/ssr.