Proposal: Server-side rendering about yew HOT 27 CLOSED

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

from yew.

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.

from yew.

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.

from yew.

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

from yew.

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

from yew.

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).

from yew.

GatsbyJS is exactly what I was thinking of...

from yew.

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.

from yew.

@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.

from yew.

@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

from yew.

I think next.js is a good reference.

from yew.

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.

from yew.

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

from yew.

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.

from yew.

@moldray

I think next.js is a good reference.

It uses ReactDOMServer

from yew.

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.

from yew.

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.

from yew.

? 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.

from yew.

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.

from yew.

@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?

from yew.

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.

from yew.

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.

from yew.

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

from yew.

@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.

from yew.

@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.

from yew.

@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.

from yew.

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.

from yew.