A note about server-side rendering (SSR) #5
Locked
claviska
started this conversation in
Feature requests
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Framework SSR was created to solve problems introduced by client-side frameworks. When we moved to rendering everything with JavaScript, we broke SEO, social media previews, and page load performance. While framework SSR can be helpful in some scenarios, it's often misused to justify shipping massive JavaScript bundles that leave pages looking ready but completely unresponsive until everything loads and hydration completes.
The idea behind framework SSR is that fetching and hydrating can be done in the background before the user is likely to interact with the page. As such, it first sends the user a "fully painted" picture they can't actually do anything with while waiting for the browser to download and process a multi-megabyte bundle. However, it's become common to see 5+ seconds until TTI in the wild, leaving many users confused and frustrated.
Quiet isn't interested in supporting the framework SSR fallacy. As part of the platform, web components can be server-side rendered traditionally like all other HTML elements have since the early days of the Web. Just generate the appropriate HTML tags, import the components, and you're good to go.
If you're using Quiet's autoloader, it will only fetch the components you're actually using on the page. And to eliminate FOUCE, the most common reason people reach for SSR when using web components, Quiet provides some simple and effective tools.
The key to a great experience on the web isn't SSR, it's less JavaScript. If you're of the belief that you need framework SSR and all the needless complexity it brings to a project, this library isn't for you.
Beta Was this translation helpful? Give feedback.
All reactions