What if NextJS was just... Rust ft Perseus and Sycamore

[@thanatosor]

Can’t wait for Rust On Rails 😂

[@ohturry5591]

Trains will crash a lot 💀

[@ploruto9661]

Please more! and "long videos" are not something bad, so feel free to make even longer videos ;)

[@chrisbiscardi]

heh, since I make a video every day they can only be so long before setting up, recording, and editing takes longer than that 😅 I have a couple specific videos in mind that will run longer though (and thus will take more time to put together).

[@verified_tinker1818]

I've been waiting for this!

[@Tobi-gl2lb]

Very nice video, as usual! Would love a video about the different rendering strategies in perseus.

[@larrymarso4492]

Straightforward to set up SSR plus hydration with Axum server side, on plain vanilla sycamore. I hope to hear more about Perseus templating. Advantages over other rust solutions or database driven homegrown?

[@jcolindres001]

Hi Chris, Go to know about all these projects in Rust. Which of these projects would be the best: Yew, Perseus, Leptos, Sycamore, etc.? according to your experience. Best regards, JA

[@chrisbiscardi]

They all have different tradeoffs and I don't think any one of them is "the best". If I was making a site for a client I'd probably reach for something that's been around longer like Yew unless they had requirements that fit Perseus better. Leptos is up and coming and is just about to see its 0.1 release so I'd only use it if you wanted to be on the early-adopter cutting edge.

[@ryanmcwhorter8501]

Really cool video! I want to ask though, if you think that this tech stack is mature enough/good enough to justify using over any of the traditional JS/TS options. Could you justify this as a choice at a company?

[@chrisbiscardi]

I think it's *good enough*, but that's true for most things really. It's not hard to hit a low bar of "can build a webapp/website" for new technology these days and it's all about your project's constraints, etc. Perseus/Sycamore and the Rust ecosystem in general is much younger than the JavaScript ecosystem... but Rust is really good at WASM and maintaining Rust projects tends to be more achievable than JS/TS projects. You also tend to get better performance (in terms of memory usage, etc) with Rust server-side code than JS/TS. So yeah, I could see this being used at a company *but* that will not be a generally applicable sentiment to all companies. I wouldn't walk around telling everyone to rewrite their JS apps in Rust, or to retrain all of their JS developers, etc. Also If your company's expectations are built around specific technologies (ex: "what WordPress offers", or "NextJS has feature X,Y, and Z, and offers integrated paid hosting") it can be really hard to move on to any other ecosystem.

[@ryanmcwhorter8501]

@@chrisbiscardi Cool! I might take a shot at making myself a resume site with this.

[@chrisbiscardi]

@@ryanmcwhorter8501 that sounds like a great project to try

[@iamchu]

Really cool! Do you anticipate a JSX/TSX style approach to the current view implementation down the line? (Asking as someone who has beginner level knowledge of Rust but wants to learn - also idea of .rsx seems cool to me)

[@chrisbiscardi]

Leptos and Dioxus already use an rsx style 👀 I've got two videos on leptos on the channel right now

[@iamchu]

@@chrisbiscardi ah cool will check them out!

[@jaysistar2711]

My problem with Perseus is fixable. I want a single binary that does both frontend SSR/static file and also serves the API. It may be fixed, now, but, the last time that I checked, it was reccomended to have a seperate API server. Even so, I'm pretty much done with SSR. It's not something that offers any benefit past the 1st page load, and 1st page load is already fairly fast in my apps. Code splitting (for WASM) is a much more interesting.

[@chrisbiscardi]

yeah I definitely think the recent surge to push SSR for everything adds complexity that isn't necessary for a lot of projects. A lot of this focus came from VC backed companies' marketing efforts in the JS ecosystem. The UI vs API split is something I do in all my projects so it doesn't particularly bother me. Having the server and the client be a consumer of the API also means that you can build other interfaces easier (admin APIs, native apps, etc).

[@jaysistar2711]

@@chrisbiscardi Unrelated: Have you looked at wasmCloud? It might make a good video topic. NATS and HarperDB are pretty interesting as well.

[@chrisbiscardi]

@@jaysistar2711 NATS is definitely interesting. I haven't looked at wasmCloud much or HarperDB at all. HarperDB looks like the pricing is pretty brutal so I'm not sure the average person watching would even be able to run it for a side project.

[@tak68tak]

Does it support streaming HTML like Next.js 13 Server Components with suspense?

[@chrisbiscardi]

not that I know of, but fwiw NextJS doesn't even support that stably

[@driedurchin]

Window manager / OS?

[@chrisbiscardi]

yabai/macos -- kzbin.info/www/bejne/l6GoiaCAhZqrrtk

[@asdqwe4427]

Looks cool, terrible name for a framework tho

[@christianf1480]

IMO, Perseus is still a young project that needs maturation. I browsed examples in github, and code is very dependant of the perseus version, API is unstable for the moment. So each version will require hassle migration. I can't recommand it to my company. Compilation takes a lot of time, ni comparaison with sycamore alone.