Hey Greg, excellent video and awesome to see how good wasm already is. I would love a video on what would need to happen to make wasm faster than JS. Like go wild with what could happen, e.g wasm can manipulate dom, css, wasm spliting, ect. Intuitively, in my mind Rust should be able faster than JS as Rust is faster than JS, is there a flaw in this reasoning?
Thanks! I think we’re all trying actively to avoid framework wars etc. For example, Dioxus team just made a couple PRs to Leptos to make server functions framework agnostic, etc. It’s all just Rust, in the end…
@@gbjxc Rust community is good at this kind of collaboration, because people have a strong desire to break out common components into their own crates that consolidate the ecosystem by allowing interoperation between different crates in the same category, examples include mint, winit, etc.
@@gbjxc That is so wholesome convinced me to now learn Rust before my Systems Programming course starts next semester. Then I can use Rust instead of C or C++.
The creator of solidjs was a former co-worker of mine, and the framework we used at that company was god awfully slow, so it's pretty cool that he's created such a fast framework!
@@oxey_ this was in 2014, so it was a while ago, but yeah, pretty cool; I can remember that he was passionate about solving problems. Although my experience with that job was overshadowed by our abusive boss, though I don't need to get into that.
honestly besides the WASM vs vanillajs differences there's a LOT of information in this video, about how virtual DOM works, about various framework internals, there's the string encoding part and all your videos are like this, these really feel like a behind the scenes type video which is really cool
Maintainer of Yew here, this video was very helpful and informative. I want to clarify for any readers that the latest version had a performance regression which is fixed in git repo but it being a community maintained project, none of the maintainers have had the time to release it. I would like to have a chat about web assembly performance and improving Yew's performance, if you, Greg, or anyone else, is down for that
This is awesome to hear! I’ve done a couple small experiments with using wasm_bindgen string interning with Yew and found it dropped results in this benchmark down to the 1.48 range, which is great. I’ll open an issue to discuss when I have a little time.
As the creator of GxiRs-gxi, I am thrilled to witness developers carrying forward the idea that I had envisioned for wasm front-end frameworks. Due to time constraints, I haven't been able to devote much attention to the project myself. Nevertheless, I want to express my utmost support and enthusiasm for the ongoing progress. Kudos to all involved in the project!
Perf is one thing, the DX, the platform, and the options are another. Edge rendering, hybrid apps, RSC, sharing ts types... So much has gone into the JS ecosystem that my hesitation has been "what _else_ will I be giving up?" or "what does a full stack rust platform/stack look like?" FWIW i think lamba/edge starts for rust + using wasm in the browser could be spectacular. Like give 2-5x runway on free tiers perhaps if based on compute time! But dev productivity is an interesting angle, higher startup, lower maintenance?
After messing with Yew for a while, I came to the conclusion that a Rust WASM project will make sense if: 1. You just love Rust. 2. You do need that faster startup times (especially on the free tier thing). 3. You need predictable performance in certain scenarios. 4. You have a much more defined code structure and will not be changing. It's as you've said. JS has had so much around its ecosystem that makes it easy to prototype and overcome some of its shortcomings.
The part that I'm interested the most about rust FE frameworks is the server-side speed, you can generate pages orders of magnitude faster with rust compared to nodejs, with the bonus of everything being written in the same language, so no dealing with js for client-side. But the amount of code to transfer and the memory usage is what turns me away from using a WASM framework the same way I don't want to touch React with a stick, and that's because of mobile. Most people daily drive slow devices with unreliable mobile internet connections, which is a problem when the page they try to use takes ages to load, doesn't download properly, or just straight up crashes the browser because of high memory usage, something more common than one would expect. I really hope WASM improves and resolves the issues holding it back, so we can finally get to use another real language in webdev, besides HTML.
If you’re facing those kind of issues with any JS library even in fairly complex applications it’s most likely an implementation problem. Most popular frameworks are heavily optimized for bundling and load speed. Besides, not using js to generate pages in the server is how the web has been from the beginning, using js for that is a fairly recent thing so I think you’re going in circles here.
@@JuliaOrtiz-ti6ku The idea is that now you can do JS for both client and server side code. And since JS is not at all ergonomic, Rust tries to replace it. It's very easy to do SSR, but for client-side code Rust Wasm is not mature enough to compete with JavaScript.
so true on the wasm part for mobile. On facebook instant, the goal is to get very fast load times for games. Well, with wasm from Unity its not even possible to reach 2s load times even with an empty project (for low end mobile devices).
Man! You are cool bro! Take it to the benchmarks! Nailed the interpretation of the results. Showing immense knowledge of frontend frameworks! Wow! Keep it up!
Thanks for shedding light on some of the misconceptions about Rust and WASM! It is really cool to see there's actually not that much of a difference between vanillaJS and other Rust frameworks! What an exciting time we live in!
Ok, after days of searching and fiddling around, this video answered all of my questions. You sir, are a godsend. Was so confused with different frameworks and opinions. Thanks again!
The "hope" of WASM replacing HTML+CSS+JS altogether isn't really from the performance standpoint, it's from development standpoint. Being able to develop everything in eg. Rust, skipping all the current kinks of JS, overall reducing the overhead as well as workload, the entry barrier, pretty much everything about it would be awesome and I'd pick this any day over a traditional front end stack even if it was a bit slower initially.
Id say that’s the main reason people don’t use rust for fe actually. Far less mature and smaller ecosystem, high barrier to entry (new low level language to learn with a huge amount of things there aren’t libraries for and you’ll have to write yourself) all for a very marginal performance gain.
@D. Sherman It is not about performance gains. It’s about leveraging the knowledge you gained by writing your backend in Rust. It’s about the language Rust being miles ahead of the clusterfuck that JavaScript actually is (and TypeScript, who’s type system has so many Problems of its own..). It’s about not needing the whole JS ecosystem and just using all the libraries you are already familiar with (serde, tracing, …). It’s about having the same „if it compiles, it works“ experience when developing your frontend.
To the ecosystem. Rust was already mature enough 1 or 2 years ago. Libraries like Axum (backend) and Leptos (frontend) can be used in production without needing to write any additional libraries. To the learning curve: I would MUCH rather learn and master one single langue I love to use, instead of constantly dealing with different languages that all feel lacking in some aspects.
@@d.sherman8563 That's always gonna be the case with new languages, especially complex ones like Rust. Still, enough people are clearly on board because of all the advantages it offers. A couple years back I hadn't even heard of the language, I got into it because of the FOSS community and nowadays I see local job postings from both startups as well as established companies looking for Rust devs - I'd say this rate of adoption is relatively fast, even if you compare it with early developments of eg. Python, which only really exploded in popularity in the last 10 years or so (it's easy to forget it's much older than javascript). I agree that Rust is complex and tough to learn (so is C, Cpp, Java and many others if you want to write good code in them), but I'd say it's already mature enough for production and rising adoption in the industry proves it. And since a lot of people already write desktop apps in it and it's actually quite amazing for creating GUI's (largely thanks to the macros), being able to essentially make webapps on the fly with WASM wouldn't just be convenient, it would be a game changer for the whole industry.
This was illuminating. Thanks, Greg! I think the biggest drawback of WASM for front-end apps is iteration time. Changes you make in your code can take a bit to compile and show on the screen (and you’ll lose whatever state the app was in), whereas JS reflects them immediately. This is less important if most of your changes are to the logic and not the visuals, but otherwise, it can be a pain. Speaking of, would it be possible to somehow separate the logic from the visuals? To detect if the changes necessitate recompiling? Maybe the dev environment could have a watcher/build script that morphs the DOM instead, like Phoenix seems to?
The js frameworks basically wrap each of your components in a hot reload component that stores the props and listens for hot reload signals from the bundler system, which is tracking what modules change on the dev server then sending what changed down a websocket. The way they currently do components Rust hot reload would need some deeper hooks into the build than I believe they currently have the ability to add, not just to detect what changed but probably also to split out the user code from the framework code (at the moment you can only really have one wasm file with one memory space) - but there's definitely ways to get around this, for example separate, non Rust, components that the dev server can treat differently but a "real" build can inline (and optimize) - it's just a lot of complex work that can't reuse much.
That's exactly what Dioxus does! If you make an update only to the "component template" (the code in the rsx macro) - then Dioxus will dynamically update the DOM tree, without recompiling the whole app. Albeit it's not ideal - if you change something on the rust side in macro (like code in event handler), it will still trigger the whole app rebuild, as you need to recompile rust.
At 10:50 -ish you mention 20 characters of UTF-16 being 20kb. Would it not be 40-80 (2b to 4b encoding) bytes? Awesome video and explanation. This is the first video of yours that I've seen and I subscribed immediately.
Like the content, would appreciate if you could consider linking resources (in this case: I stopped the video and manually went to the js framework benchmark page) in the description?
My thing is it felt like the memory part was just glossed over, thats a huuuge part of the performance I care about. You mentioned it could've been a leak, but this is supposed to be a basic benchmark so what are the chances all WASM frameworks are leaking in a basic program. If I am building a big app, I really do not want to be 3x the memory footprint of svelte/solid. Is there anyway WASM will be as memory efficient? I am not just talking about the startup metric, I mean overall. Are there scenarios where GC spikes will effect JS framworks but not WASM?
Yeah let me clarify: my point here is that the way memory is being measured in the benchmark doesn’t capture the actual memory usage. I’m not sure why it changed but if you look back at older benchmarks that were taken on OSX you see the memory usage is much more comparable krausest.github.io/js-framework-benchmark/2022/table_chrome_103.0.5060.53_osx.html I don’t know why the measurement is different on later Chrome versions and/or on Windows.
There' 2 different memory models being used -- with the rust/wasm examples, it's not that more memory is being used, just that more memory is being set aside to be used. Think of two different beach parties: one where the kids go wild, soda cups get left on the ground, and you send in the garbage person the next day to tidy up; and another where there's a defined area allocated for waste disposal. It might look like a lot of space is set aside for waste in the second case, but in reality it's a lot easier to manage such a party that way than just letting everyone throw their drinks cans on the floor.
@@thirdvect0r My thing is, if my app is setting aside memory that isn't actually being used. That is still memory being taken up by my app, what I don't want is that the memory set aside is scaled alongside the actual memory being used, if its a fixed offset or just a buffer that eventually gets filled up when memory usage passes a certain point, then that's fine. So by memory usage all I am saying is that I don't want my rust app to have less memory available for other processes compared to a solid/svelte one. It doesn't really matter to me if technically speaking the rust one is actually a buffer and not the totality of actual used memory.
@@gbjxc I'm just defining memory usage as, the delta between the total memory that are available for other processes to use before/after the app is loaded. Is it measuring that? And part of that includes some allocated memory not actually being used yet? For me, even if that 's not technically being used, if other processes can't use it then it counts as memory being used. Or is the memory usage just totally off and completely unrelated to real world memory metrics? I am curious why the windows results are so different than the OSX ones though.
Web isn't used for it's performance. The reason web and performance is mentioned in the same sentence is because we need to find ways to mitigate all the performance challenges web has. Working on a large scale 3D multiplatform renderer the discussion about "fast" JS frameworks is quite silly. In our comparisons it's just a matter of "not that much slower" (ie: at least we're not counting orders of magnitude), "dead slow" (orders of magnitude) and "won't even run" (usually because of lack of/bad memory/resource management).
Your writing makes no sense. Nobody argued: let's go web, because it's so fast. Point is, if you want to collaborate in real time (if it is work, or gaming, or whatever) over distance, you need something like the web. And than performance matters, even 10th of seconds. You don't think so? Try to enjoy a movie with delayed sound.
@@frankszander2761 Uhm, you say that nobody says this, and then in the next sentence _you_ say it! Or what do you interpret as "The Web"?! I happen to write a collaborative app framework, and yes, over a distance, and NO, web is NOT something I need, because I don't need more problems. In the performance world I live in, fractions of milliseconds matter (that is fractions of 1/1000's of a second), and having to live in a VM with random stalls and no guarantees about timing is not ideal if you expect do do anything realtime.
@@brynyard Well, the clip is about WebAssembly and FWs to build Webpages. And no. I said people use the web because that is the common (and for some the only) way to collaborate over a distance and not because of the performance.
@@fadichamieh The most important is absence of pointer arithmetic in principle. You don't need to check something that not exists. And there are a lot of task where security prevails over performance
The perfomance of wasm wasn't an issue for me as a frontend developer. It's the ecosystem behind framework. Frontend is not just interactivity (do smth on btn click). What about css support inside thoseframeworks? It's a big pain to even setup windi/tailwindcss properly. I have to use vite to bundle all my app (i know about rust alternatives they just very raw). What about animation capabilities? All those stuff matter and it's really sad to see that most of these frameworks are focused only on rendering perfomance. Yeah it's good. What's next?
that looks like a good choice for something that has to do a lot of state changes purely on the client side without any server interaction. will be interesting to see what will happen once DOM modification directly from WASM is possible. i'm not too sure though how this would work out for low-frequency state updates with a roundtrip to the server ... might well be that minimal js and server-side rendering (e.g. actix-web + sailfish + htmx) would outperform here. for sure for the loading performance, but maybe also for rendering. browsers are extremely fast on html processing. obviously, your changed DOM causes html processing in the browser as well, but i talk about processing/diffing larger chunks as it would happen if the whole table got replaced by a server roundtrip.
29:00 why wouldn't you use Leptos for an e-commerce? Stability? Or an e-commerce would need the best performance all-around, hence something like SolidJS would be better? Or for other reasons? BTW your content is great, thank you!
Imho, the real tradeoff at this point is Rust vs Typescript frontend ecosystem. Overall I am really interested in Dioxus' rendering approach, since I also think it also works better for native backends where the cost of repainting rectangles isn't hidden away behind the DOM abstraction, and there is a lot of potential to optimize the rendering backends there. But of course at the same time the state management part of the react model is quite clunky, and signals or something similar is a great way to separate the rendering tree from the state tree. Imho, meshing Dioxus' approach with Vue's state management model is very promising. With that said, imho I would really have loved to see how logic programming languages would do for GUIs, and wasm is a promising platform to host other scripting languages than JS (speed is no longer the goal here). The main reason is that logic programming languages is probably the single best way to make two-way data binding work.
I got confused about Yew vs wasm-bindgen, in these benchmarks are they "competing" or are they used together? I saw that Yew also uses wasm-bindgen, but wasm-bindgen scores better in the table, does that mean I can make a front-end using just wasm-bindgen without Yew and it will perform better?
Great overview, and I really like the deep dive into why the differences seen are there, as well as the context of what it all means. As a developer who primarily works in back-end or automation, I'm unfamiliar with the constraints of front-end work. Is it possible to get sub-second interactive page loads, or are we doomed to the 1.8s interactivity floor you showed in the chart? I know 1.8s is still "fast" by most standards, as the teams I help are often pushing 5-10 seconds before interactive, but the dream of a desktop-equivalent experience is that everything feels real-time without delay.
is there a benchmark using a large, real life like project - say twitter like - that compares the load time and bundle sizes for leptos and javascript libraries? how does it "really" compare?
i know that airbus uses dioxus on their commercial planes. a lot of it is dependent on the specific project. twitter could be feasible, but it wouldn't make as much sense. wasm suffers the most with creation and i imagine twitter would have more than normal creation costs. apps like facebook, instagram, gmail, slack, etc, would make much more sense. the bundle might be larger with wasm, but it's also streamed into the browser which offsets some of that. time to interactive isn't an issue regardless just because of progressive enhancement. the main benefit of full stack wasm frameworks is server side performance.
can we have hybrid model like micro frontends.. so that on a large team some can focus on high performant wasm based framework on some critical viewsand other in react/vue..
What I don't get is why all of the performance metrics seem to be around accessing the dom instead of just equivalent graphical effects entirely in wasm, have I just entirely misunderstood wasm itself?
I am here because I am the maintainer of a web-app that at some point has do display interactive charts and maps that handle larges amounts of data. The frontend post-processing and the many abstraction layers of Plotly (and mapboxgl) are causing a huge slowdown and everything gets laggy. I am searching for alternatives of how I could perform faster post-processing (I already did my best with JavaScript) and GIS/Plotting. Do you gentlemen and women and anything in between have any suggestions?
Just a silly question. You said - "The main constraint is not actually the ability to call DOM apis from WA but the cost of copying strings from WA to JS". But then you at 10:00 say that - "creation ....where you have to generate a whole bunch of strings and ship them in to the DOM". So the constraints is actually accessing the DOM or transferring those strings from rust -> WA-> JS -> DOM. So if WA is able to access the DOM directly, wouldn't it be faster?
Good question. Here’s a rephrase: What’s expensive is not the action of calling a DOM method from WASM via JS, it’s the cost of copying and reencoding a string argument. Direct DOM access or the WASM stringref proposal should remove the need to copy which would be great. I suspect reencoding to UTF-16 would still be necessary but I’m far from an expert. So yeah it should be a win but maybe not 100% of the difference!
I wouldn't pick rust over javascript for effeciency. I don't think we need better performance on the web today, but more statical typing and robustness, while keeping the access to web development pretty easy. The goal to me is to find a way so that with very little knowledge we can't mess up code and create invisible bugs, incoherent dependencies, while at the same time it shouldn't be very hard to develop a good web application. Rust looks a like a very good language for that, thank you guys for the frameworks you're developping!
There is no need to "access the DOM directly" for WASM, because it's not what it was created for. But I still don't understand why to move HTML code into Rust if it doesn't make any performance difference - for an experiment? For fun? Or for something else?
Simple: 1) It’s a language I’d much rather be writing than JavaScript, in which I can express myself better and create fewer bugs 2) It performs much better on the server than JS, and writing single-language apps on the whole stack is great.
@@gbjxc You could have said from the beginning that you don't like JS and you just want to write in another language 🤣 Create less bugs? How about to use typescript instead?
How many more lines does it add compared to the equivalent javascript? Like how much tinier is the delivered website? And how much more convoluted will the implementation be?
How did you set your text editor line numbering (in vim I assume)? That way of showing the line you are on and then the relative distance from that line is a brilliant move that I never thought of until this moment.
I’m a total nvim newb and copied my whole config from ThePrimeagen pretty much :-) the term here is “relative line numbers” I think. Super great for your j and k navigations
Using the link in the description I cannot see Sledghammer in the benchmarks. I also can't find it in the git repository. Is there a fork that includes the rust frameworks?
I think currently the dev experience of Rust in the frontend compared with frameworks like Svelte or Vue, is very bad. And that's pretty important too: Run time vs Code time. I think in the near future we'll see devs migrating to WASM but there is still a lot of work to do to compare JS experience with Rust in the frontend. Thanks for this helpful information!
development experience is subjective. from a maturity standpoint it's not there. as far as writing code, i personally find it to have better dx. it's easier to start a project with js but gets harder as it grows. rust is the exact opposite where it's harder to start a project but gets easier as it grows. there are trade offs to both so it depends on the app you are intending to build.
@@eyz-4I think is not subjective when you can write less boilerplate and code in general so write a very simple component. Do you think a framework like Svelte or Vue scale worse than another Rust web framework? No way...
@@SilvestreVivo there's less boilerplate/code in leptos than react or vue. svelte has the least but svelte is it's own language which makes that possible. leptos is just a clone of solid js/solidstart in rust. the leptos server api is also much simpler to implement than kit, nuxt, and next.
@@eyz-4This confirms me that Svelte is sill easier that any web framework in Rust. That was my point. Maybe in the near feature will be different but not currently.
@@SilvestreVivo yes but svelte is not javascript. it's a completely different language that has it's own compiler. it has such great dx because it's not javascript. solid has comparable dx to svelte and rust has better dx than js. even then svelte is not a completely sure thing for every project. the server api as i said is very confusing compared to the leptos server api. you don't get the type safety and other features that the rust language offers. on top of that leptos is faster on the client and server by a significant margin so you get performance advantages. there are trade offs to both so it comes down to the project and what you're intending to do.
It’s a good question - That may be a possible micro-optimization, but the issue is that the Rust String type is defined as UTF-8 so you either lose the *whole* ecosystem for working with strings in Rust, or pay the (relatively small?) performance cost. Certainly framework architecture ends up swamping the string cost, because Leptos/Dioxus are faster than Svelte/Vue/Preact etc simply because of our architectural choices.
@@gbjxc Wow, I was not expecting a direct response from the creator a leptos-rs himself 😂. Primeagen is always hyping up what a cool tool this is. It probably would be more trouble than it was wroth, but I didn't know if you could use utf-16 strings for a subset of operations like accessing dom nodes as you mentioned earlier, and only perform the conversion when you needed the full power of the rust ecosystem.
What exactly is javascript string interop? My editor saves javascript files in utf-8. Does that mean that the js engine converts my js files, saved in utf-8, to utf-16 before executing?
He is referring to the Javascript runtime string representation. So not the type of your input file but the types used in the language itself. If you take a JS string in memory and look at it the representation it is not comparable with ascii or utf-8.
@@dynfoxx Thanks for the clarification. Since it's an internal representation, it could be converted to utf-8 without breaking javascript programs? All internal handling of strings would also need re-tooling to deal with utf-8, I assume. Would there be a benefit and or downside to any other interested parties?
@@richardgeddes630 I'm not 100% sure what you are asking and I don't know the answer for sure. Basicly I belive the standard says all internal strings must be UTF-16 or there is a requirement that makes it inconvenient to use any other standard. It would be basically impossible to change at this point.
Hello I'm actually new at web development. Is leptos good for seo if I dont use SSR? I actually want to make an lms marketplace for that I thought of using actix for the backend, so I thought, why not to go for front-end written in Rust. I dont want to learn two languages like JavaScript and then rust, just wanna stick with Rust so here I am. So is Leptos hood for SEO? Also does it support static site generation?
Super interesting! As a frontend dev mostly working with vue, it’s so weird to me that it’s always dismissed so easily especially with it’s insane performance even though it is using v-Dom and it’s great community and easy to use api. Once vue 3 has vapor mode it should be on par with solid performance wise.
I think some people are simply jaded. It's like with Java, modern Java is amazing, but people remember the Java 1.5 days where doing just about anything sucked and younger developers haven't tried Java and just listen to the jaded seniors. Vue is probably in a similar situation.
@toast I am working on a large project with vue and can’t complain. Vue 3 is awesome and has super easy to use APIs, the script setup syntax is basically identical to how svelte handles JS, vue 3 was completely written in typescript so that is also covered and the composition API and the ability to outsource logic into dedicated, statefull, TS modules is an amazing feature. I haven’t really worked with svelte a lot so I can’t compare the two fairly, but I can say that DX in vue 3 is first class!
As someone happily running a 2011 CPU with the RAM maxed out to 32GiB for everything except web apps (I have a separate gaming rig I'm quite happy with... it's a hand-me-down of similar age with 8GiB of RAM and a Radeon HD 5870 from 2009), I'd say that WEB APPS IN GENERAL aren't ready for prime time, regardless of what they're written in. When normal "a few open tabs and a RUclips video at 480p" web browsing doesn't reliably maintain better P99 janklessness than games like Superliminal or A Hat In Time, something's wrong.
I like the video, I might try some WASM on my portfolio. I agree that bigger applications might require a little more thought, the part that scares me the most is the size of the bundle, i hope WASM gets a code splitting feature, if they do, then its done. Greg I'd love to know why rust based frameworks were taking memory on startup even though they might not use it? Is it something rust related? I'm new to rust, I'm still reading the book and doing the rustlings course.
One silver lining of wasm's generally-larger bundle size, is that wasm parsing can be streamed, so by the time the file is done downloading, it's pretty much already parsed and ready to execute. Contrariwise, JS files can't be parsed until they're fully downloaded (AIUI), and that parsing cost is larger for JS due to complex text syntax's disadvantages vs wasm's compact binary format. But still, I agree that code splitting should be made a lot easier. Right now, you have to create multiple wasm by hand and they can only communicate through JS. I don't know of any alternative to that at the moment.
@@climatechangedoesntbargain9140 I believe the answer to that is no, everything has to be downloaded before it's ready to run. The browser can parse as the file is downloading, however, so it should be ready to go almost immediately after the last byte is received. I think JavaScript has to download the file completely before it can even begin parsing. The difference here comes from the fact that wasm is a binary format much closer to machine code, requiring the browser to do a lot less translating.
@@Andrew-jh2bn yeah, but you can load JS incrementally, so it can run before everything is loaded, even though the inidivudal files have to be completely loaded before parsing.
Am i misunderstanding something? You said the problem is not WASM not being able to call browser APIs directly but copying of strings to JS. That copying is done because you can't call browser APIs directly, right? So it completely invalidates the previous sentence. Is there something i am not getting?
I don’t why there is even this much of a discussion about performance, to me it was clear from the beginning, if react is fast enough, and its more than fast enough really, then pretty much everything else will also be fast enough. The speed of ui rendering is almost never a bottleneck on user experience anyways.
probably the only thing is 3d engines, they don't access to DOM but use many cpu resources in calculations, but i don't think wasm can help with gpu calculations performance.
My excitement for wasm isn't so much wasm, but rather that you can run combined code ( be it Rust or good old C ) in a browser witch today basically runs everywhere and to me that sounds awful lot like compile once run everywhere and you are also no longer bound to do web client side in JavaScript which likes to pull your hair out so JS being just a smidge faster then properly typed language is not much of concern for me.
Optimizing web apps in the 0.% to save milli seconds ... then Marketing comes in and adds 4MB of tracking and other stuff that blots the apps performance 1000x ^_^
Sorry for the super small text! I forgot to bump it up in the terminal, but it's not a coding-focused video so hopefully it doesn't ruin it for you!
@@DavidChoiProgrammer Somebody buy me a time machine and I'll make as many videos as you want :-D
@@gbjxc hopefully Elon will build one for us using Rust
@@gbjxc on my way 😂🌌
Hey Greg, excellent video and awesome to see how good wasm already is. I would love a video on what would need to happen to make wasm faster than JS. Like go wild with what could happen, e.g wasm can manipulate dom, css, wasm spliting, ect. Intuitively, in my mind Rust should be able faster than JS as Rust is faster than JS, is there a flaw in this reasoning?
How fat a wasm library is? Last time I checked, a wasm hello world example was megabytes fat
I appreciated the way you talked about the entire ecosystem in a positive and uplifting or factual way here
Thanks! I think we’re all trying actively to avoid framework wars etc. For example, Dioxus team just made a couple PRs to Leptos to make server functions framework agnostic, etc. It’s all just Rust, in the end…
@@gbjxc Rust community is good at this kind of collaboration, because people have a strong desire to break out common components into their own crates that consolidate the ecosystem by allowing interoperation between different crates in the same category, examples include mint, winit, etc.
@@gbjxc That is so wholesome convinced me to now learn Rust before my Systems Programming course starts next semester. Then I can use Rust instead of C or C++.
The creator of solidjs was a former co-worker of mine, and the framework we used at that company was god awfully slow, so it's pretty cool that he's created such a fast framework!
in interviews and such he always seems like a cool guy, what's he like to work with?
@@oxey_ this was in 2014, so it was a while ago, but yeah, pretty cool; I can remember that he was passionate about solving problems. Although my experience with that job was overshadowed by our abusive boss, though I don't need to get into that.
working with awful code has been one of the main drivers for writing reusable solutions for me
honestly besides the WASM vs vanillajs differences there's a LOT of information in this video, about how virtual DOM works, about various framework internals, there's the string encoding part and all your videos are like this, these really feel like a behind the scenes type video which is really cool
Maintainer of Yew here, this video was very helpful and informative. I want to clarify for any readers that the latest version had a performance regression which is fixed in git repo but it being a community maintained project, none of the maintainers have had the time to release it.
I would like to have a chat about web assembly performance and improving Yew's performance, if you, Greg, or anyone else, is down for that
This is awesome to hear! I’ve done a couple small experiments with using wasm_bindgen string interning with Yew and found it dropped results in this benchmark down to the 1.48 range, which is great. I’ll open an issue to discuss when I have a little time.
(Just posted some stuff in the Yew discord assuming you're hamza1311 in there)
great to see this collaborative spirit guys...
Maybe it was unintentional but, I learned so much from this presentation that you earned yourself a subscriber.
Thank you SO much man for how you've done the introduction! I wish more people did this "gist-of-the-video" type of intros, it saves so much time!
Really well formulated video. As a react dev interested in moving to wasm, this was a perfect intro into the space
As the creator of GxiRs-gxi, I am thrilled to witness developers carrying forward the idea that I had envisioned for wasm front-end frameworks. Due to time constraints, I haven't been able to devote much attention to the project myself. Nevertheless, I want to express my utmost support and enthusiasm for the ongoing progress. Kudos to all involved in the project!
Greg, I highly appreciate your content. I already compared the table back in the days but I love your thoughts and opinions.
Thanks, that's really kind!
Continuing to enjoy the organization, clarity, and focus your videos. Keep up the great work!
Perf is one thing, the DX, the platform, and the options are another. Edge rendering, hybrid apps, RSC, sharing ts types... So much has gone into the JS ecosystem that my hesitation has been "what _else_ will I be giving up?" or "what does a full stack rust platform/stack look like?"
FWIW i think lamba/edge starts for rust + using wasm in the browser could be spectacular. Like give 2-5x runway on free tiers perhaps if based on compute time!
But dev productivity is an interesting angle, higher startup, lower maintenance?
After messing with Yew for a while, I came to the conclusion that a Rust WASM project will make sense if:
1. You just love Rust.
2. You do need that faster startup times (especially on the free tier thing).
3. You need predictable performance in certain scenarios.
4. You have a much more defined code structure and will not be changing.
It's as you've said.
JS has had so much around its ecosystem that makes it easy to prototype and overcome some of its shortcomings.
The part that I'm interested the most about rust FE frameworks is the server-side speed, you can generate pages orders of magnitude faster with rust compared to nodejs, with the bonus of everything being written in the same language, so no dealing with js for client-side. But the amount of code to transfer and the memory usage is what turns me away from using a WASM framework the same way I don't want to touch React with a stick, and that's because of mobile. Most people daily drive slow devices with unreliable mobile internet connections, which is a problem when the page they try to use takes ages to load, doesn't download properly, or just straight up crashes the browser because of high memory usage, something more common than one would expect.
I really hope WASM improves and resolves the issues holding it back, so we can finally get to use another real language in webdev, besides HTML.
If you’re facing those kind of issues with any JS library even in fairly complex applications it’s most likely an implementation problem. Most popular frameworks are heavily optimized for bundling and load speed. Besides, not using js to generate pages in the server is how the web has been from the beginning, using js for that is a fairly recent thing so I think you’re going in circles here.
@@JuliaOrtiz-ti6ku The idea is that now you can do JS for both client and server side code. And since JS is not at all ergonomic, Rust tries to replace it. It's very easy to do SSR, but for client-side code Rust Wasm is not mature enough to compete with JavaScript.
so true on the wasm part for mobile. On facebook instant, the goal is to get very fast load times for games. Well, with wasm from Unity its not even possible to reach 2s load times even with an empty project (for low end mobile devices).
Man! You are cool bro! Take it to the benchmarks! Nailed the interpretation of the results. Showing immense knowledge of frontend frameworks! Wow! Keep it up!
Such an informative video man. I really enjoyed the behind the scenes explanations from an expert like yourself :)
Thanks for shedding light on some of the misconceptions about Rust and WASM! It is really cool to see there's actually not that much of a difference between vanillaJS and other Rust frameworks! What an exciting time we live in!
Ok, after days of searching and fiddling around, this video answered all of my questions. You sir, are a godsend. Was so confused with different frameworks and opinions. Thanks again!
The "hope" of WASM replacing HTML+CSS+JS altogether isn't really from the performance standpoint, it's from development standpoint. Being able to develop everything in eg. Rust, skipping all the current kinks of JS, overall reducing the overhead as well as workload, the entry barrier, pretty much everything about it would be awesome and I'd pick this any day over a traditional front end stack even if it was a bit slower initially.
And yeah, I know doing this is not the original/current "point" of WASM, but hey, one can only hope...
Id say that’s the main reason people don’t use rust for fe actually. Far less mature and smaller ecosystem, high barrier to entry (new low level language to learn with a huge amount of things there aren’t libraries for and you’ll have to write yourself) all for a very marginal performance gain.
@D. Sherman It is not about performance gains. It’s about leveraging the knowledge you gained by writing your backend in Rust. It’s about the language Rust being miles ahead of the clusterfuck that JavaScript actually is (and TypeScript, who’s type system has so many Problems of its own..). It’s about not needing the whole JS ecosystem and just using all the libraries you are already familiar with (serde, tracing, …). It’s about having the same „if it compiles, it works“ experience when developing your frontend.
To the ecosystem. Rust was already mature enough 1 or 2 years ago. Libraries like Axum (backend) and Leptos (frontend) can be used in production without needing to write any additional libraries.
To the learning curve: I would MUCH rather learn and master one single langue I love to use, instead of constantly dealing with different languages that all feel lacking in some aspects.
@@d.sherman8563 That's always gonna be the case with new languages, especially complex ones like Rust. Still, enough people are clearly on board because of all the advantages it offers. A couple years back I hadn't even heard of the language, I got into it because of the FOSS community and nowadays I see local job postings from both startups as well as established companies looking for Rust devs - I'd say this rate of adoption is relatively fast, even if you compare it with early developments of eg. Python, which only really exploded in popularity in the last 10 years or so (it's easy to forget it's much older than javascript). I agree that Rust is complex and tough to learn (so is C, Cpp, Java and many others if you want to write good code in them), but I'd say it's already mature enough for production and rising adoption in the industry proves it. And since a lot of people already write desktop apps in it and it's actually quite amazing for creating GUI's (largely thanks to the macros), being able to essentially make webapps on the fly with WASM wouldn't just be convenient, it would be a game changer for the whole industry.
There should be a conference of all lead devs of the frameworks of this benchmark. I am in!
great vid! loved the passionate narrating, half an hour worth spent :p
This was illuminating. Thanks, Greg!
I think the biggest drawback of WASM for front-end apps is iteration time. Changes you make in your code can take a bit to compile and show on the screen (and you’ll lose whatever state the app was in), whereas JS reflects them immediately. This is less important if most of your changes are to the logic and not the visuals, but otherwise, it can be a pain.
Speaking of, would it be possible to somehow separate the logic from the visuals? To detect if the changes necessitate recompiling? Maybe the dev environment could have a watcher/build script that morphs the DOM instead, like Phoenix seems to?
In JS the Vite do a fantastic job!
The js frameworks basically wrap each of your components in a hot reload component that stores the props and listens for hot reload signals from the bundler system, which is tracking what modules change on the dev server then sending what changed down a websocket.
The way they currently do components Rust hot reload would need some deeper hooks into the build than I believe they currently have the ability to add, not just to detect what changed but probably also to split out the user code from the framework code (at the moment you can only really have one wasm file with one memory space) - but there's definitely ways to get around this, for example separate, non Rust, components that the dev server can treat differently but a "real" build can inline (and optimize) - it's just a lot of complex work that can't reuse much.
That's exactly what Dioxus does! If you make an update only to the "component template" (the code in the rsx macro) - then Dioxus will dynamically update the DOM tree, without recompiling the whole app.
Albeit it's not ideal - if you change something on the rust side in macro (like code in event handler), it will still trigger the whole app rebuild, as you need to recompile rust.
This was incredibly helpful to understand the differences between these frameworks. Thank you
At 10:50 -ish you mention 20 characters of UTF-16 being 20kb. Would it not be 40-80 (2b to 4b encoding) bytes?
Awesome video and explanation. This is the first video of yours that I've seen and I subscribed immediately.
Very informative. Thank you for your work on this video.
18:40 - Surely yew could do this too? Or is there a technical reason why these performance improvements couldn't be added to yew?
Great video, very informative and you have a great character and spirit!
Like the content, would appreciate if you could consider linking resources (in this case: I stopped the video and manually went to the js framework benchmark page) in the description?
Really interesting comparison. Thanks!
Really insightful video. Definitely going to consider wasm for my next project now
Great video! Just found your channel. Looks awesome 🙌🏾
Awesome overview, thanks for the video😁
Wee need this. Keep up the good work 👍
The man! Glad to find you.
My thing is it felt like the memory part was just glossed over, thats a huuuge part of the performance I care about. You mentioned it could've been a leak, but this is supposed to be a basic benchmark so what are the chances all WASM frameworks are leaking in a basic program. If I am building a big app, I really do not want to be 3x the memory footprint of svelte/solid. Is there anyway WASM will be as memory efficient? I am not just talking about the startup metric, I mean overall. Are there scenarios where GC spikes will effect JS framworks but not WASM?
Yeah let me clarify: my point here is that the way memory is being measured in the benchmark doesn’t capture the actual memory usage. I’m not sure why it changed but if you look back at older benchmarks that were taken on OSX you see the memory usage is much more comparable krausest.github.io/js-framework-benchmark/2022/table_chrome_103.0.5060.53_osx.html I don’t know why the measurement is different on later Chrome versions and/or on Windows.
There' 2 different memory models being used -- with the rust/wasm examples, it's not that more memory is being used, just that more memory is being set aside to be used. Think of two different beach parties: one where the kids go wild, soda cups get left on the ground, and you send in the garbage person the next day to tidy up; and another where there's a defined area allocated for waste disposal. It might look like a lot of space is set aside for waste in the second case, but in reality it's a lot easier to manage such a party that way than just letting everyone throw their drinks cans on the floor.
@@thirdvect0r My thing is, if my app is setting aside memory that isn't actually being used. That is still memory being taken up by my app, what I don't want is that the memory set aside is scaled alongside the actual memory being used, if its a fixed offset or just a buffer that eventually gets filled up when memory usage passes a certain point, then that's fine. So by memory usage all I am saying is that I don't want my rust app to have less memory available for other processes compared to a solid/svelte one. It doesn't really matter to me if technically speaking the rust one is actually a buffer and not the totality of actual used memory.
@@gbjxc I'm just defining memory usage as, the delta between the total memory that are available for other processes to use before/after the app is loaded. Is it measuring that? And part of that includes some allocated memory not actually being used yet? For me, even if that 's not technically being used, if other processes can't use it then it counts as memory being used. Or is the memory usage just totally off and completely unrelated to real world memory metrics? I am curious why the windows results are so different than the OSX ones though.
In my eyes memory usage is way more important of a factor than speed
Web isn't used for it's performance. The reason web and performance is mentioned in the same sentence is because we need to find ways to mitigate all the performance challenges web has. Working on a large scale 3D multiplatform renderer the discussion about "fast" JS frameworks is quite silly. In our comparisons it's just a matter of "not that much slower" (ie: at least we're not counting orders of magnitude), "dead slow" (orders of magnitude) and "won't even run" (usually because of lack of/bad memory/resource management).
Your writing makes no sense. Nobody argued: let's go web, because it's so fast. Point is, if you want to collaborate in real time (if it is work, or gaming, or whatever) over distance, you need something like the web. And than performance matters, even 10th of seconds. You don't think so? Try to enjoy a movie with delayed sound.
@@frankszander2761 Uhm, you say that nobody says this, and then in the next sentence _you_ say it! Or what do you interpret as "The Web"?!
I happen to write a collaborative app framework, and yes, over a distance, and NO, web is NOT something I need, because I don't need more problems. In the performance world I live in, fractions of milliseconds matter (that is fractions of 1/1000's of a second), and having to live in a VM with random stalls and no guarantees about timing is not ideal if you expect do do anything realtime.
@@brynyard Well, the clip is about WebAssembly and FWs to build Webpages. And no. I said people use the web because that is the common (and for some the only) way to collaborate over a distance and not because of the performance.
Hey Greg, Loved the video , Just one quick question, I am lactose intolerant can I use Leptos?
100% dairy-free baby
I don't understand the question. Leptos isn't something you eat or drink. It's a web framework.
@@31redorange08 oh dude
It's very possible that WASM will be more popular in serverside than in browser.
WASM-containers are really interesting
IMHO WebAssembly carries the potential to break all system / hardware specific limitations and should allow true reusable code for so many use cases!
@@fadichamieh The most important is absence of pointer arithmetic in principle.
You don't need to check something that not exists.
And there are a lot of task where security prevails over performance
The perfomance of wasm wasn't an issue for me as a frontend developer. It's the ecosystem behind framework. Frontend is not just interactivity (do smth on btn click). What about css support inside thoseframeworks? It's a big pain to even setup windi/tailwindcss properly. I have to use vite to bundle all my app (i know about rust alternatives they just very raw). What about animation capabilities? All those stuff matter and it's really sad to see that most of these frameworks are focused only on rendering perfomance. Yeah it's good. What's next?
Forgot to say thank you for video. Very helpful and interesting
Love your presentation!
Super interesting video, very informative. Thanks!
This is great content, learnt a lot from this!
that looks like a good choice for something that has to do a lot of state changes purely on the client side without any server interaction. will be interesting to see what will happen once DOM modification directly from WASM is possible. i'm not too sure though how this would work out for low-frequency state updates with a roundtrip to the server ... might well be that minimal js and server-side rendering (e.g. actix-web + sailfish + htmx) would outperform here. for sure for the loading performance, but maybe also for rendering. browsers are extremely fast on html processing. obviously, your changed DOM causes html processing in the browser as well, but i talk about processing/diffing larger chunks as it would happen if the whole table got replaced by a server roundtrip.
that was actually pretty interesting indeed ! thanks
Such a great and informative video!
29:00 why wouldn't you use Leptos for an e-commerce? Stability? Or an e-commerce would need the best performance all-around, hence something like SolidJS would be better? Or for other reasons?
BTW your content is great, thank you!
Imho, the real tradeoff at this point is Rust vs Typescript frontend ecosystem.
Overall I am really interested in Dioxus' rendering approach, since I also think it also works better for native backends where the cost of repainting rectangles isn't hidden away behind the DOM abstraction, and there is a lot of potential to optimize the rendering backends there. But of course at the same time the state management part of the react model is quite clunky, and signals or something similar is a great way to separate the rendering tree from the state tree. Imho, meshing Dioxus' approach with Vue's state management model is very promising.
With that said, imho I would really have loved to see how logic programming languages would do for GUIs, and wasm is a promising platform to host other scripting languages than JS (speed is no longer the goal here). The main reason is that logic programming languages is probably the single best way to make two-way data binding work.
This channel is incredible! Really enjoy your delivery style, and love the content with nuanced perspectives that aren’t black and white.
I got confused about Yew vs wasm-bindgen, in these benchmarks are they "competing" or are they used together? I saw that Yew also uses wasm-bindgen, but wasm-bindgen scores better in the table, does that mean I can make a front-end using just wasm-bindgen without Yew and it will perform better?
Thanks for this type of content!
Great overview, and I really like the deep dive into why the differences seen are there, as well as the context of what it all means.
As a developer who primarily works in back-end or automation, I'm unfamiliar with the constraints of front-end work. Is it possible to get sub-second interactive page loads, or are we doomed to the 1.8s interactivity floor you showed in the chart? I know 1.8s is still "fast" by most standards, as the teams I help are often pushing 5-10 seconds before interactive, but the dream of a desktop-equivalent experience is that everything feels real-time without delay.
Dude! Great breakdown
is there a benchmark using a large, real life like project - say twitter like - that compares the load time and bundle sizes for leptos and javascript libraries? how does it "really" compare?
i know that airbus uses dioxus on their commercial planes. a lot of it is dependent on the specific project. twitter could be feasible, but it wouldn't make as much sense. wasm suffers the most with creation and i imagine twitter would have more than normal creation costs. apps like facebook, instagram, gmail, slack, etc, would make much more sense. the bundle might be larger with wasm, but it's also streamed into the browser which offsets some of that. time to interactive isn't an issue regardless just because of progressive enhancement. the main benefit of full stack wasm frameworks is server side performance.
can we have hybrid model like micro frontends.. so that on a large team some can focus on high performant wasm based framework on some critical viewsand other in react/vue..
What I don't get is why all of the performance metrics seem to be around accessing the dom instead of just equivalent graphical effects entirely in wasm, have I just entirely misunderstood wasm itself?
Is V8 able to auto-vectorize JavaScript code? If it isn't, applications could benefit from manual SIMD implementations in WASM
I am here because I am the maintainer of a web-app that at some point has do display interactive charts and maps that handle larges amounts of data. The frontend post-processing and the many abstraction layers of Plotly (and mapboxgl) are causing a huge slowdown and everything gets laggy. I am searching for alternatives of how I could perform faster post-processing (I already did my best with JavaScript) and GIS/Plotting. Do you gentlemen and women and anything in between have any suggestions?
Just a silly question. You said - "The main constraint is not actually the ability to call DOM apis from WA but the cost of copying strings from WA to JS". But then you at 10:00 say that - "creation ....where you have to generate a whole bunch of strings and ship them in to the DOM". So the constraints is actually accessing the DOM or transferring those strings from rust -> WA-> JS -> DOM. So if WA is able to access the DOM directly, wouldn't it be faster?
Good question. Here’s a rephrase: What’s expensive is not the action of calling a DOM method from WASM via JS, it’s the cost of copying and reencoding a string argument. Direct DOM access or the WASM stringref proposal should remove the need to copy which would be great. I suspect reencoding to UTF-16 would still be necessary but I’m far from an expert. So yeah it should be a win but maybe not 100% of the difference!
Yep.The web browser,JS engines etc today are so complex, that it's really difficult to say what will happen.
Greg, the leptos man, you're doing good work here, full of coconut oil
Very insightful, thanks for sharing. Now I wonder how I can apply this to webgl performance 🤔
Great video, thanks!
I'm new to programming and I've been enjoying tutorial hell before I invest time into writing code. I was wondering if wasm can replace json?
Glad to see SolidJS as representative of the JS frameworks.
I wouldn't pick rust over javascript for effeciency. I don't think we need better performance on the web today, but more statical typing and robustness, while keeping the access to web development pretty easy. The goal to me is to find a way so that with very little knowledge we can't mess up code and create invisible bugs, incoherent dependencies, while at the same time it shouldn't be very hard to develop a good web application. Rust looks a like a very good language for that, thank you guys for the frameworks you're developping!
Is there a list where we can see the websites using these Rust UI frameworks?
There is no need to "access the DOM directly" for WASM, because it's not what it was created for. But I still don't understand why to move HTML code into Rust if it doesn't make any performance difference - for an experiment? For fun? Or for something else?
Simple: 1) It’s a language I’d much rather be writing than JavaScript, in which I can express myself better and create fewer bugs 2) It performs much better on the server than JS, and writing single-language apps on the whole stack is great.
I bet there will be a performance difference once you do more complex things besides editing the DOM.
@@gbjxc You could have said from the beginning that you don't like JS and you just want to write in another language 🤣
Create less bugs? How about to use typescript instead?
@@f1amezof because the safety improvement from JS to TS is similar to the improvement from TS to Rust
How many more lines does it add compared to the equivalent javascript?
Like how much tinier is the delivered website?
And how much more convoluted will the implementation be?
I'm wondering, if browser can add support for UTF8 strings to JS? Or font rendering itself is tied to UTF16? Then perhaps Rust can make use of UTF16?
this is great. at this point my priorities revolve around developer experience
How did you set your text editor line numbering (in vim I assume)? That way of showing the line you are on and then the relative distance from that line is a brilliant move that I never thought of until this moment.
I’m a total nvim newb and copied my whole config from ThePrimeagen pretty much :-) the term here is “relative line numbers” I think. Super great for your j and k navigations
@@gbjxc Be careful with nvim, I just spent my entire day configuring it :P.
`:set rnu` to turn on, `:set nornu` to turn off relative line numbers
Using the link in the description I cannot see Sledghammer in the benchmarks. I also can't find it in the git repository. Is there a fork that includes the rust frameworks?
Thank you for a great overview, that was very informative and useful for us, "traditional" JS devs :D
That whole point about compile time verification of component diffing absolutely blew my mind. But it makes perfect sense. Holy heck that’s cool
I think currently the dev experience of Rust in the frontend compared with frameworks like Svelte or Vue, is very bad. And that's pretty important too: Run time vs Code time. I think in the near future we'll see devs migrating to WASM but there is still a lot of work to do to compare JS experience with Rust in the frontend. Thanks for this helpful information!
development experience is subjective. from a maturity standpoint it's not there. as far as writing code, i personally find it to have better dx. it's easier to start a project with js but gets harder as it grows. rust is the exact opposite where it's harder to start a project but gets easier as it grows. there are trade offs to both so it depends on the app you are intending to build.
@@eyz-4I think is not subjective when you can write less boilerplate and code in general so write a very simple component. Do you think a framework like Svelte or Vue scale worse than another Rust web framework? No way...
@@SilvestreVivo there's less boilerplate/code in leptos than react or vue. svelte has the least but svelte is it's own language which makes that possible. leptos is just a clone of solid js/solidstart in rust. the leptos server api is also much simpler to implement than kit, nuxt, and next.
@@eyz-4This confirms me that Svelte is sill easier that any web framework in Rust. That was my point. Maybe in the near feature will be different but not currently.
@@SilvestreVivo yes but svelte is not javascript. it's a completely different language that has it's own compiler. it has such great dx because it's not javascript. solid has comparable dx to svelte and rust has better dx than js. even then svelte is not a completely sure thing for every project. the server api as i said is very confusing compared to the leptos server api. you don't get the type safety and other features that the rust language offers. on top of that leptos is faster on the client and server by a significant margin so you get performance advantages. there are trade offs to both so it comes down to the project and what you're intending to do.
Great video!
That's really interesting about the cost of strings. Could you guys use utf-16 strings in the rust implementations?
It’s a good question - That may be a possible micro-optimization, but the issue is that the Rust String type is defined as UTF-8 so you either lose the *whole* ecosystem for working with strings in Rust, or pay the (relatively small?) performance cost. Certainly framework architecture ends up swamping the string cost, because Leptos/Dioxus are faster than Svelte/Vue/Preact etc simply because of our architectural choices.
@@gbjxc Wow, I was not expecting a direct response from the creator a leptos-rs himself 😂. Primeagen is always hyping up what a cool tool this is. It probably would be more trouble than it was wroth, but I didn't know if you could use utf-16 strings for a subset of operations like accessing dom nodes as you mentioned earlier, and only perform the conversion when you needed the full power of the rust ecosystem.
What exactly is javascript string interop? My editor saves javascript files in utf-8. Does that mean that the js engine converts my js files, saved in utf-8, to utf-16 before executing?
He is referring to the Javascript runtime string representation. So not the type of your input file but the types used in the language itself.
If you take a JS string in memory and look at it the representation it is not comparable with ascii or utf-8.
@@dynfoxx Thanks for the clarification. Since it's an internal representation, it could be converted to utf-8 without breaking javascript programs? All internal handling of strings would also need re-tooling to deal with utf-8, I assume. Would there be a benefit and or downside to any other interested parties?
@@richardgeddes630 I'm not 100% sure what you are asking and I don't know the answer for sure.
Basicly I belive the standard says all internal strings must be UTF-16 or there is a requirement that makes it inconvenient to use any other standard.
It would be basically impossible to change at this point.
Hello I'm actually new at web development. Is leptos good for seo if I dont use SSR? I actually want to make an lms marketplace for that I thought of using actix for the backend, so I thought, why not to go for front-end written in Rust. I dont want to learn two languages like JavaScript and then rust, just wanna stick with Rust so here I am. So is Leptos hood for SEO? Also does it support static site generation?
Solidjs mentioned! lets go!
Super interesting! As a frontend dev mostly working with vue, it’s so weird to me that it’s always dismissed so easily especially with it’s insane performance even though it is using v-Dom and it’s great community and easy to use api. Once vue 3 has vapor mode it should be on par with solid performance wise.
I think some people are simply jaded. It's like with Java, modern Java is amazing, but people remember the Java 1.5 days where doing just about anything sucked and younger developers haven't tried Java and just listen to the jaded seniors.
Vue is probably in a similar situation.
@toast Why is it a nightmare? You've got SFCs, typescript, ... What are the issues causing the nightmare?
@toast I am working on a large project with vue and can’t complain. Vue 3 is awesome and has super easy to use APIs, the script setup syntax is basically identical to how svelte handles JS, vue 3 was completely written in typescript so that is also covered and the composition API and the ability to outsource logic into dedicated, statefull, TS modules is an amazing feature. I haven’t really worked with svelte a lot so I can’t compare the two fairly, but I can say that DX in vue 3 is first class!
New to rust, but why not use UTF16 in WASM to match JS?
I saw nvim and harpoon!
Great video thanks bro
Do you have goals to make ur full stack framework compatible with multiple devices.
you are a great teacher man
Absence of separation info smaller bundles and lazy loading can be a problem for bigger rust front end apps.
Great video
I'd like to see DX improvements for rust wasm ecosystem and rust in general.
As someone happily running a 2011 CPU with the RAM maxed out to 32GiB for everything except web apps (I have a separate gaming rig I'm quite happy with... it's a hand-me-down of similar age with 8GiB of RAM and a Radeon HD 5870 from 2009), I'd say that WEB APPS IN GENERAL aren't ready for prime time, regardless of what they're written in.
When normal "a few open tabs and a RUclips video at 480p" web browsing doesn't reliably maintain better P99 janklessness than games like Superliminal or A Hat In Time, something's wrong.
if i write performance based code in c++ can i use wasm and see a significant performance improvement
I'm using Dioxus at the moment :p
We love Dioxus! (I mean, we love Leptos more but you know, we're all on the same team :-) )
I like the video, I might try some WASM on my portfolio. I agree that bigger applications might require a little more thought, the part that scares me the most is the size of the bundle, i hope WASM gets a code splitting feature, if they do, then its done. Greg I'd love to know why rust based frameworks were taking memory on startup even though they might not use it? Is it something rust related? I'm new to rust, I'm still reading the book and doing the rustlings course.
One silver lining of wasm's generally-larger bundle size, is that wasm parsing can be streamed, so by the time the file is done downloading, it's pretty much already parsed and ready to execute. Contrariwise, JS files can't be parsed until they're fully downloaded (AIUI), and that parsing cost is larger for JS due to complex text syntax's disadvantages vs wasm's compact binary format.
But still, I agree that code splitting should be made a lot easier. Right now, you have to create multiple wasm by hand and they can only communicate through JS. I don't know of any alternative to that at the moment.
Whoops, I hadn't watched the whole video yet and Greg covered everything I just said. 😅
@@mwcz5190 can WASM code run before everything is parsed?
@@climatechangedoesntbargain9140 I believe the answer to that is no, everything has to be downloaded before it's ready to run.
The browser can parse as the file is downloading, however, so it should be ready to go almost immediately after the last byte is received.
I think JavaScript has to download the file completely before it can even begin parsing.
The difference here comes from the fact that wasm is a binary format much closer to machine code, requiring the browser to do a lot less translating.
@@Andrew-jh2bn yeah, but you can load JS incrementally, so it can run before everything is loaded, even though the inidivudal files have to be completely loaded before parsing.
Very Great content
Am i misunderstanding something? You said the problem is not WASM not being able to call browser APIs directly but copying of strings to JS.
That copying is done because you can't call browser APIs directly, right? So it completely invalidates the previous sentence.
Is there something i am not getting?
*Notice's Primeagen's harpoon vim plug*
_"Ah, I see you're a man of culture as well"_
Amazing content.
I don’t why there is even this much of a discussion about performance, to me it was clear from the beginning, if react is fast enough, and its more than fast enough really, then pretty much everything else will also be fast enough. The speed of ui rendering is almost never a bottleneck on user experience anyways.
probably the only thing is 3d engines, they don't access to DOM but use many cpu resources in calculations, but i don't think wasm can help with gpu calculations performance.
My excitement for wasm isn't so much wasm, but rather that you can run combined code ( be it Rust or good old C ) in a browser witch today basically runs everywhere and to me that sounds awful lot like compile once run everywhere and you are also no longer bound to do web client side in JavaScript which likes to pull your hair out so JS being just a smidge faster then properly typed language is not much of concern for me.
How fast is Rust compiled to Wasm compared to Rust compiled to the processor's machine language?
Depends on JIT implementation that compiles wasm to native code in the browser.
Hm. What about consumption of resources -and battery-?
Optimizing web apps in the 0.% to save milli seconds ... then Marketing comes in and adds 4MB of tracking and other stuff that blots the apps performance 1000x ^_^
lol