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 caught my attention immediately as I scrolled down my TH-cam 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.
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.
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...
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!
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.
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.
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...
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!
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.
@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.
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.
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...
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
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?)
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!
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
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.
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
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.
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
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
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.
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."
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
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
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="
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,
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.
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 :(
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😂
@@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
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
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.
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
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.
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.
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.
would be good to know perhaps the version of rustc and nightly, because im getting a lot of errors. also you have an unclosed delimiter of Callback of the move function i believe.
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.
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
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.
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.
Hmm, cloning the entire state on an event doesn't seem great for an application that is or may become large. I wonder if this pattern popularized by redux is actually suitable with Rust's approach to memory management?
I grappled with this as well - we can't take ownership because state is used in the component markup, and we can't borrow a reference because we call the set function. Would love to find a better way!
@@codetothemoon I think the need of having to use state methods could actually be wrong already. Rust already compiles to assembly, so why not bring reactivity directly into the language? Chaning a variable that is used in html markup should be enough for rust to update the UI..
@@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
I'm thinking the next one is probably going to be about setting up the infrastructure (CDK, Repos, CI/CD, etc) for a full stack Rust app on AWS - ie where both the frontend and backend are written in Rust. Would you be interested in that?
@@codetothemoon In general yes, but it would be nice to not only focus on AWS! So I would prefer vendor agnostic solutions since we can't always choose the cloud provider for our projects.
I forgot the exact size, but it was much bigger than I would have liked - I believe it was in the megabytes (!). I think that is one of the biggest issues the developers of Rust frontend frameworks face today.
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.
But, what's the point of all this if at the end it's still slower then the moder js alternatives like solid/svelte ? .......although i really love the idea of wasm and like rust on a language construction level, i would still stick to js for FE and Go for BE
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.
![BOWKYLION - วิงวอน (ex-change) [Official MV]](http://i.ytimg.com/vi/cLdnZWDaO-w/mqdefault.jpg)
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.
Sycamore is faster than most JS frameworks!
@@codetothemoon It should be way faster once wasm gets native dom manipulation capabilities as opposed to having to call javascript.
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.
@@schizoidman9459 username checks out
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
Just to add, ofc if you wanna make graphic heavy application near native wasm might be it, or it could be webgpu which is behind a flag in chromium
@@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.
Your content is really great. The expertise on rust is on point. And no time is wasted.
Thank you Meizano! I strive to pack in as much value per second of watchtime as possible
I've been waiting for a video tutorial like this, thank you.
Glad it was helpful! It makes me happy to see that others are also looking for JS alternatives!
@@ccriztoff What do you mean exactly?
@@ccriztoff You can simply clarify what you mean.
@@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.
Really liked how it was quick and shows enough similarity with react, so easier to try it
Glad you liked it!!
This caught my attention immediately as I scrolled down my TH-cam 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.
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.
@@codetothemoon now you can say you have fans as far away as Zimbabwe
@@anotidaisheneilmisi904 that's incredible!! great to have you onboard. this is what I love about the TH-cam platform!
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...
Except the 5% of developers that love rust.
@ivanpetrov2435 That's 99% of all web frameworks (frontend or backend).
Macromedia ColdFusion did quite a good job tho.
@@schmoris True but it had the disadvantage that you need a specialized software for development.
Beautiful is an interesting word of choice
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!
Okay this intro is beyond amazing. Nice video. Only thing with yew is the lack of community made components.
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 :)
Awesome to hear! My goal is always to provide as much value as possible, so I love hearing that it's helped you! More to come!
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.
Rust syntax is IMHO the weirdest of mainstream,production-ready languages. I am writing this as someone who loves perl. :D
@@jdrab theres no way you think rust syntax is weirder than perl 😂 only really weird addition to common patterns is lifetime annotations
This was pretty cool, you explained all the necessary details while keeping the video short.
Thanks, glad you liked it!
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.
For a systems development language, that seems very straightforward. Hope to see future progress in this.
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...
I've watched several of your videos on the way to learning Rust. Beneficial stuff!
so happy you found them valuable! what have been the biggest pain points for you so far in learning Rust?
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!
Nice, thanks for watching!!
Awesome, simple tutorial. Will definitely need to check out more example Yew projects on your channel.
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.
these sound effects are insane 🔥
Thanks, some might say I went overboard :)
Great video. I wanna especially thank you for the font size. Thank you.
Glad you enjoyed it!
Wow! You create some high quality content. Keep going and you're going to blow up!
Thank you for the kind words. I really enjoy creating these videos, even more so when I see comments like this!
Seems like a step back compared to react. Though, I’m interested in seeing how this develops in the near future.
It's possible that you're right. It'll be interesting to see how the ecosystem develops as Yew and WebAssembly mature a bit.
Bleeding edge is a step back from a fully mature ecosystem? Umm, yeah.
how is this a step back? the rust code requires a bit more boilerplate, but that's worth it for the speed you can achieve
React is slow and bloated tho
@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.
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.
great, this was exactly what I was looking for!
image processing can be done with web workers too but of course wasm is faster
I don't know much about Web Assembly or Rust, but this tutorial was really cool ! Didn't know we could do something like this without JS 😲
Thanks, glad you liked it!
Great tutorial sir! Thumbnail made me believe it's a new Fireship video XD
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...
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
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?)
Thanks for pointing this out, I'll make a pinned comment per your suggestion!
@@codetothemoon thanks!
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!
5:56 Never heard of “French braces” before and couldn’t find anything about it. I usually just call them something like curly brackets
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
Very concise and full working WebApp....great....Yeehaa
1000 TXs for your video
Best wishes from Berlin
1000 thx for watching, thanks Chris! Love Berlin, I can't wait to go back!
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.
Are you saying js is slow? how? like what can't you do in js that rust can? newb here, just trying to understand and tia
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.
Wooowwwww 🤩 glad to be there rustian. Thanks for this video.
Thanks for watching!
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
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.
Thank you so much your instructions were so easy to follow !! This helper a lot ❤️
Nice, glad you found it valuable Rathod!
Most people won't notice a 50ms delay... No need to reinvent the wheel
Would love to see more videos like this!
Thanks, they are in the works!
This is a very nice informative video! Thank you
Thank you, it was really fun to make!
Awesome, now I'm going to learn Rust and I'm a React Developer.
Nice! Doesn't hurt to give it a try!
very good video, I was looking for 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
You deserve more subscribers!
Thank you! I really enjoy creating these videos, it makes me happy to see others finding value in them.
woaaaa, i need to try this one. it's look hard, but beautiful. 🤪
Give it a shot and let us know how it goes!
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
Since you're really into rust, you might also be interested in the proposed replacement for electron, Tauri!
I've heard of Tauri but haven't been able to dive into it yet - I'll add it to the list, thanks!
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.
Yeah imo Rust is definitely worth learning and toying with even if you don't wind up using on a project (yet). Let us know how it goes!
@@codetothemoon Thank you!
Było się zakochać a nie strzelać do ludzi. Rzuciłeś to i dobrze. Radom się broni. Mówicie że to wasz były prezydent, ale to tak wszyscy mówią.
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."
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
Awesome video! Loved the way this looks like React. gonna try it sometime.
Thanks for watching, glad you liked it! I think it's worth a try, even if you don't wind up using it.
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
You explained very beautifully. I have a question. How can we pass arguments to onclick handler?
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="
Awesome! Is there a “Next JS” equivalent for Yew?
Thanks for watching!
I haven't tried it, but maybe check out Percy which support SSR - github.com/chinedufn/percy
Loved the tutorial... Keep it up.
Thanks Umar!
Thanks for this very useful video.
thanks for watching!
Yew're great!
And CSS is really the headache part.
Haha thanks Steven! Yeah CSS gets a little crazy, I've heard TailwindCSS makes things a bit easier but I haven't tried it yet
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,
Thanks Estuardo! I mostly just used the official Rust book, and watched quite a few "Let's Get Rusty" videos.
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.
Can't go wrong with Go!
What is the size of the final wasm bundle? I only tried wasm bindgen and those bundles were quite heavy.
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 :(
Awesome video!! Love your channel
Thanks Anand! Many more to come.
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 Does including yew in your code build the whole yew package into the WASM?
good question, to be completely honest I'm not sure. I need to read more about how libraries are linked.
@@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😂
Amazing fast product :) and safe !
I agree!
Looking forward to wasm being anywhere near complete so languages like Rust and frameworks like Yew can actually be practical
Me too!
@@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
merci beaucoup a toi :))
de rien, merci d'avoir regardé !
Looks great for a simple example but when we start looking at state management for a large scale application how does it hold up?
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
Awesome tutorial! I was wondering how the onclick variable is working, even one semicolon is missing on line 20.
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.
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
this allows:
let onclick = {
let...
move || ...
}
html! { ... { onclick } ... }
or even
html! { ... onclick={ move || ... } ... }
very cool video, gets you started with the basics
also the missing close paren on line 20 was mildly off putting
glad you enjoyed it! yeah, i botched that. Find the full working code at my GitHub repo (link in the description)!
Hi Sir,
As of today; which is the best rust front end framework or which would you recommend?
Regards,
JA
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.
Great Video! But what are the pros of doing any application in Rust is this going to be much faster? I mean React with typescript is very very fast
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.
Really good tutorial. Would love to see you make something more complex.
Thanks, glad you liked it! Currently working on more complex projects, stay tuned for those videos!
This is great
Glad you liked it!
what would be the advantage over using npm and javascript? i am not really convinced by rust frontend so far...
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.
would be good to know perhaps the version of rustc and nightly, because im getting a lot of errors. also you have an unclosed delimiter of Callback of the move function i believe.
Don't forget to increase the zoom level when recording, the screen looks crazy unreadable on a phone screen
I'm curious about the bundle size and how it scales with the amount of code written. It wouldn't be worth to have a really fast app if it weights 20mb
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.
Is there websocket implementation for wasm in rust?
I haven't tried it, but there appears to be - check out the "websocket" Rust crate. Not sure if it can be used in a WASM context.
Great video!
Thanks!
great job on the video. can you compare performance to a react app?
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
Nice tutorial. It would have been nice to inspect the source of the page and check out the wasm code.
That's beautiful
Thanks! Nothing more satisfying than a button with a counter.... ;)
Incredible!
Thank you Jonathan!
Can it be debugged on VS Code?
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.
This proves that just because it can be done doesn't mean it should be done.
This reminds me of Elm. I like it… Maybe Rust is for me after all!
It's worth giving a try!
Thank you so much 😊
thanks for watching!
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.
Hmm, cloning the entire state on an event doesn't seem great for an application that is or may become large. I wonder if this pattern popularized by redux is actually suitable with Rust's approach to memory management?
I grappled with this as well - we can't take ownership because state is used in the component markup, and we can't borrow a reference because we call the set function. Would love to find a better way!
Cloning the entire state seems wasteful. Utilizing a functional programming type would be a better idea to store the state
That pattern is widely used in the elm architecture witch was a direct inspiration for this crate
@@codetothemoon I think the need of having to use state methods could actually be wrong already. Rust already compiles to assembly, so why not bring reactivity directly into the language? Chaning a variable that is used in html markup should be enough for rust to update the UI..
Thanks so much man. Legend
you're very welcome, glad you found it valuable!
@@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.
@@thelenardjourney8525 oh nice, I'd be very interested in trying that out when it's ready!
@@codetothemoon will be a little while but will let you know once it’s done for sure!
@@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
Does yew have passportJS like something? I would like to have a login screen using SSO; such as keycloak.
I'm going to make a project that combines yew+tauri+embedded rust. Wish me luck.
Nice! Please let us know how it goes!
Interesting video but you should include a benchmark if you're going to claim it's "Really fast"
check out krausest.github.io/ - though i believe the benchmarks there are biased toward DOM manipulations
Nice videos, keep it up!
Glad you enjoyed it, will do!!
@@codetothemoon what are your next topics you wanna cover?
I'm thinking the next one is probably going to be about setting up the infrastructure (CDK, Repos, CI/CD, etc) for a full stack Rust app on AWS - ie where both the frontend and backend are written in Rust. Would you be interested in that?
@@codetothemoon In general yes, but it would be nice to not only focus on AWS! So I would prefer vendor agnostic solutions since we can't always choose the cloud provider for our projects.
Is there way to ser work Rust and React together?
How can Rust help to React? Do you can imagine some context?
I haven't done it, but yes I believe you can incorporate WASM into any JavaScript based app by building JavaScript bindings for your WASM code.
Having functional component really get me back to yew. Seed macro is just confusing
yeah function components definitely eliminate a lot of boilerplate code!
How big is the compiled wasm? Bigger or smaller than stuff like react's js?
I forgot the exact size, but it was much bigger than I would have liked - I believe it was in the megabytes (!). I think that is one of the biggest issues the developers of Rust frontend frameworks face today.
smt around 300kb
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.
But, what's the point of all this if at the end it's still slower then the moder js alternatives like solid/svelte ? .......although i really love the idea of wasm and like rust on a language construction level, i would still stick to js for FE and Go for BE
5:22 why not to use return keyword and avoid any kind of stupid issues?
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.
Awesome!
Thank you! Cheers!