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.
“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.
I am excited for the 1.0 version! Dioxus seems like a lot more simpler and manageable than Leptos. On the other hand, Leptos has a lot more features and more stability.
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.
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.
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)
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.
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.
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 :(
10 หลายเดือนก่อน +3
@@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.
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.
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.
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
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.
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..
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
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.
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
@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
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.
@@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?
yeah it will be interesting to see how this plays out. I am definitely bullish on Mojo, but it has quite a bit of ground to cover in terms of ecosystem growth
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 🤪
@@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.
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.
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
![[#2024MAMA] G-DRAGON - 무제(Untitled, 2014)+POWER+HOME SWEET HOME+뱅뱅뱅+FANTASTIC BABY | Mnet 241123 방송](http://i.ytimg.com/vi/Ox29z5Nf1Uk/mqdefault.jpg)
Now I can use node in backend and rust in frontend
now that's a freaky friday!
hahahahaha! I never thought anyone would ever say that.
yo want a blazing fast frontend 🌝
lol i hate u
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.
“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
Thanks for bringing this to light!! will be trying them out!
I am excited for the 1.0 version! Dioxus seems like a lot more simpler and manageable than Leptos. On the other hand, Leptos has a lot more features and more stability.
me too, can't wait to see what they come up with!
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.
@@theycallmesloth There's two things that it can refer to:
1. JSX (HTML inside your code)
2. Composition-style (useState, useFoo, useBar, etc...)
@@theycallmesloth I think that means React's built-in state management, as opposed to more performant signal-based systems like Solid.
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.
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)
All rust needs now is faster compile times, so it will be more enjoyable.
brb rewriting everything in leptos
Looks like Dioxis is taking inspiration from mobile development trends with frameworks like Flutter, Swift UI, and Jetpack compose.
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
dioxus is very different from leptos, their main goal is to make a single framework which has wide cross-platform support
Nice one, seems like dioxus are using mythrilJS format for markup
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.
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.
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.
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.
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.
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..
dioxus is also pretty active because they are basically a startup with a well-defined team.
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
@@codetothemoon no, you can develop ios and android applications with tauri
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.
Elm lang is similar to dioxus. Based on Haskell. That is why.
Most people are more familiar with React and not Elm. Check Elm out.
I thought you used nvim not emacs (saw Rustic in the screenshot at 3:55 and googled it).
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
Any rust framework to do SSR and send HTML not WEBA?
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
Thanks
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
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?
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
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)
If mojo is a half of what they declared, there is no space for rust in llm world. unfortunately, i love rust❤
yeah it will be interesting to see how this plays out. I am definitely bullish on Mojo, but it has quite a bit of ground to cover in terms of ecosystem growth
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 🤪
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
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.
4:10 - Red flag. 4:15 - Crisis averted
Bro is on gun point
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.
no it doesn't
😎
lol, just no.
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
that sintax is shi
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
😛
Second🎉🎉 😂
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