How to work with SSR pages?
Normally, react JS frameworks render all DOM in page by using JS file. When do SSR, some HTML DOM already available in page. Then how to handle these DOM in client side with react JS frameworks like SolidJS? Consider SSR not doing by JS. If it is use JS, can use SolidStart.
Example: Product page render in server side. It has many cards for products.
Also, I would like to know how to pass data from server to client?
Example: I do SSR for user page, and it has user data like ID, and other details. Not DOM. How to pass these details to client side to use in solidJS?
15 Replies
OK the core of the question seems to be:
“Can Solid be used by a web application rendered in a server language other than JavaScript”—yes, absolutely.
But before getting into that it has to be said that SolidStart was created to minimize the friction of creating and running a fullstack application. Note that in this context "fullstack" doesn't mean everything has to be written in JavaScript.
It's just enough JavaScript to allow rendering on the server (straight to HTML; i.e. strings, not DOM) while isomorphically accessing the same (JavaScript-based) APIs during server side rendering, as are used to refresh the client side state during client side rendering, while also being able to hydrate the client after initial load.
The rest of the back end can be written in whatever language is necessary as long as the JS-based web stack can access it (via HTTP or whatever foreign function interface).
As of right now, traditional non-JS servers do not perform the work necessary for client side hydration, so you are restricted to creating a client-side bundle for the SolidJS part which then creates a DOM subtree under some root element within the page that was rendered by the browser based on the HTML sent from the server.
Typically what happens is that the SolidJS part will fetch additional information from an API server. However initial data can be rendered into the page and retrieved when the code initially runs.
For an example see here; that example is for Preact but that approach can be adapted for Solid (or anything else running in the browser).
https://dev.to/this-is-learning/why-efficient-hydration-in-javascript-frameworks-is-so-challenging-1ca3
DEV Community
Why Efficient Hydration in JavaScript Frameworks is so Challenging
Hydration is the name given to the process in JavaScript frameworks to initializing the page in the...
thank you for information. As a summery, add data to
<script id="appProps" type="application/json"> </script> and add those data to JSX App as a input prop. This is for second question. For first question, I use Rust for SSR and it add some DOM to page but control is doing in client side. How to do it? old days doing it by using JQuary or JS using getelementbyid method.In terms of terminology: the Rust server generates HTML which the browser turns into DOM.
SolidJS has access to the entire DOM document via the use of vanilla JS but as a framework it only controls the DOM subtree that it creates via client side rendering. So it doesn't “take over” control of the DOM that was created from the HTML sent by the server.
This process of “taking over the DOM that was created from the HTML that was sent by the server” is what hydration is all about.
There are no non-JS SSR hydrating frameworks right now. And once you are using JS-based SSR for hydration you may as well use SolidStart.
If you are looking to manually attach functionality to DOM generated from server-generated HTML I'd strongly recommend taking a good, long look at qsa-observer (example)
GitHub
GitHub - WebReflection/qsa-observer: handle elements lifecycle thro...
handle elements lifecycle through CSS selectors. Contribute to WebReflection/qsa-observer development by creating an account on GitHub.
There are no non-JS SSR hydrating frameworks right now. And once you are using JS-based SSR for hydration you may as well use SolidStart.What about leptos? dioxus? Both can do SSR/hydration afaik. But ye, for hydration the client needs to know what the server has rendered, so it needs to be done in the same library on the front/back. U could render only the skeleton on the server and then render/mount a client side app into a html-element of that skeleton. Then u don't need to hydrate.
What about leptos? dioxus?What do you think people who would consider SolidJS/SolidStart niche think of those? And from what I recall even Leptos has to lean heavily into progressive enhancement to have a good loading UX. Still seems lean, lightweight JS is the way to go for client side UI. So in my head I was more thinking of a fullstack product that was developed for the back end comfort zone but transpiled to efficient JS client side. Realistically speaking the browser's operating environment is very different from any back end that a common language (e.g. Rust) seems like a relatively minor win (i.e. learning the browser environment is the time sink, not JS). On the flip side running just enough JS on the server to generate HTML from the same code base while leaning primarily on browser native features (rather than costly, layered abstractions) client side seems to make more sense. The HTMX buzz is partially about staying in the back end comfort zone but can only go so far in terms of client capabilities and UX. Liveview pushes a bit further but is also pushing more outside of the back end comfort zone because of a conceptually expanded, different environment.
mount a client side app into a html-element of that skeleton.That's exactly what the repo I linked to was about.
GitHub
GitHub - peerreynders/astro-wc-ssr-demo: A recipe for "designed for...
A recipe for "designed for SSR" web components (with Astro-though not necessarily requiring server side JS) - peerreynders/astro-wc-ssr-demo
thank you for information. I think old days method can use with SolidJS. Old day use PHP for SSR and JQuary or pure JS use to handle events by identify elemets using ID. So when use SSR using Rust, I can handle events using JS.
<HTML Page>
<SSR HTML DOM />
<CSR DOM (solid JS) />
</HTML PAGE>
SSR HTML DOM event can handle using JS inside solid code but not hydrate any DOM. Example: Facebook profile page - profile header parts (cover letter, Add friend etc.) can use SSR and bottom parts (post render, comments) can use SolidJS. So only Add friend button click event need to handle inside SolidJS code. I think this method is posible way to do.
and bottom parts (post render, comments) can use SolidJSThe tradeoff is that you are exposing the visitor to Cumulative Layout Shift (CLS) . This is the main reason CSR SPAs send an empty document body—there is nothing to display until the client side code completes the first blocking render. With SolidJS SSR (& hydration) the shouldn't be any CLS. Astro & SolidJS can perform partial hydration for SSG or SSR but then you are back to fullstack JS. “… if you're not using JavaScript on the server, you're doing it wrong … but if you care about end-user experience, you can make more significant improvements by running JavaScript on the server [compared to any other server language «you» prefer] …” https://youtu.be/8ObxzMSIqKA?t=10921 Another take on client side augmentation: https://www.smashingmagazine.com/2022/02/web-frameworks-guide-part2/
Docs
@astrojs/solid-js
Learn how to use the @astrojs/solid-js framework integration to extend component support in your Astro project.
Docs
Astro Islands
Astro Islands (aka Component Islands) are a pattern of web architecture pioneered by Astro. “Islands architecture” was first coined by Etsy's frontend architect Katie Sylor-Miller in 2019, and expanded on by Preact creator Jason Miller.
Ryan Carniato
YouTube
Evolving Isomorphic Data-Fetching
New constraints have been leading to a complete rethinking of how we handle isomorphic data-fetching in JavaScript frameworks. Truthfully I don't have the full answer yet. Join me as we explore this topic understanding the constraints, learning from history, and attempt to design what the architecture of the future looks like.
0:00] - Preamble ...
Smashing Magazine
What Web Frameworks Solve: The Vanilla Alternative (Part 2) — Smash...
In this second part, Noam suggests a few patterns of how to use the web platform directly as an alternative to some of the solutions that are offered by frameworks.
True, just wanted to give some nuance to
There are no non-js hydrating frameworks right now.
Regarding the progressive enhancement, splitting bundles is still practically not possible w wasm afaik, but I think in islands mode leptos could actually be a pretty decent choice: https://book.leptos.dev/islands.html
That being said, I personally am not going to use those rust libraries, bc I don't know rust and I don't like waiting for things to compile.give some nuanceTo be honest, I didn't consciously realize that Leptos/Dioxus had hydration. I guess the real question is: why a Rust server? I mean, it's cool to learn/play with and if that is the goal then use Leptos. But the reality is that 80% of the internet seems to PHP-based anyway and eBay seems to do OK with Marko's Node.js based rendering—it's React SSR that is slow. https://medium.com/@mlrawlings/maybe-you-dont-need-that-spa-f2c659bc7fec
Medium
Maybe you don’t need that SPA
There’s an article by Tom MacWright that’s been gaining some attention in the twitter-verse: Second-guessing the modern web. I’d…
The tradeoff is that you are exposing the visitor to Cumulative Layout Shift (CLS) . This is the main reason CSR SPAs send an empty document body—there is nothing to display until the client side code completes the first blocking render.Can explain more about this how CLS effect with that? (and bottom parts (post render, comments) can use SolidJS) You mean when part of webpage already loaded using SSR and other part load after full load so CLS score will high? then not good.
I guess the real question is: why a Rust server?Because it is fast and not use much server resources. And also it is binary file so have more security.
But the reality is that 80% of the internet seems to PHP-based anyway and eBay seems to do OK with Marko's Node.js based rendering—it's React SSR that is slow.Yeah most of website PHP based because of wordpress. Rust is new and has more learning curve so most developers not use. But when use rust, long term website have more profit like PHP use. But not like NodeJS. NodeJS always uses more hardware resource to run and always use. I use Rust Axum for API endpoints. So I am thinking about SSR process. Old days I use PHP for SSR and jQuery for event handling.
then not good.Typical pages have, for example, a static footer at the bottom. If that footer is initially above the fold and JS starts to render something above it then that is going to result in a layout shift. There are various mitigations but rather than eliminating the problems they merely ameliorate them. That's why the rule of thumb is to either entirely render the content on the client or deliver the fully rendered page to the browser and then hydrate it.
And also it is binary file so have more security.If there was an imaginary compiler that generated a binary from PHP source would the result be more secure? Granted Rust is designed for memory safety and the Rust community tends to be more security aware but it's difficult to draw any definitive conclusions from that.
Because it is fast and not use much server resources.I understand that from a technical perspective. But that's is why I mentioned eBay. In 2012 they switched from Java to Node based rendering to improve development velocity and UX, without sacrificing rendering speed. https://youtu.be/7XR5-qDhqGY?t=166 Which leads to the next question: Are you sure that your use case cannot afford the server resources to support a node-based hydrating framework?
because of wordpress.Is there anything in the Rust ecosystem challenging WordPress? As I'm aware the only thing ramping up to do that is Astro and it uses server JS-runtimes.
learning curve so most developers not use.Go seems to be favoured as a back end language as it is perceived to have superior development velocity compared to Rust (…I personally find it mind numbing but that's just me…).
Smashing Magazine
How To Fix Cumulative Layout Shift (CLS) Issues — Smashing Magazine
Google’s Core Web Vitals initiative has taken the SEO and Web Performance worlds by storm and many sites are busy optimizing their Page Experience to maximize the ranking factor. The Cumulative Layout Shift metric is causing trouble to a lot of sites, so let’s have a look at ways of addressing any issues for that metric.
NodeJS always uses more hardware resource to run and always use.While true, every day businesses pay lots of money to vendors like AWS to run bloated software. Meanwhile, anecdotally a $6/month DigitalOcean droplet is enough for a 10,000 visitors per day WordPress site (…and I'd argue WordPress is bloated as well; it's used because it's convenient). Could Rust make better use of these resources? Sure. The question still remains: does it have to in your particular use case? Don't get me wrong, in general I'm on “Team Lean” but my observation has been that success in all things web is a weird beast.
I use Rust Axum for API endpoints. … Old days I use PHP for SSR and jQuery for event handling.Ok: 1. If Rust is non-negotiable: Try Leptos and see if you can tolerate the risk. 2. If Rust Axum is non-negotiable: The benefit here is that you are closer to the PHP-SSR development experience, the downside is the typical “develop 1 application for the price of 2” trade off. I'd shelf jQuery and on the client side develop exactly what I need using Noam Rosenthal's guidelines. One of the core ideas is that rendering only ever happens on the server; that means that client side code copies template element content that already exists on the page and then “fills in the blanks” before adding/replacing it on the page (which I further explored in this repo). If it's worth your time you can use
usignal if you want to leverage signals to minimize re-rendering but I suspect it would just make things needlessly complex.
Alternatively If you chose to go ahead with CSR SolidJS, expect to have to deal with CLS issues for the lifetime of the site (which is true for any typical non-SSRed CSR framework when rendered into existing page content).GitHub
GitHub - WebReflection/usignal: A blend of @preact/signals-core and...
A blend of @preact/signals-core and solid-js basic reactivity API - WebReflection/usignal
Smashing Magazine
What Web Frameworks Solve: The Vanilla Alternative (Part 2) — Smash...
In this second part, Noam suggests a few patterns of how to use the web platform directly as an alternative to some of the solutions that are offered by frameworks.
GitHub
GitHub - peerreynders/astro-wc-ssr-demo: A recipe for "designed for...
A recipe for "designed for SSR" web components (with Astro-though not necessarily requiring server side JS) - peerreynders/astro-wc-ssr-demo
wow thank you very much for information and your time. Really helpful.