See the entire conversation

Losing my mind at how bad web component marketing is. The "web components can't ssr" is a lie from the depths of hell; it's false. No, you don't need to rewrite all your shit in Lit You don't need some weird wc server You just need to synchronously register your wc's 🧡
37 replies and sub-replies as of Aug 23 2022

What does synchronously register your web components mean? Somewhere in your JavaScript there's code that does something like this. It needs to run in a blocking script from your document's head. Then, when your wc's parse, they'll immediately render correctly; no fouc.
Next will fight you every step of the way. It'll tell you to use its Script component from "next/script." Don't. Even with the strategy of "beforeInteractive" it'll emit a script tag with defer. Just do this, and tell Next to fuck off with its warnings.
Then you'll need to change the eslintrc file Next gives you from this "extends": "next/core-web-vitals" to this "extends": "next" since the former fails your build if a synchronous script is present.
"Oh but Adam you'll wreck your Lighthouse score," you pine. I wrote Vite script to bundle a few Shoelace components into a standalone UMD script. I stuffed it into my doc's head. It was 60K minified. About 25% the size of React.
The Lighthouse score was 100%, but if you're curious what the absolute cost was, it was about 0.4s lcp. Obviously not free, but probably manageable, especially considering you could cache this with a service worker using something like Workbox.
And this was for some thicc, high quality, accessible web components. Something simpler would be smaller, and cost less. This was basically a blank page w/ some web components, and static content to confirm no fouc. The 0.4s is the startup cost you pay, and build your app onto.
But seriously service workers exist, as does Workbox to make them easy. Cache that shit so only first-time visitors pay that price. Unless you're in eCommerce, or click-bait content garbage, that's a decent tradeoff!
Wanna try it out? Like I said it's just a few web components (some tabs, progress bar, a section divider) along with some text. When the hydration script runs, you'll see the text turn purple (via React effect). But layout is done immediately; no fouc. next-wc-ssr.vercel.app
Oh and lastly if you're one of those eccentric folks who wants your shit to work without JavaScript enabled then just move along; this isn't for you.
Not for professionals who care about accessibility. Got it.
That's an incredibly bad faith take, to say nothing of the fact that plenty of web apps (apps, ie applications, not static sites with a few event listeners sprinked on) depend on js to function, and don't do anything useful without it.
Just responding in kind to the bad faith eccentric assertion. I don't think being a professional with concern for really basic web tenants around ethics is eccentric.
Like..*really basic*. Junior dev basics.
"really basic web tenants" is meaningless. The web is a big place. There's lots of different kinds of software being built. Much of it isn't intended to work without JavaScript. That's fine. Pretending like that's some deep violation of Web Dev Best Practices™ is just silly.
I don't know what you think this page proves. There's software delivered over the web that's not designed to work without JavaScript. That's fine. That doesn't break some deep, meaningful law of what ✨The Web✨ is
Let’s be honest that clickbait garbage can’t get much more stinky or rotten lol
what's the gzip/brotli size?
Could be better to disable specific rules instead of chucking the whole config here
Nah gotta throw the whole lint package in the trash :)
Whoever developed that is just Sweating Questioning their life’s decisions Why Why did they fail your build lol
Its Alex Ru$$els slice of the js industrial complex
The one part he cared about
That’s technically blocking CSR, since everything inside root wcs are rendered by JS on the client. You can also inline your entire React bundle as a blocking script in the head - also no fouc, but that’s not SSR!
Yeah - I did mention that in a separate reply I’ll clarify better if I blog about this. Good callout - thx πŸ‘Š
You’re right. As replies said, crawlers might run JS, but otherwise this isn’t *true* ssr; it just works without fouc.
Do you happen to have (or know of) a good tutorial for getting started with Web Components?
This just renders the html on the server assuming the custom elements will hydrate to something real on the client right? The only drawback with this approach is if there is content in the web component that you want crawlers to understand. O/w this is very cool. Love the perf!
no drawback because js is resolved by crawler and page is indexed, as any other SPA app. I do this for years now, works perfect.
Not every crawler runs javascript. GoogleBot is like the only one that does and pages that require JS to run get indexed slower. TwitterBot, the Facebook crawler, Reddit crawler etc none of those execute JavaScript.
are not html dc meta attribs used for that? I allwaxs use at least img, title, desc and canonical. never had problems with preview what am I missing?
You’re right. As replies said, crawlers might run JS, but otherwise this isn’t *true* ssr; it just works without fouc.
Arguably content like that should be part of the light dom. So passed as slots rather than rendered directly into the shadow root. Then the crawler will see the content regardless of if you elements have been registered and upgraded
Adam I just love your enthusiasm for webcomponents. I've been a huge fan of them since I've first started working with them in 2017 and seeing people talk about them in a positive way like you do is just amazing.
I don’t think this is really what people mean by SSR. The server would just be “rendering” <your-web-component></your-web-component>