Enhance WASM: Back End Agnostic SSR for Web Components
begin.com
begin.com
SvelteKit server-side runs happily on e.g. Cloudflare Workers which is just V8 + Web APIs, and definitely not Node or Deno.
Generating the files to deploy to a Cloudflare Worker still needs NodeJS.
What am I missing?
SSR doesn't mean that you can't use web component frameworks, just that the framework must be able to both (1) produce and manipulate DOM in the browser as output, and (2) render the same components into HTML strings on the server. I believe frameworks with this capability are categorized as "isomorphic" frameworks.
Enhance WASM essentially makes Web Components an isomorphic component framework, with a bonus (for some) of not having to use a server-side JavaScript runtime.
My confusion is that a web component by definition has to run client-side javascript. You're either (a) using javascript to port content from a template into your custom element, or (b) using javascript to attach a shadow dom to a custom element. I could be wrong about this, but I don't believe there's a way to send down a working web component from the server without accompanying client-side logic.
Do you mean declarative shadow dom? That landed in FF 123, so I think it's now available on all major browsers.
I had a skim of the Lit SSR docs and they didn't really spell it out either
My best guess at something that might make sense is if the idea is to pre-render something usable, but static, with SSR and then once that is delivered to the client it is able to upgrade itself back into an interactive client-side web component ?
No idea if that's what these are trying to do though
What I'm saying is that if you inline your styles in a style tag (either in the shadow DOM or in the head of the document) then the browser doesn't have to make any additional requests at all, because the styling information is present in the initial document already.
If you don't inline your styles, then the browser has to make two separate requests if the cache is empty: one to fetch the document and figure out which additional resources need to be loaded, and then an additional request to actually download those resources. There's no HTTP protocol shenanigans or link preloading that can change the fact that packets are being transmitted from the browser to the server and back again twice. It's basically another formulation of the N + 1 query problem. Once the CSS file has been cached you only have N requests instead of N + 1, but then the cache has to be invalidated every time you update your styles so you're back to square one again. The documentation for Lit explicitly recommends avoiding external stylesheets for web components, because it can lead to a flash of unstyled content while the browser makes an additional request to load the external styles: https://lit.dev/docs/components/styles/#external-stylesheet
If you place the link element inside the head of your document, then it is render blocking, which means the browser has to make two round trips to the server if the CSS file isn't in the cache before it can render (one to download the HTML file, and then another after it discovers your link element, and has to download the corresponding CSS file).
> The best from both worlds is to embed a lightweight basic CSS stylesheet inline and the rest in cache-able external CSS files.
This is the absolute optimal way of doing it. You would have to analyze your styles to see which styles are applied to elements above the fold, then extract them and put them in an inline style tag. The rest of the styles would have to be downloaded via a link tag, but you'd have to place the link tag at the very end of the HTML body tag to prevent the browser from blocking as soon as it encounters the link element or alternatively use JavaScript to add the link element after the page has been rendered. There are tools to automate this for static sites [1], but doing this for dynamically generated HTML is kind of a pain, and I've found that browsers parse CSS so quickly that the overhead of just inlining it all is very low in many cases.
I'm also curious why rendering something in the browser would have poor performance or wouldn't be optimally accessible?
To render something in the browser, you have to first send the browser javascript, which then needs to run. Server side rendering can usually be able to generate HTML faster than the javascript renderer can generate DOM. And the HTML itself is often smaller than the javascript needed to render the html. (And you can generate HTML from your server, not from your user's slow android phone via javascript).
Server side rendering almost always gets you a faster time-to-first-paint. Which is good for blogs and news websites. But if you need client side rendering anyway (eg you're writing Figma), then its not as big a deal.
Server side caching is pretty good these days and a valid option in more cases.
A lot of devs just started client side and the other side naturally seems bad or unknown. The time where this was an issue server side was when linux didn't network or perform so well with lots of traffic (and the cloud became popular). That's been largely solved.
It's hard to find concrete evidence for anything in SEO. However, from what I've seen (and is also shown by some big websites that index just fine) at least Google seems to do handle client side rendering just fine and has been doing so for ~5+ years.
The only thing you might get pinged on is if you have crappy core web vitals scores as a result of the client side rendering.
There is, in the sense that every site gets a CPU budget allocated for indexing. SSR means less of that budget gets used per page.
Is there some concept of a budget regarding how many pages they should index on your website? Yes. Is it the same thing as CPU budget, no. Does it impact what position you rank in absolutely not.
The vitals bvetween the average client side compared to the average server side can be staggering.
For example, if you take a website that is using client side, on a headless cms or something vs Wordpress, wordpress has many, many plugins that obsess on optimizing the assets and delivery of the file beyond most client side implementations.
I love building myself a client side site, it feel so fast, until the need to communicate better or at scale increases and it is a reminder why the website should just be something that is good at being a website.
I wonder how Reddit gets indexed given its client-side rendering is painfully slow.
Server side is generally lower cpu hit for content that is more SEO specific.
I feel it's much easier/better to concentrate on social media or sites like hn/reddit to increase your site's discoverability.
Google will crawl and render client side only sites, but the crawl budget will be reduced.
The bigger factor is that Google cares a lot about long clicks - clicks on results which don’t immediately produce another search or a return to the results page. Client side rendered sites almost always perform worse from the POV of the user and therefore convert at a lower rate.
And now Web Vitals includes things like Largest Contentful Paint and Interaction to Next Paint, you’re going to find it much harder to bring these metrics under the target thresholds.
If you want to perform well in search, make things easy for yourself: use mostly SSR HTML and CSS and some sprinkles of JS on top.
I assume that people who create client side rendered sites disagree. Surely no one wants to make user performance worse, and I struggle to see advantages sufficient to offset that.
You can read more about the things that are absolutely mainstream and are problems in very popular libraries in the "Speeding Up JavaScript" series from Marvin Hagemeister – like this one https://marvinh.dev/blog/speeding-up-javascript-ecosystem-pa...
Also, most devs are testing on powerful devices, and there is a big disconnect between their experiences and that of their users – https://infrequently.org/2021/03/the-performance-inequality-...
Whatever is developed is for the user, not the developer.
If developers making their lives easier (or appearing to through more layers of abstraction in some cases) is more important than the user, the users will go where the best experience is.
Beyond things like developer products, End users overwhelmingly don't care what anything is coded in.
I loathe FB but use it for exactly that reason.
I even admin and moderate FB groups and it is a constant struggle against the system - but that is where the community is, I have no choice. Other admins do not like it either, but it is where all the related groups are, and people are nervous of relying on solutions from volunteers (e.g. me setting up an old fashioned forum).
Where SEO is involved, simplest wins. There's a reason why Wordpress focused on making words easy to publish, organize, and connect, and from there try to be a CMS.
That's really a tough one to answer since every site is different, but here's a few things to keep an eye on when doing CSR.
You don't own the hardware rendering your site. Slow devices will render pages more slowly and there's really nothing you can do about it beyond optimizing the rendering logic itself.
CSR will always add more network requests to the page. For a small site, or a user close to your servers this may not be an issue. Caching on CDNs will help for any static files too.
Any API requests that are required for rendering will likely introduce waterfall network requests. If the APIs live on your servers, that could have been drastically reduced or removed all together if the HTML rendering was handled by server in the first place.
For accessibility, I'm not aware of anything that can't be done accessibly with CSR, but there are things that can get tricky. Every accessibility tool is different. Making sure that content added and removed is updated properly, changes are notified to users when necessary, and that focus is handled properly are all up to you when you decide not to "use the platform" as they say.
Server side has many advantages.
If the key is delivering SEO information, client side dynamic UX might not be the core of that experience, and may not be the best application for that part of it.
Google's? A bunch of random ass metrics.
Facebook's? Well, I guess you're making a Business Page.
Apple's? The list is so long.
JavaScript frameworks masquerade as SDKs and whatever, when really something like Next.js is a middleware with the same eventual product development complexity as Unity. Web developers think they have 2 browsers (Mobile Safari and Chrome). It's really like 10+ game consoles: Meta Instagram, Meta Facebook, Meta WhatsApp, TikTok iOS, TikTok Android US, TikTok Android Worldwide, Google Search destination, App Store iPhone, App Store iPad...
I didn't fully understand what WASM is doing here though. Web components whether React or otherwise are written in Javascript or something that compiles to it, so you need a server side JS engine (Elide/my Micronaut work use GraalJS). Is WASM just being used here as an alternative to providing a .so/.dll file?