Proposal: Server-side rendering

[KSXGitHub]

No description provided.

[RangerMauve]

Node.js supports WASM globals now, so this could potentially work, but I assume that stdweb and yew both assume a browser environment for JS interop, so it'll be a bit harder

[KSXGitHub]

@RangerMauve A Rust server shouldn't require any foreign tool (such a Node.js) to do such thing.

[moldray]

I think next.js is a good reference.

[KSXGitHub]

What yew need right now is ability to render HTML string from view function.

I expect cargo web start server sends pre-rendered HTML to browser but what I received is a <script> tag instead. I assume that Rust code using yew is only meant to be converted to WASM.

[KSXGitHub]

@moldray

I think next.js is a good reference.

It uses ReactDOMServer

[therustmonk]

Thank you for the issue! It's important thing. I think Rust is the best candidate to implement this kind of features. But it will take some time to implement it. Let's keep this issue opened.

[mtsr]

Another really interesting thing to do with server-side rendering is AOT rendering of all static routes, such as for a blog. That way you don't even need to run the server for simple sites, but can just deploy the static site.

There's a few examples of React blogs that work that way.

[naartjie]

Another really interesting thing to do with server-side rendering is AOT rendering of all static routes, such as for a blog. That way you don't even need to run the server for simple sites, but can just deploy the static site.

@mtsr I was also thinking about this. It looks like the html! macro is quite powerful, and I started wondering if something like GatsbyJS could be doable with yew, or if there are even simpler ways of solving the use-case for static sites.

[mtsr]

GatsbyJS is exactly what I was thinking of...

[ericmarkmartin]

What's the status of this feature? I'm new-ish to Rust and really liking this framework and I'd love to help out with this if it's being worked on.

[theashguy]

I’ve been spending a lot of time recently on converting some pretty large react apps to Gatsby and have a lot of opinions around what’s important. Would love to be part of bringing together this as a feature.

[KSXGitHub]

GatsbyJS is exactly what I was thinking of...

GatsbyJS only render static pages, it does not render dynamic pages. I want yew capable of rendering dynamic pages (like Next.js).

[theashguy]

? Gatsby is just SSR React during build.

Oh you mean backend rendered dynamic pages? I think what you’d do is make the DOM macros be able to be used inside the view renderer of a web server like rocket or actix and then also have another pattern to use the same renderer in a custom configured CLI app that could be run on build. And then the DOM that either / both generate can be hydrated into a Yew app once the webasm is downloaded.

[theashguy]

The bigger question to my mind is how it aligns with the current goals of the Yew project? How would it be implemented in a way that compliments what we already have without sacrificing using it in its current use case to add the functionality we’re keen on? And how does it affect the current team? Is it something they even want as part of the project or should it be something entirely external that just uses Yew as a dependency.

[olebedev]

Hey @deniskolodin, any chance to see updates wrt this issue?

[jstarry]

Here's a nice post about rehydrating state on client side after a server side render: https://joshwcomeau.com/react/the-perils-of-rehydration

[onelson]

Something I've been thinking about is how to build something like Phoenix LiveView for rust projects.

I could totally see a combination of a rust service with websocket support pushing SSR yew content to the client which is then applied to the DOM via morphdom.

Wanted to chime in here since I hadn't seen this discussed elsewhere. It's an interesting idea but definitely requires some opinionated framework choices to implement successfully.

[jstarry]

@onelson cool ideas! One of the current advantages of using a virtual dom in wasm is that it helps limits DOM API calls which require JS glue at the moment. I haven't run benchmarks on how much that slowdown is across different major browsers yet.

I think a liveview type framework would likely live on top of yew as a separate crate. Do you want to open another issue to discuss?

[onelson]

Do you want to open another issue to discuss?

I'd be happy to kick off the discussion on a new issue, but I'd urge voices who have worked directly with this feature of Pheonix to participate in the discussion (I have not). I'm still unclear as to just how much overlap the goals of yew align with what's required for a LiveView-like setup. More research required.

This is something I've been thinking over since an article prompted Dan Abramov to tweet.

[damooo]

Hey guys, i want to point towards svelte & sapper projects.

Svelte is a compiler unlike react, in that it compiles svelty-js to imperative js in many modes. like it can compile for browser target, and for ssr target. ssr compiled js is basic string concatenation in node. This way, ssr is blazing fast.

Here too we may compile it to a wasm target, and an efficient rust target for ssr.

[chpio]

@damooo i don't think that you can even compare non-vdom svelte/imba/... (or my poc lib in rust, that's blocked on GATs right now.) libs to vdom libs like react/yew etc. the basic principles are very different.

The vdom fraction is based on a dynamic (all the elements sit on the heap in Boxes) vdom that is built at runtime. There's no way you could resolve that at compile time without insane compiler optimizations.

[KSXGitHub]

@damooo I don't know why you brought this up in an issue about server side rendering in which DOM manipulation mechanism is irrelevant.

[damooo]

@KSXGitHub .

I just wanted to point out svelte's approach to ssr. Svelte compiles it's components to multiple targets, like for client, and for server. server-targetted build doesn't have anything to do with dom, but an effective ssr-specific component, which only performs string concatenation to generate html.

[KSXGitHub]

@damooo Ah, I didn't read all of your comment, sorry. Anyway, back to the topic, Rust has zero-cost abstraction which can be used to transform a Yew component into a string concatenation.

[Ciantic]

@KSXGitHub is there an example of this? I couldn't figure out an API for that last time I tried. I wanted to create static site generator for my blog, and not use web assembly at all, just generate strings from components and store them to HTML files.

[stoically]

@Ciantic A bit random, but if your goal is really just to generate strings from HTML then maybe the html-to-string-macro example from syn-rsx is interesting. I'm using that for my site, though, served by warp - but could be used in a build script or written to a file after macro execution, I guess

[0x1af2aec8f957]

At present, most SSRs need to write specific code to complete.
In nodejs, you can use jsdom to do SSR, so there is no need to change the isomorphic code.
Rust needs a library similar to jsdom to implement the first access to server-side rendering, and subsequent requests use client-side rendering, and client-side rendering and server-side rendering do not need to deal with compatibility code.