ERRATA There is a mistake in the video where there is a missing parenthesis, the corrected code can be found here github.com/Me163/youtube/tree/main/RustFrontEnd
Cool video, but it might be better with a “limitations” section. Accessing the DOM, window or document is a real hassle, the rust GUI browser frameworks are not mature and the performance isn’t actually better than JS in these frameworks. I’m a huge rust fan, but wouldn’t recommend yew over react for serious projects yet.
Totally - I probably should have expanded more on this in the video. Rust on the frontend is still bleeding edge, and it's still not 100% clear that WASM DOM manipulation will get faster than JS DOM manipulation. But if the application's performance bottlenecks exist outside of DOM manipulation, it probably makes sense to at least consider Rust.
Is there any rust library/framework for gui development, not really limited to dom and web, but gui in general, like for desktpp apps, I just want to use rust and use its fastness, security and multithreading and make a blazingly fast and solid app!!
@@climatechangedoesntbargain9140 for linux and mac? Are there anything? I don't really care about windows. Also of there are, are they permant enough conpared to other methods of creating softwares...???
I'm a systems developer and I love rust for that purpose. But what I love even more is to see how this basically helps with applications that usually rely on Python, Ruby, JavaScript and so on. Although mostly not yet production ready for all of this. This really is a hell of a language. Can't wait for all these crates to mature.
Totally agree! I think it is often pigeonholed as a "systems language" and prematurely ruled out for other use cases like web frontends or REST services.
@t0prar: Agree, but using Rust only to interface with HTML and CSS is so ridiculous that it really doesn't make it shine for its real value. This is completely archaic and Neanderthal reasoning. This is a typical video from someone coming from "stack" programming and "front-end" JS cavemen mentality. Sorry, but using Rust for system development has absolutely NOTHING to do with this junk, and you know it. There is no room here for any praise, just to lament that people are still not seeing the light. Please don't encourage them to stay in the caves and to "seduce" women by hitting their head with wooden bats.
From what I understand, WASM doesn't have access to the HTML DOM and anything that wants to access the DOM, has to do so via WASM DOM API which uses JavaScript. The official Yew docs mention that "using DOM APIs from WebAssembly is still slower than calling them directly from JavaScript". This is something that they are hoping to fix in the future, so that WASM has direct access to the DOM. So for now it seems, anything that accesses the HTML DOM is being compiled into JavaScript. The only performance gain we get is the server side execution of front end functions. Anyone, feel free to correct me, as I am only 99% sure.
I believe your first 3 sentences are correct. Re: "The only performance gain we get is the server side execution of front end functions." - WASM does still run in the browser (it can run on the server too, but thats a separate video), and will be more performant than JavaScript for pretty much anything outside of DOM manipulation and network IO. Those two things are the most common bottlenecks for webapps, but for those where they are not, WASM may provide significant benefit.
But in the end the perf gains from network is not really existing, and having DOM access is a stale issue for one reason security so i Think its very unlikely it Will ever have it - but time Will tell
I Think it was @Theprimeagen that made a video, where he talked about a startup that built a webapp in rust only to gain 15% perf on top of react; compaired to how much harder it is to find developers and how much time it takes to code i dont Think there is a business case. I Think wasm should only serve as a foreign function kinda implementation. I believe that wasm have a place but js and web tech another
@@nomiscph I think in the end everything is possible, it all comes down to how WebAssembly is able to create new standards that are then hopefully implemented by all major browsers. If all parties involved in the development of WASM and browsers work together, they should be able to pull things off that we can only dream of.
@@ccriztoff Dude, where did you see any obligation? I didn't understand what you meant so I simply asked you to clarify, that's all. Of course, you are free not to. I just assume that if you take the time to comment, it means you want to say something. If you wanted to keep it to yourself, you could just watch with no interaction.
This is really cool and all, didn't expect to see a "react equivalent" in Rust. I'm betting we'll see much more like this in the future. HOWEVER, if I were to ever use wasm on a project, you best believe that project has to be something I'm so passionate I'm willing to die for it because no one in the world is going to want to maintain that code for me.
Glad you liked it! I can't speak to the maintainability of the code in the context of a larger project yet, going to try it soon and see how it goes...
This caught my attention immediately as I scrolled down my RU-vid news feed. I’m react dev and I feel like it’d be a good strategy to keep an eye on these new players in the web landscape. Rust feels weird though, but willing to shift if needed, as for now I’ll keep writing js code. Thanks, really insightful video.
Really glad you liked it! Compile-to-JS definitely remains the industry standard for now, but I'm with you in that it makes sense to explore outside the box and try to get a feel for where the industry might go in the future.
As a React diehard who's rapidly becoming a Rust lover (not that these are mutually exclusive), this blew my mind. Thank you for showing how simple yet powerful Yew can be!
First 40 seconds in and I'm impressed, great channel. Love the graphics and this is one of the few times I get to watch something that no one else is talking about, I know WASM and Rust obviously but I'd never heard of Yew
Thank you and I'm so happy you got something out of the video! I'm obsessed with getting ahead of industry trends and addressing the areas for which there isn't much content yet.
thank you! yeah lack of community made components is definitely an issue in general in the Rust frontend ecosystem. I'm hoping the better these Rust frameworks make the developer experience, the more folks come onboard and subsequently the more community made components we will have. Right now the Leptos framework is turning heads, hopefully that will bring in a new wave of developers 😎
Really great tutorial, I have been trying to learn Rust for a while now. And these kinds of tutorials were just what I needed to advance to the next step. I really appreciate it thanks a lot :)
Pretty intrigued, i’m a react dev but i’m very open to shifts in the web landscape. Last thing i’d want is to be left behind. After playing the DOOM port that was compiled to web assembly and served on the browser, i realized that this wasm thing might something to pay attention to. I’ve always written javascript, never really branched out much, so the Rust syntax looks pretty weird but there are also some similarities.
Nice! Yeah React/TS definitely has a strong foothold on the industry right now, but it's not completely inconceivable that Rust frameworks start to gain more traction soon. Re: DOOM port in the browser, this wasn't on my radar, I'm going to give it a try!
Some of the similarities can be dangerous. One of them is that the "let" statement associates a pattern on the left to a pattern on the right. It looks the same to js, but it's actually more powerful. Rust compiler also wants to do every statically. So several algorithms that work in js needs to be adapted for rust. To summarize. In javascript, if all the lines are valid operations, it will not cause any errors until you get them at runtime. In rust, the compiler wants to know exactly when memory is allocated, how it is shared, and when it is freed. If there is the possibility of a race or memory leak to happen, it will generate an error at compile. We can use unsafe blocks for these situations if it is absolutely needed though. But on the bright side. The time spent debugging rust code is a small fraction of the time spent debugging js.
I agree, and I also hope to see this ecosystem mature a bit. Biggest problem currently seems to be WASM bundle size, which can be in the megabytes for even the smallest apps...
Really good tuto. I'd love to see more of these in the future, as I am currently working on react and I feel like Rust has a potential to take over the web in some time in the future.
Thank you! Definitely more to come. I agree about the potential for Rust to become more popular for web development - i think WASM in general is going to disrupt web development far more than some folks realize.
thanks, glad you found it valuable. If you're considering Yew for a project, maybe also consider Leptos - so far I'm a big fan after testing it out a little bit.
Yeah somebody pointed this out, it's quite embarrassing. I had been calling them french braces for many years I think because I had a college professor that did so and it stuck. A quick Google search revealed that the correct term is curly braces, lol
It's not just 30 something line of code. It's code plus a whole convoluted ecosystem of tools to create a simple web app. And I'm not just bashing Yew, the entire front end ecosystem can become really convoluted very quickly. This is why I really believe a good engineer knows what to use for the job at hand. For instance, something this simple, you can do completely with either vanilla js or jQuery. I'm sure Yew has this place in the web development world but I'm not going to use it for something this simple. I still think the greatest example of showing the power of a framework and how it can incrementally be used to create a wonderful application is the rails 7.0 demonstration that dhh does. If you haven't seen that yet you should really check it out.
If the end goal was to create this app, I agree Yew (or really any frontend framework) would not be a good choice. It's presented here merely as an exercise for those new to Yew. I'll definitely check out the Rails 7.0 demo you mentioned, thanks for the recommendation!
This is convincing. I'm being drawn into the Rust cult. I was just starting Go, but it seems Rust is a better home for me. As a JS exile, I miss having an ultimate multi tool with an overly zealous userbase. I just can't deal with the slowness any more.
Thanks, glad you liked it. The smaller Rust userbase is definitely a downside, but if I had to bet, I'd wager that it will grow substantially in the next 5-10 years. Personally I consider it inevitable that it overtakes C/C++ at some point.
@@recursion. sorry I missed your response. I'll explain. I'm building an undetectable bot network that plays garbage mobile games. If you've ever seen those obscenely bad mobile games like Raid Shadow Legends or Mafia City and wondered, "who would actually play that???" the answer is that 99% of the players are bots. Don't even ask me how the game companies make money off of spending billions on getting users via paid bots. All I care about is not being poor anymore lol That being explained, my problem is this: part of being undetectable is IP address management. If you use a VPN, don't even bother trying to be undetected. VPNs are so slow you'd think it's illegal for their commercials to say they're fast. The answer is to build a national network where a node of bots is placed in a real physical location, and is programmed to get a clean IP address from the actual area it's in which prevents the server from knowing it's a bot. For example, if you're in Chicago and you route your data through a Miami IP, it'll be so consistently slow that the server will assume you're using a VPN or spoofing, but if those bots are actually in Miami, it gives the server nothing to detect as there is nothing to slow down the internet connection. Here's why JS/Python is too slow: I need these bots to do more than play videogames. I need them to factory reset themselves, connect themselves to the correct new IP address, receive commands, and use tesseract OCR to analyze the screen. As this system deals so much with networking, it made sense to design it with a local computer handling everything that needs handling. Nothing else could be faster, so for the sake of being more undetectable and the sake of saving time I need a local computer. As buying tens of thousands of androids is expensive enough, I decided controlling each node controller should be an Android phone - preferably the cheapest one possible since it'll really only be dealing with running a timer, executing android commands on the local networks, tesseract analyzation, and sending data back and forth between each node and my database caching server. This isn't something you need a strong computer for, but more bots demands more compute. I'd like to run 1 controller per 100 bots, but my original build is in Python which is way too slow even for running 10 devices. Rust is considered to be anywhere from 20-40 times faster depending on the task being measured, so Rust is perfect as it should comfortably get me over a hundred bots per controller. The reason I'm joining the Rust cult, though, isn't just due to speed. It has a dev experience that sounds incredible with the bug checking compiler, it runs on everything, and it has the versatility JS claims to have (node.js is absolute garbage for example - I only learned it because I was scared of learning another language, and that was a MISTAKE as Flask is stupid easy to get running and demands like 10% of the code). Hope that wasn't too boring.
Thank you and thanks for watching! That's a huge compliment to me, Fireship is one of my primary sources of inspiration! You can't quite see it, but I'm actually wearing a Fireship shirt in this video...
Nice! System Rust, Backend Rust, Embedded Rust, Frontend Rust.... Just need JVM Rust now so we can do Android development too. I can't say I'm enamoured with Rust's syntax... way too many unintuitive symbols.... but we'll get used to that eventually.... I love the idea of one (typesafe) language for all application areas.
Yeah, I initially found the Rust syntax off-putting. But in retrospect I think it might have been more due to my internal biases from using other languages for so long. I remember thinking that all the #s and !s looked ugly, but I think I've gotten used to them now
@water although, if I understand correctly, it's slower only with DOM manipulations. If your app performance is bound by something else (e.g. Figma is not reliant on DOM manipulations, but still quite heavy on performance), wasm should be much faster in those cases.
For anyone coding along, there is a bug in the code shown in the video: At 5:06, he mentioned to not put a semicolon in this place, but there _should_ be both a closing parentheses, then a semicolon ");" (CTTM, if you're reading this, a pinned comment would be very helpful) Another issue I encountered: If you use "rand" (version 0.8.3) as a dependency in the Cargo.toml file, you'll get the compiler error "the wasm32-unknown-unknown target is not supported by default" (I wonder if "getrandom" version 0.2.7, which appears to be installed by Trunk, causes some conflict?)
WebAssembly is not competing with JavaScript it's aiming to fill the gaps where JS falls short. For actual web UI it's actually counter-productive to use WASM - a better use-case is heavy computation like image processing which can be run async while JS runs your UI
To your point - WASM currently doesn't make DOM manipulation any faster - but whether using it is counter-productive for a UI really depends on the use case. It also doesn't seem inconceivable that it will become more compelling for DOM manipulation when WASM matures a bit and it becomes faster. It's also very possible that will never happen - it'll be fun to see what happens in the next few years.
@@codetothemoon The thing is, that Javascript is actually more than fast enough for UI development. And with typescript and a framework its easily possible to build big Webapps that serve millions of users aroumd the world. So yeah we just need to wait and see whats going to happen in the next few years.
DUDE. Editor Matt! I used to watch Matti all the time, so I'm a huge fan of your work. As you can imagine I was very confused at first about how you came across this video, but I watched your "I quit video" video and things came into focus a bit :) How has your coding journey been so far? What are you interested in and what's been your go-to stack lately?
@@codetothemoon Hahaha no way! Hope my comment didn’t come across rude 😅 just being silly. Great tutorial. I got into media / creative automation systems for an agency. I was actually building a Tauri + svelte app for work and was doing som rust research today!
Really enjoyed this. For those that might encouter some difficulties while using intellijIDEA, style.css file can be created from the 'RustFrontEnd folder' above '.idea folder'. Right-click ==> New ==> File ==> and name it 'style.css' For the bug from line 13-20, here is the correct one which worked for me let onclick = { let state = state.clone(); Callback::from(move |_| { state.set(Model { value: state.value + 1 }) }) }; goodluck all.. Let's get rusty
What really should have been explained is when you would want to use this. You could code this with Vanilla JS in like 4 lines of code (and be backwards compatible even as far as ie6) vs 30 lines in Rust (with less backwards compatibility), and I seriously doubt the performance in Rust is markedly better.
I could have done a better job covering this! If creating this counter app was the ultimate goal, we'd never need anything other than JS. Think of it as a stepping stone to larger projects where using Rust actually would provide an advantage.
I used Google translate to translate to English, but I'm still not sure I understand... This is what it gave me: "It was to fall in love, not to shoot people. You dumped it, and good. Radom is defending himself. You say it's your ex-president, but that's what everyone says."
Must give this a try, mostly use React and Node myself, but I watched a video today where the guy claims learning Rust has made him a better programmer even if he were not to continue using it.
The code as provided in the video doesn't compile lol, I wonder if that left on purpose :P These are minor things though, so easy to figure out. Thanks a lot! Really cool!
I apologize for this!!! I believe I made some corrections and then erroneously left those fixes out of the video. Sounds like you have it figured out already but you can find the completed code in my GitHub repo! github.com/Me163/youtube
I only see a missing closing parenthesis for the Callback::from function, a missing mut on the state variable and a missing semicolon for onclick. These are all things that the compiler would guide you to fix
Don't have the size of the one for this specific app on hand, but I just took a look at the one I'm currently working on (which is not much different) and it's 5.7MB. Yikes. Hopefully there's a solution for this at some point :(
Rust is cool. Maturity will come with time, but lots of neat things are being made every day. I'll stick to Go for now. But keeping Rust in mind, as it is super cool and challenges how you think about memory management.
Good question, I believe so but I haven't tried yet as I haven't created much more than small toy programs so far. Probably just a matter of getting the right extensions.
The tech is cool but when it’s about DOM manipulation i think JS will still be the king just because of the ecosystem. I know that the WASM devs are confident that WASM will be able to be at least fast as JS. I hope for more JS alternatives. Blazor from Microsoft seems to be disappointing in terms of performance. Looks very cool. Thanks for the video!
Yeah Yew doesn't appear to provide a substantial performance advantage yet for DOM manipulations yet, though from the benchmarks I've seen it seems to be in the same ballpark as React. All performance tests outside of DOM manipulation seem to favor Rust/WASM over JS though.
Wasm wasnt intended to replace js, but to work together with it. Who knows myb wasm will be a better alternative than js some day, but i doubt it with such a big js ecosystem
@@echoptic775 It depends.. Rust has pretty big ecosystem as well, albeit with different focus (atm).. if more computation-heavy logic is moved to the front-end it'll come handy and wasm will be the way to deliver that performance. IF they do bridge that wasm-dom gap in a good way in further wasm -development.. it can disrupt the status quo.
@@digitalspecter i honestly hope that happens, so many people hate working with js and nodejs, but in a lot of cases they are forced to. I also have high hopes for wasi, i think theres a lot of potential in it
glad you got something out of it! one thing I'd point out that didn't exist at the time this video was made - the Leptos framework. I now have a vast preference for it over Yew, so I'd definitely check it out if you're building a Rust frontend these days. Most of the concepts in this video still apply there
@@codetothemoon I suspect interface types can't be far off now. I think that's the big one holding back DOM access in wasm modules Also thanks for this video, it's such a great tl;dr of Yew
found a closure crate with closure! macro that let's you selectively choose to move or ref variables that are closed over (in the closure generated by the macro) - ie, don't have to move all of them if there are several - if that's an issue. Wow, this has over 100k views - must be most popular rust video to date! I wonder how many watched another rust video afterwards? (not a hit against your video, only how complex and daunting the language is - to non C/C++ devs anyways)
This crate sounds interesting - it always seemed odd to me that 'move' was an all or nothing deal. This video was sort of the channel's 'big break', I believe it had less than 100 subscribers when I posted this.
@@codetothemoon - I think Bevy is finally "catching" with the crowd, though many have Rust ahead of them. I think it will rule them all eventually, though never be as popular as Unity likely since most won't take on Rust - they simply won't. Doesn't need to be as popular though - still should have a great community.
Maybe they can embed wasmtime and get a plugin model where python / C# / javascript / java, etc devs can join the fun over here with wasm based plugins - think they could build entire games in wasm (as a wasm based bevy plugin) - you know, via WASI interfaces ... Might end up luring too many tho ..., which might not be the best for the bevy community. Not sure. OH, and it would also allow C++ devs that don't want to learn rust or aren't ready quite yet. Since most pro game devs are C++, that would be a big win I believe - though I don't know if they'd want to do game part in C++. Lua supports wasm too tho.
Right now there are a few possible justifications - (1) Preference for Rust features that compile-to-JS languages don't have, (2) Expectation that Yew will become faster than JS frameworks when WASM matures a bit, or (3) Rust is used elsewhere in the project (either on the frontend or backend) and there is a desire for language homogeny across the entire stack. Ultimately it depends heavily on the team and use case.
@@codetothemoon hard to justify writing rust on the frontend when most of the things like adding events to buttons can be done with a more elegant syntax using javascript. I can understand justification of Rust if you need performance algorithms, strongly typed code being compiled, etcs, but for small things like programming the UI it seems ( based on your tutorial ) to be a lot of extra work to make a hello world. If we get to something similar to next.js written in Rust i can start seeing it become close to a reality but now ( based solely on your tutorial ) it looks like a nice proof of concept.
Thank you for pointing this out! I had a bit of an existential crisis when my Google searches came up empty for "french braces"! I think I may have had a college professor that referred to them that way. Somewhat to my relief, the wikipedia page for "Bracket" references "French brackets" as slang for "Curly brackets". Still, it doesn't seem to be a common way to refer to them so I should probably transition to saying "Curly brackets" =X
Thank you! I *believe* you should be able to add parameters to the closure using the pipe operators immediately prior to the first french brace after "let onclick="
I'm curious as well, my understanding is that this is one of the current shortcomings of writing an entire frontend in Rust. Haven't built anything big enough to thoroughly kick the tires on this yet though.
I don't have a ton of experience with it yet, but I've had a great experience with Leptos so far. It takes a more "batteries included" approach than Yew, and if you're also building a backend to support your frontend, it should definitely be an option to consider. It eliminates a lot of the boilerplate logic you'd otherwise need to shuttle data between the frontend and the backend.
I corrected some mistakes but neglected to put those corrections in the final edit. The final version of the code can be found in my github repo, Me163/youtube. In the future I'm going to either show the mistake corrections or redo the entire recording.
This video is gold. However, I would like to know, What documentation did you use to learn on this label Rust? Could you please share the books used to learn Rust? Regards,
Are there any disadvantages for using rust instead of some JS library? I read somewhere that wasm isn't fully developed yet -- Something about modifying the DOM being slow if I remember correctly -- But it looks like rust -> WASM will definitely be a big part of the web pretty soon if it can deliver the speed and (comparably to similar higher-level languages) tiny sizes rust programs have 😯
Great question! I think one of the main disadvantages right now is the relatively small size (as compared to React) of the community around frontend Rust / Yew. From the benchmarks I've seen it looks like DOM manipulation performance is roughly on par with React at the moment, but the creator of Yew believes WASM will have a DOM manipulation performance edge once a few new WASM features are added. For most things outside of DOM manipulation, it's already reasonable to expect WASM to be faster.
@@codetothemoon Apparently, "Yes and no. The entire yew crate is included by default. But the Rust compiler and wasm-opt does tree shaking that removes most unreachable code." -- It does optimize it where it can, I'm loving rust more and more here😂
great question - I haven't personally built a large app with Yew, but my guess it would be very similar to doing so with React. Also like React, there seem to exist libraries for helping manage state akin to Redux. I haven't tried it but there is one called Yewdux
Have you had a look at Dioxus? Would love to see an example and initial thoughts, as well as how it compares to Yew. My initial impressions of Dioxus, with the rsx! syntax, is that it is definitely easier to use
@@codetothemoon i run a tech start up with a few others and as a long-term side project we're building a front-end rust framework that works similarly to svelte but in rust.
@@codetothemoon our first version for our start up will be released in a few weeks. The entire backend and database we built in rust, whilst currently the frontend is built in svelte. Keep making your vids because they’re great. Only started learning rust about 4 months ago and I love it
yeah that's an option, I can definitely see some development teams having a lint rule that disallows returning values without the "return" keyword for this reason. It's so easy to accidentally add a semicolon unintentionally.
Thanks! To your point, TS/React is probably sufficiently performant for most webapps. But there are performance critical use cases that can benefit significantly from Rust/WASM, see this testimony the Prime Video team: www.amazon.science/blog/how-prime-video-updates-its-app-for-more-than-8-000-device-types Some might also argue that Rust is preferable irrespective of any performance gain - ie just for the language itself.
idk if this was the case when the video was uploaded, but if you use a closure/fn as a prop (ie somewhere in html! tags) it automatically gets wrapped in a Callback, as per Advanced Topics/Struct Components/Callbacks Yew documentation
One thing I hate about rust is their take on returns as "no semicolon means implicit return" and most rust devs do that which makes the code harder to read because unless you're paying attention to every line end you might not notice there is a return and the fact that rust is so verbose and syntactically overwhelming at times makes it worse, reading an implicit return naturally with all that noise just doesn't come naturally to me.
I agree! I actually spent quite awhile trying to figure out why my code didn't work - it actually turned out to be because the last line of a closure had a semicolon, causing the closure to return nothing! Rust is an incredible leap forward in terms of achieving memory safety with no garbage collector, but it seems to leave out a lot of the syntactic goodness that some other modern languages have.
thanks! For benchmarks check out this krausest.github.io/js-framework-benchmark/2020/table_chrome_87.0.4280.66.html despite being called "Results for js web frameworks benchmark", it includes Yew as well
