Rust full stack web frameworks have a bright future
ฝัง
- เผยแพร่เมื่อ 13 ม.ค. 2024
- A look at Rust full stack web frameworks, including a comparison between the Dioxus and Leptos.
Keyboard: Glove80 - www.moergo.com/collections/gl...
Camera: Canon EOS R5 amzn.to/3CCrxzl
Monitor: Dell U4914DW 49in amzn.to/3MJV1jx
SSD for Video Editing: VectoTech Rapid 8TB amzn.to/3hXz9TM
Microphone 1: Rode NT1-A amzn.to/3vWM4gL
Microphone 2: Seinheiser 416 amzn.to/3Fkti60
Microphone Interface: Focusrite Clarett+ 2Pre amzn.to/3J5dy7S
Tripod: JOBY GorillaPod 5K amzn.to/3JaPxMA
Mouse: Razer DeathAdder amzn.to/3J9fYCf
Computer: 2021 Macbook Pro amzn.to/3J7FXtW
Lens 1: Canon RF50mm F 1.2L USM amzn.to/3qeJrX6
Lens 2: Canon RF24mm F1.8 Macro is STM Lens amzn.to/3UUs1bB
Caffeine: High Brew Cold Brew Coffee amzn.to/3hXyx0q
More Caffeine: Monster Energy Juice, Pipeline Punch amzn.to/3Czmfox
Building A Second Brain book: amzn.to/3cIShWf - วิทยาศาสตร์และเทคโนโลยี
![โอ้มายก๊อด! ไม่ถึงชั่วโมงหมดเป็นแสน 😅 [cc] แดนแพทตี้ SS2 | EP.42 |](http://i.ytimg.com/vi/OH2ShXfO6tA/mqdefault.jpg)
Thanks for bringing this to light!! will be trying them out!
Nice one, seems like dioxus are using mythrilJS format for markup
I've run into several rather critical leptos bugs, but I got them to have them all fixed so it should be pretty stable now lol. That being said, you can absolutely use leptos for a production app, you just gotta be prepared for show stopping bugs here and there and to put in the effort to report them and possibly also fix them (although the leptos maintainers are typically fixing most bugs I reported within a couple of hours or a few days).
I think the bigger issue with using Leptos or Dioxus for production development is that pre-1.0, they make no promises about major breaking changes to the code and how you use it prior to the 1.0 release. It's less about bugs and more about maintainability moving forward.
I thought you used nvim not emacs (saw Rustic in the screenshot at 3:55 and googled it).
“Discord servers with maintainers” sounds cool and all but does not help one bit the poor dev who has been stuck on an issue and cannot find the answer with their search engine of choice.
ChatGPT m8.. ChatGPT
And also, I search on both Bing and Google before I decide search engines are of no help.. At most times, found Bing to be more helpful
Leptos Discord "server" is bridged to Matrix, which can be indexed if the room settings are configured accordingly
@@newtonchutneygood luck using chatgpt for small libraries, I have problems even with huge ones like next.js
@@newtonchutneydoesn’t help when your issue caused by a bug that’s a few weeks old
Looks like Dioxis is taking inspiration from mobile development trends with frameworks like Flutter, Swift UI, and Jetpack compose.
That's great and all, but how good is web-assembly wit SEO?
Not an expert in SEO, but both Dioxus and Leptos support SSR which I understand to be key for SEO. Just need to make sure the content relevant to SEO is sent to the browser on first load as opposed to being retrieved after the initial page load
anyone who tried either leptos or dioxus, what's your experience with your compile times? have you tried them with larger codebases?
I wrote a character sheet app with many modules/components - after the first few compiles, not much has to be re-compiled. That plus the live reload feature made it so that I hardly ever had to wait on compiling, just on the browser refreshing (so not more than a couple seconds usually)
@@ZacharyHubbellCodes Thanks! I hoped that was the case. In your experience was it more like 2-3 seconds or like 9-10 seconds? (when everything is compiled and cached)
the compile times are painfully slow if you're used to build tools like vite. it's kind of comparable to using webpack. it feels ancient but it's not unbearable.
Yes, I'm using Leptos with large codebase, and it's great, trunk build compile time is not bad at all. (tho i9 12gen cpu). but trunk build --release is slow, especially with wasm-opt flags which is acceptable.
brb rewriting everything in leptos
Thanks
My problem with Dioxus is that it forces you into the React paradigm again, and they still leverage a WebView for their mobile and desktop targets. I don't like it, we need a proper React Native alternative that is truly native on all platforms, and I hope that it will not force the React-way on you.
Oof. Yikes. Yeah, I was actually just digging into this. I was intrigued when I saw Desktop and Mobile, until I realized that it's effectively just pseudo-support like an Electron app.
@@JosephDalrymple yep, back when I discovered Dioxus it looked too good to be a true and it took me a while to get what is really going on. I mean they popped up pretty fast, so it felt it can't be truly native on all platforms. Actually however, there is a true competitor to React Native that does things how I want: The Uno.Platform ... but in no life I will ever do XAML/WPF again, that was pure cancer when it comes to viewmodels, style templates and errors messages. But I have to give them probs. It's still a bit slow, but the web target renders a true DOM (instead of rendering on a canvas) and their mobile controls are native as well. It's still far from an enjoyable platform.
What exactly is "react way" I don't quite understand this phrase.
@@darshankumawat1764 There's two things that it can refer to:
1. JSX (HTML inside your code)
2. Composition-style (useState, useFoo, useBar, etc...)
@@darshankumawat1764 I think that means React's built-in state management, as opposed to more performant signal-based systems like Solid.
Any rust framework to do SSR and send HTML not WEBA?
genuinely curious why would someone use Rust over JS for the FE logic of production applications. I do get that for fun everyone can do what they want, but what's the benefit of bringing rust to the FE? One can achieve really good DX (i.e: TS) as well as performance (kv stores, CDN) - so what makes Rust a compelling choice to consider?
it's a great question! most frontends will not benefit much performance-wise from using Rust/WebAssembly. But for those that need to use WebAssembly for performance critical pieces (like Figma, Google Earth), it might make sense to just use Rust across the entire frontend instead of having a bridge between the JS and WASM.
You could make the case that writing the frontend in Rust yields better compile time static analysis that may help prevent bugs. Same benefit on the backend.
Also on the backend, using Rust will likely provide performance and memory efficiency benefits over using something like JS.
Then putting it all together - using the same language on both the frontend and the backend provides so many benefits - the ability to have server functions which automatically handle the interface between the client and server, server side rendering, no need to context switch when developing in the frontend and backend, etc.
@@codetothemoon Thanks a lot for your in depth response.
It's very interesting to see how the movement to move JS to the BE to have the same language across the stack is met with a response to move Rust to the FE for the same reasons. Communities of these languages are truly powerful and I can't help but to feel excited of what's going to come.
Thanks a lot for your effort to make these videos. You inspire me to get better and 'make better' around me.
:)
In one of the recent Dioxus talks, I heard that Eurpoean Space Agency is using Dioxus to create some web app that runs on planes. If such serious and to-the-spec kinda people are deciding on Rust despite it being pretty new, I assume the performance has to be the most critical aspect of it.
All rust needs now is faster compile times, so it will be more enjoyable.
Doesn't Dioxus have the ability to use one codebase to compile to Web, Desktop and Mobile, the creator mentioned this in one of his presentations.
Looks like Dioxus' support for Desktop and Mobile is effectively an equivalent to an Electron App. It just renders everything in a WebView. It doesn't natively support Desktop and Mobile :(
@@JosephDalrymple It's not equivalent. An electron app is written in JS, so it occupies many MB of RAM and it's slower. A Dioxus app is written in Rust, and very few JS is executed, so it occupies much less RAM and runs faster.
@@JosephDalrymple I know people keep saying it, but if you want your UI to look the same as it does on the web, then what's the point of rendering it natively and not just get away with using a WebView? Genuinely curious.
5:45 developers? I think Greg is the only active maintainer
For Leptos, Greg & Ben are both pretty active; the Leptos ecosystem crate authors are pretty active too. I tend to help onboard people and work out documentation issues more-so than the code-base..
Don't know about the status of Dioxus, though..
I like to see the HTML rather than an abstraction of it. I think I'd gravitate towards Leptos purely for that reason (disclaimer: I'm a PHP dev, not using Rust)
From my experience, I highly recommend Leptos for the following reasons:
- Leptos is fine-grained with a well designed reactive state flow, unlike dixous VDOM which is coarse-grained/component-scoped reactivity.
- Leptos pure html syntax, more vanilla and rusty.
- No scope variable.
- Stable and never run into issue.
agree with all of this, although I have a slight preference for the Dioxus DSL, I'm not sure its worth the other stuff. I wouldn't count Dioxus out quite yet though, apparently 0.5 is a huge overhaul of many things - should be interesting to see
dioxus is based on blockdom. million js was heavily inspired by blockdom. there is still a vdom but the diffing process is much faster with the blockdom pattern. if you look in js framework benchmark it actually outperforms solid and leptos in many metrics.
My stack involves using Dioxide and Rocket. Works great
is rocket still maintained?
@@ElektrykFlaaj oh yeah. They released 0.5 not too long ago
@@boohba maybe cause of the fact that rust can handle 20x requests per second more than any js runtime
@@boohba it's not a scripting language, has zero-cost abstractions and requires less memory. 20x is an exageration (depends what you do, sometimes its 100x, sometimes its 2x), but when speed actually matters for your business, nobody sane uses JS for the backend
@@boohba lol
why not Tauri which is more mature and its also even being talked in stateofjs.
Dixious tries to mimic React, but with Tauri you can use Rust as backend and frontend you can use React or Vue or Svelte
my understanding is that Tauri is only for desktop applications, right?
@@codetothemoon its for Desktop and with v.2 for mobile too
The compilation times still a problem for me on Rust, JS have a great advantage there.
I experimented before creating a fullstack framework with Yew supporting any backend, was no fun, I think just supporting one like Dioxus is better.
True that! compilation time can be a real downer in the write-test feedback loop. Re: Yew, I agree. I think it'd be really hard to justify building something with disparate frontend and backend frameworks when you have frameworks like Dioxus/Leptos that do all of the integration heavy lifting for you
I've had great compile times by turning on nightly with the new multithreaded frontend and turning on incremental compilation. Sub-5 seconds.
@@kalebburris6425 that's an improvent, I only tested on small toy projects, not sure how well it scales when you have a ton of components
@@neociber24 I've got a little over 1k lines right now, seems to scale decently.
Actually my incrementals compilations are typically sub 2 seconds depending on the scale of the change. This comp time stuff is only an issue if you have major changes or are compiling freshly.
My issue with Axum and Artix is the auto-documentation sucks. Salvo and Poem are much better choices for APIs to be honest; Manually tagging OpenAPI docs is a terrible choice (for Axum and Artix) it leads to a lot of human error.
Dioxus also supports Salvo and Warp for fullstack in addition to Axum
Hi any one will tell me i am done with rust basics, so any can help me which frame work should i learn for rust, i am thinking to start with rocket
For backend , dont use a framework for now , use a library like warp
I don’t get why they use their own syntax to create HTML elements, why would I like to learn an entire set of constraints related to their template since this would be useless somewhere else. It’s like learning how to make queries using an ORM instead of just using your knowledge in SQL.
Exactly, you still need to know html or sql and then translate it in your head
yeah that's one of the main reasons i prefer leptos over dixous. i was able to pick up leptos quickly because it feels exactly like jsx.
0:57 Not really; Blazor WASM is the pioneer of doing web app using Web Assembly. And it's leaps and bounds easier than doing it with Rust.
I’d use Rust for the frontend if the ecosystem had accessible component libraries like shadcn. Until then, I’m going to prioritize UX/dev velocity over DX/maintainability and stick with Typescript. If I need Rust performance, I’ll use WASM bindings. The harsh reality is that development in Rust is always going to be slower than Typescript, and most projects never see 1000 users.
faster in what way? not on the server, that's about 200x faster in rust. not on the client when most of these frameworks are using signals like solid. architecture is more important than language when it comes to frontend performance. the js glue performance cost is a myth.
@@stone-snare Could you repeat your question? I mean that Rust brings many pros in terms of maintainability (think monadic error handling, exhaustive pattern matching) and performance (tight loops, fine-grained algorithms) to the frontend. However, I’d argue that being able to iterate quickly is more important to the frontend in 99% of projects, and writing Rust will almost always be slower than TS.
@@AdlerWeber oh i didn't know you were referring development speed. for most js frameworks i'd agree, especially svelte and vue. for react it's debatable and even more so now with react server components.
There are accessible Web Component libraries out there which are fully compatible with Leptos/Dioxus/etc.
I really don’t understand why a DSL for HTML is seen as a pro
I personally think HTML is more verbose than necessary and this syntax is both easier to work with and easier to read. But that’s just me 😎
@@codetothemoonbut how much less verbose is this DSL? You only lose the brackets and closing tags, but any normal ide will add these for you.
The problem I have with these dsls is that they always cover not 100%. What if I want to use web components? Do I need to add something additional to the DSL?
Bro is on gun point
If the mobile was native or something like flutter type, I would have use it
I suspect this sentiment is shared by many, hopefully they have something like this on the roadmap (I haven't checked)
leptos is more readable for me.
I can definitely understand that perspective! Sometimes I'm still on the fence about which one I prefer from a readability perspective
Rust is very powerful... It makes you feel super human once you understand the syntax. It's actually interesting to write in Rust if you have the brain and a trial will convince you 🤪
4:10 - Red flag. 4:15 - Crisis averted
as long as WASM frameworks still need to go through JS to access the DOM, Rust frontend frameworks will never be able to achieve their true potential
The performance of going through the JS to access the DOM isn't much of an issue. There is some overhead to convert between the rust and JS string format, but Dioxus uses a custom binding system sledgehammer-bindgen to mitigate that issue. It has about half the overhead of wasm-bindgen for dom manipulation.
Even with the slight overhead JS adds, both dioxus and leptos are both very fast. They are both faster than (the old version) svelte and react.
Leptos is already faster than common JS frameworks in a simple app and the distance will only increase with app complexity
Did you get paid from Dioxus? :) - Iced is cooler, I looked at all the GUI frameworks. Iced is cooler. :) - just kidding... I haven’t fully figured it out myself yet, but Iced and egui are praised in public.
no, this was not sponsored. re: Iced is cooler - LOL i love it. took me a second 😎 Seriously though I've been wanting to check out Iced and egui, as you say they seem to get a lot of love from the community
@@codetothemoon Egui seems to be most peoples choice among Iced, egui and druid. The documentation for Iced is subpar.
Honestly, for a web server, I can't see myself picking Rust over Go anytime soon :)
Hard to beat the simplicity of Go, especially because it's almost as fast as Rust in a lot of cases 😎
The syntax looks ugly, not as good as in react.
that was kind of my first impression as well, but I found that when it became more familiar, this sentiment largely went away.
@@codetothemoon don't know why people try to bring spaghetti code back on this while merging server side and client side code together like the practice people commonly used in 10-15 years ago in ASP or PHP projects. It may be OK in small projects, for big projects manage those kinds of code could be painful.
Second🎉🎉 😂
lol, just no.
no it doesn't
😎
that sintax is shi
Why on earth would anyone choose to code webdev stuff with Rust. It seems really stupid.
Because debugging JS code once it's in production is a terrible dev experience, and customers hate buggy JS apps.
Rust helps you solve issues upfront, at compile time, so that bugs don't crop up unexpectedly in prod.
the funny thing is that next 14 with rscs is more complicated than rust wasm frameworks
@@bear458ziif-s lol
Because the multi-billion dollar marketing machine behind rust has convinced a bunch of people that rust is the only choice
@@steveoc64 Not true. Rust is great. A trial will convince you
Rust has been a huge success in coming up with a paradigm that literally sucks all the enjoyment out of programming
It’s a great language for ppl that don’t give a rats about computers
😛
It's all sunshines and rainbows in rust front end until you reach web_sys.
why is that?
I had a decent experience using it - I've found it to be a very helpful escape hatch for when the framework doesn't do what you're wanting
web-sys is just the dom api's in rust