Web-native Rust apps [PART 2]
ฝัง
- เผยแพร่เมื่อ 19 ต.ค. 2022
- This is my follow-up video on Rust and Wasm.
Do check out part one, if you haven't already. • Rust & Wasm
Sponsor: Quadratic - The Data Science Spreadsheet for Engineers
Check out the project on Github: github.com/quadratichq/quadra...
View open jobs here: careers.quadratic.to
If you would like to support what I do, I have set up a patreon here: / noboilerplate Thank you!
All my videos are built in compile-checked markdown, transcript sourcecode available here github.com/0atman/noboilerplate this is also where you'll find links to everything mentioned.
Corrections are in the pinned ERRATA comment.
Start your Rust journey here: doc.rust-lang.org/stable/book/
CREDITS & PROMO
My name is Tris Oaten and I produce fast, technical videos.
Follow me here / 0atman
Website for the show: noboilerplate.org
Come chat to me on my discord server: / discord
If you like sci-fi, I also produce a hopepunk podcast narrated by a little AI, videos written in Rust! www.lostterminal.com
If urban fantasy is more your thing, I also produce a podcast of wonderful modern folktales www.modemprometheus.com
Special thanks to my patreon sponsors:
- Affax
And to all my patrons!
ERRATA
GTK doesn't support webassembly but you might be interested in the Broadway Project docs.gtk.org/gtk4/broadway.html
It could be fun to have the errata comment be something like the following some time:
match errors {
None => println!("So far...");
Some(err) => reply_to(comment, err);
}
Apologies for the bad code (which I typed on mobile), but you get the idea :)
@@miguelguthridge hehe!
not really an errata, but the egui people have a convention on how to read and write their name:
"Name
The name of the library and the project is "egui" and pronounced as "e-gooey". Please don't write it as "EGUI"."
@@fakegermano Ha! I didn't know that. Names are hard aren't they XD
Not that important, but GTK doesn't support webassembly, and there aren't any ports as far as I know of. Its also not simple to port, basically the entire library runs off of the assumption that a filesystem and windowing system is present.
What you might've seen is _broadway_ a GDK backend that can be used to render GTK apps to html over a websocket connection. However, this requires running your app on the server with a separate instance for each user, which really doesn't scale well at all.
Literally LOL'ed at "JavaScript is aggressively fine." That is a perfect way to describe the...thing.
Heh, there's a good language in there, but they keep adding bad features!
@@NoBoilerplate not helped by the never ending list of libraries and frameworks. i'm a vanilla fan. that's how it was when i first used it in the 90's. that's how i use it now. and it works great.
"aggressively fine" is a good way to describe Javascript
Hi
so… as an alternative to creating a HTML+JS web app and making a desktop version that runs in a Chromium instance, we could be making Rust GUI desktop apps which seamlessly work online via WebAssembly?
You've got it.
The power of native app development, with the ease of web distribution.
Check out www.egui.rs
Lol :D
What about accessibility? SEO?
@@31redorange08 you host a pre-rendered blog on your site for that. Your app's dashboard doesn't need to indexed by google.
@@nodebutler7681 that only covers SEO. What about accessibility? The dash still needs to be accessible.
Fullstack web dev for 10 years here who just stumbled upon Rust a couple weeks ago. And wow. Between egui and Yew ... I want an excuse to go learn Rust more in-depth and build something with them.
Right! Same background as me - All Rust needs is a tiny bit more momentum and we're about to change the world!
Exactly my thinking !! How can I fit rust in my daily schedule please !!
Was really happy to see egui mentioned! Been developing a complex webapp using it and it's by far the nicest gui framework I've ever used!
Great vid for Rust advocacy, we get real examples of what people have done with it.
Thank you!
A web browser is a virtual machine that downloads and runs code on the fly. The further we are from implementing that in software, the worse the web experience is going to be. WASM and WebGL are huge steps in the right direction.
Incredible contribution brother ! You are awesome
I built a debugging tool in egui for my work recently, it's awesome! It's my first UI I've ever made too :D
That sounds awesome! TELL US ABOUT IT ON THE DISCORD!
Do you read my mind? I was looking for GUI libraries for Rust two days ago and now you upload this video :D. Love your videos, keep up the good work!
perfect timing!
Upvote for Quadratic and Egui !!! my current app runs on Egui
Nice!
I've created several WebAssembly projects and this was very educational. Thank you!
My pleasure!
Have any resources to learn webassembly and rust?
LETS GO! Always on the lookout for nee boilerplate videos
Thank you!
Egui is beautiful. Thanks for sharing these gems!
My pleasure! Come chat to us about it on my Discord, there's lots of people who love egui there too!
BROOO thankyou so much, this really helped and the tutorial was really easy to use as well :)
Glad it helped!
I love the html/css api, you can build amazing things with just a few simple lines of both. Checking the rust code in the video, although it has the potential to run fast, it doesn't look appealing as compared to, say, jsx.
I feel like this is great, but no more than a niche until the api is more friendly to the general public. Like what unreal/unity do for opengl/directx/vulkan.
The frameworks shown still feel too low level to go mainstream, although they do show promise for what's to come.
Have you see my first video on this subject? yew.rs literally has this jsx syntax that you're asking for, go check it out! th-cam.com/video/P4LMfkFLRsI/w-d-xo.html
I love yew!
@@NoBoilerplate I have not and I should have, given the note at the beginning of the video.
Will definitely take a look.
Thank you very much!
@@TheRanguna Nice! Also, there's 10 other videos about INSANE rust features, do check them out 😁
@@NoBoilerplate that I did check, albeit not all of them. Love your videos, keep em coming!
hanks lot Sir.. You helping us..
egui is a great library. I've already used it at work to build some small projects.
i am a web dev who's been around the industry for a bit over a decade, and i absolutely love what you say about the distribution framework of the web
that's what brought me here, it's good to be reminded of how much i still love it
I'm so excited by wasm and webgl, but (as I hope I explained in the video) the DOM is SO GREAT too
I'm just excited for WASI and the WebAssembly-GC (while not directly useful for Rust, it adds support for other stuff) that will ultimately lead to webapps without any js. Currently emscripten and wasm-bindgen both have to make javascript binding code to convert WASM ints/floats to strings, and then parse that into web API calls.
Yeah, that'll be fantastic! Doesn't need the GC though, right? We just need proper wasm bindings to the web apis
@@NoBoilerplate Yeah we won't need the GC and can leave it disabled, but it'll give us access to proper type interfaces.
Been doing web dev for years. I feel like WASM will be great for power apps. I had an employee make a UI in unity that compiled to WASM. It looks fantastic and gave the website a really distinct feel. The browser is essentially a platform that outpaced the JVM for portability and development speed. I think low-code (not no-code) options are what will replace day-to-day websites, websites for DMVs or submitting a reimbursement. Web pages are visual constructs, they should be made visually. CSS is the embodiment of this, and the bane of most web developers.
The big thing that needs to be improved in webgl is accessibility. EGUI has workarounds, but the standards are still evolving there.
egui is a great library. I'd recommend it.
Very informative video! As someone with a penchant for roguelikes, Bracket seems interesting. One thing I would've liked to know about all of these is if it's possible to build "native" (i.e. running outside of the browser) versions of apps using these frameworks.
They all are cross-platform, just hit the links!
Macroquad (Game engine) can be used to make for all platforms and WASM with the same code.
Hello ! I love your videos !
I would love to here your take on Iced. Do you plan to investigate it ?
Oh cool! Thanks for showing me, looks like yew's reactive model but for native. Very nice.
I don't have any deep-dive plans yet, I've still got lots of shallower topics to exhaust, but I've put it into my backlog :-)
That all sounds too hood to be true 😉
Was there at the beginning of Netscape internet. It is awesome and wonderful how dar we came.
It's actually BETTER than this video explains, I've only talked about using Rust in the browser, where it is very exciting, but it's a niche.
Rust's SO exciting, and it's so popular that your boss actually might let you use it ;-)
See more of my Rust series here th-cam.com/video/Q3AhzHq8ogs/w-d-xo.html
thx and subscribed
Muito bom, vou atualizar. Very good. I will update.
WASM is amazing for apps, but typical web stack is still the *easiest* way of creating simpler (and prettier) UIs.
And what about accessibility?
Great question, AFAIK EGUI builds hidden form elements that can be spoken aloud for screenreaders and such, but there's much to be done.
Exactly my thoughts. Just a webgl canvas will be lacking one of the biggest features of modern DOM. As much as I love ditching the old DOM and CSS, I would not use it in production until the accessibility is not on the same level :(
Nothing stops you from having both. Yew manipulates the DOM like react.
@@katech6020 doesn't yew use the old and annoying html/css workflow? I had hoped to finally ditch that
@@johannes596 yew works like react, it has a syntax similar to JSX
Thanks for dropping this, I played around with simple WebGL canvas stuff, but found it cumbersome trying to decide which bits should go in rust versus the difficult to debug shader logic and while i got shapes moving around nicely these frameworks hopefully streamline development.
Hmm could Bevy help you there?
most likely, i just hadn't run across it thus my appreciation of this video showcasing it. the abstraction of webgl versus webgpu is appealing as well
This will require implementing A11y in JS to provide accessibility in WebGL contexts, otherwise it's not viable for real world use. You can see how you would go about that in react-three-a11y - which doesn't support all of ARIA yet.
Accessibility is incredibly important to the work I do, I couldn't agree more.
But consider the Wavacity port - that wasn't accessible on the desktop before it was put into the browser - so there's nothing changed there.
In good news, EGUI are putting in lots of work to make accessibility happen in as best they can. AFAIK, they make hidden DOM elements for each UI element so that a screenreader can read it. Plenty of work to be done, we're in the early days yet.
@@NoBoilerplate That's good. I have always been skeptical of non-native UIs due to their lack of a11y even outside the browser, so it's good to hear there's a ton of work being put to make it happen.
Excellent video! What font are you using?
FiraCode Nerd Font - it's LOVELY
Webassembly is definitely the way to go, but I honestly don't think rust will take over the web (I know the video doesn't make such statement, but a lot of people have been repeating this narattive).
Rust is just too hard, so I don't think a lot of startups ( that don't need rust performance ) or even many starting web developers will even touch rust.
I personally love rust and would love to see more usage of it, but for now it just feels like it's occupying niches that weren't filled or were poorly filled by other languages.
Great video as always, but I'd love to see a video about shortcomings of rust one day at least.
Me too, they all seem either a bit lackluster
th-cam.com/video/2h05zeFWSj8/w-d-xo.html
Or unhinged and psychotic (I won't link to these lol)
Maybe one day!
Thank you!
You're welcome!
@@NoBoilerplate I would really love to know what you using for your slides...
@@io_inc It's so simple: It's obsidian.md
I talked about it in detail in the middle of this video th-cam.com/video/ifaLk5v3W90/w-d-xo.html
All my slides are open source here github.com/0atman/noboilerplate/tree/main/scripts
I’ve messed with Bevy a bit (still trying to wrap my head around ECS!) and know it can target WebAssembly, but I’ve never felt like trying to mess around and get the compiler target set up… maybe I should look into it?
You should! It's so fun to get a 3d scene running. Do ask in #newbie-advice on my discord server, there's loads of bevy users there!
Hmm, this looks very interesting! So I get you can send your code over to a server and then people visiting the site will run that code in their browser, but is there a way to take the exact same code and compile it to a binary that runs on the desktop without a browser? Essentially turning the web page into a downloadable app, which sounds really cool if it's a thing
Yep, all frameworks I have describe target both desktop (win/mac/linux) and browser!
"...and I've used emacs." I lost it.
org-mode is great! :-D
For once, the software is actually really useful
I just started a project using Yew and kept thinking whether there is a more "Rust" frontend framework. I came across egui but totally forgotten about it. But with your video, I have decided to give it ago instead of using Yew!
Both very fine options! EGUI for native, Yew for web!
Since I don't have much experience in the field I figure I can ask here: How do "native UI" web apps compare to JS-DOM-fiddling regarding data transfer size?
I don't necessarily refer to the page load time (though that can get annoying on certain connections), but like "can the server service the same amount of clients" and "much will I have to pay for data".
We benchmarked this on the channel's discord server yesterday:
hello world wasm size: 17KB
yew hello world wasm size 128KB
Brackets hello world size: 500KB
I'd say it's very competitive in terms of bundle size, these values don't change much when you start building your app on top, most of the above numbers are the initial standard library / runtime overhead.
@@NoBoilerplate Interesting, thank you!
"It's aggressively fine" 👏👏👏
SO fine XD
How did you get those fancy arrows and comparison operators?
Most editors support 'ligatures', which are joined-up characters, so when I type -> it makes that arrow. Many fonts support this, my favourite is FiraCode. Enjoy!
I've been using emscripten for a few months to port a pre-existing codebase written in c++ to WASM. The codebase is heavily dependent on networking, and getting things to work in the browser has been quite painful: I've had to completely restructure much of the code. My question is: is networking from within WASM any more streamlined when compiling from Rust?
I don't know a lot about networking but Macroquad(game engine) has a multiplayer game demo on their website, it may help you.
The big challenge with wasm is that any interaction with web apis (networking, screen, sound, DOM etc) have to go via Javascript.
With other wasm languages (other than C++ and Rust) that is a REAL turn-off, as they are ALREADY so slow, and now this is another slowdown.
With C++ and Rust, however, the speedups compared to javascript balance this somewhat.
As you will have discovered, it requires careful design to work around this problem, until the browsers implement direct access for wasm.
The way I look at it is when building a wasm app you must:
- Make as few network requests as much as possible, perhaps by designging your API to bundle more data in each request, or using graphql
- Only update the DOM when absolutely necessary
- Keep a lot of state in the browser side, only sending pipelined messages from wasm to trigger pre-arranged state changes
ie, what we'd do for good webapp design anyway!
I'd love to see a working web assembly example using gtk-rs. I've got 10s of thousands of lines of code of practice using gtk-rs. Where could I find some documentation for that?
Great question, I'm afraid I don't know, but I know someone who does! Join my discord channel (links in the description) and ask in #newbie-advice for @eden - tell her I sent you!
60 FPS, does that mean that libraries like WebGL or WebKitGTK redraw their content 60 times per second even when it's not modified, like the "hello world" in your example? I'm not too familiar with that technology. For example, I've noticed that egui and gtk4-rs were constantly using a lot of GPU even when mostly idle, which made me choose other libs like fltk (less fancy for sure, but not as power-hungry and without 3rd-party lib requirements for gtk4-rs).
WebGL draws onto a canvas, it draws whenever and whatever the application tells it to draw, and GTK utilises local reloads so it only draws 60 times a second to render continuous change.
Egui on the other hand does rerender (at least rebuild the draw command sequence, idk about optimizations in its rendering pipeline) 60 frames a second, but that's because of immediate mode.
Yeah, exactly, it's down to the provider.
My wording of "60FPS" I should have said "up to 60FPS" to illustrate that you can do whatever you want.
WebkitGTK is not what you're thinking of. WebkitGTK is a web engine like Chromium. GTK does have a WebGL backend called Broadway though.
@@NoBoilerplate I don't think it's capped at 60. On my 165hz monitor, the egui demo site looks like it runs at the full 165 fps to my eye, and it's usually easy to tell when something only runs at 60 as it's nearly 3x slower than native frame rate. Anyway, it does seem cool, but - people mentioned accessibility - for me, I just hate the sound of having to rebuild every single thing about a web interface from scratch when we already have css
Hi! I decided to take on the Rust and WebAssembly book, but it looks like it's not being maintained.
I can't get the Hello World! to work, because of deprecated packages and such.
Are there any other resources you'd recommend to get the hang of it? 😶
If you want to just get cracking fast, I'd go with the yew.rs tutorial yew.rs/docs/getting-started/introduction
You should also mention femtovg. It's a 2D vector graphics library, which also works well in the browser.
Looks good! Says the backend is opengl, any wasm options?
@@NoBoilerplate Yeah, one of the examples also runs in wasm.
And recently I ported all the examples to run on the browser, but the pull request has not been accepted (yet)
what do you think about iced?
oh it's really cool! I just found out about it, seems up there with egui, good to test both for your usecase!
egui is impressively flexible and easy to use, but something about immediate mode ui irks me, but i can't place it. Perhaps it's just yet another learning curve that will be better on the other side, like Rust
If anything, there's really only two big gotchas with immediate mode:
1. power efficiency. It renders every frame regardless of state update, which helps a ton with smoothness and latency but spends CPU even when there's no meaningful interaction.
2. Layout is a bugger to do in some circumstances.
It's great otherwise, but there's definitely a time and place for retained mode UIs. That being said, a pseudo-immediate UI could work really well, where it does diff calculations to make small changes in the UI efficient like React and Yew do or it simply ties all re-renders to meaningful interaction (mouse movements in and out of hover bounding boxes, clicks, key presses, etc.). It's definitely massively inappropriate for traditional, rich websites like Facebook or Reddit, but it's great for apps.
The biggest issue I have with using either web GL or just good old-fashioned HTML canvas is the lack of ARIA and whatnot
What problem does that cause you?
@@NoBoilerplate Me personally, no issue at all. But I do prefer making accessible sites and at the end of the day the DOM is the best way to do that (for now). Don’t get me wrong, I think the technology is awesome and will definitely be messing around with it, but the lack of accessibility will be a hurdle to widespread adoption of WebGL+Rust. Personally I think the best application of rust in the browser will be as the backend for the next React. Doing complex state management, render logic, and dom calculation in rust and then interacting with it from JS/TS could be very powerful. But all that said I’m still not really sure where it’s gonna go, but I fully agree with you that it’s going somewhere!
@@jthoward I can tell you've not watched my part 1 on this topic, you might be delighted: th-cam.com/video/P4LMfkFLRsI/w-d-xo.html
@@NoBoilerplate I did actually see that video (and liked it), I just don’t think it’s quite mature enough (speed and library wise) yet, but that’s a gut feeling based on minimal experience, hence why I’m gonna have to get around to it. Heck maybe I’ll port one of my rust TUI apps to WASM
I'm skeptical for reasons too big for comment box. At the same time, I want to believe there can be a language that goes up and down the stack, services machines and humans equally and transcends historical job roles. TIL figma's core is webasm and Rust. Sheesh, what a counter-argument.
I'm sorry for the confusion: Figma is written in wasm and webgl - I don't know what they wrote it in. It MIGHT be Rust, but I've not found that out.
If you genuinely want to believe, then watch this th-cam.com/video/PuMXWc0xrK0/w-d-xo.html and then th-cam.com/video/P4LMfkFLRsI/w-d-xo.html
I'm excited about Rust for this exact reason: It might be the last language I ever need
Hey, do you know about dioxus?
Nice I didn't! Looks like yew.rs is more mature for now though
Most of the time an web app just need to display text, image, and some inputs. Writing web app with js and HTML is relatively simpler than writing rust. Do you think there will be mass adoption of rust web app development in the near future?
There's two ways you can use Rust to write apps in a web browser:
- Native webgl (this video)
- Native DOM (the previous video th-cam.com/video/P4LMfkFLRsI/w-d-xo.html)
Both have good points!
egui is great, but they really need to work on the text rendering.
At least in the web demo, not only it's greyscale AA instead of subpixel AA, but the hinting is very poor, leading to a very blurry mess.
It's bad enough that I wouldn't consider using a webapp made in egui because reading litterally hurt my eyes 😢
It's sad because I really like the idea of egui, I prefer it to imgui in many aspects
I wonder if there's an open issue for this? Seems like something they'd want to get right!
A quick tip that might help you here: egui obeys the browser's zoom scale - so if you zoom in a notch or two that might clear it up for you?
Problem with web assembly is that it's still limited by the browser, it uses the same slow fetch and JSON parsing under the hood.
I was not aware of that. My understanding is that DOM manipulation must go via javascript, for now (which as I said in the video, WebGL solves).
Could you link me to a page about the slow fetching problem? Thank you!
@@NoBoilerplate I'm not sure if anything has been written about it but I'm building a data intensive app with qt c++ and when I heard about web assembly I was excited to see if I could switch to the browser to avoid deployment hell. I quickly found out that I wouldn't be able to use any of the high performance JSON or requests libraries because WA uses the standard JavaScript fetch and parse. For most web related stuff these are fine but my app downloads 100s of mbs of json data on startup, which is nothing with true native desktop performance, but it destroys a browser.
@@theLowestPointInMyLife The key thing in your explaination that doesn't add up, is that json parsing can be done natively, it's a pure cpu operation - why would we ask javascript to do this? I don't think this is right, certainly not in the Rust world:
The most popular https library, reqwest, has a wasm version, and it seems to do both fetching and json parsing natively.
docs.rs/reqwest-wasm/latest/reqwest_wasm/
Again, if you have any documentation on this, I'd be keen to read it. Is it possible you are mistaken?
@@NoBoilerplate I think the issue is that the JavaScript object eventually has to be created in the browser to access it in the app and this uses the browser API, don't think there is any way around it but there doesn't appear to be much documentation I can find.
This would also mean that a lib like reqwests couldn't be used because only browser API fetch is allowed.
I think there's some confusion here. The basic problem (as far as I understood it) is that in order to use most of the browser API including fetch and DOM, you need to get into JavaScript land, which also includes some fairly expensive conversion / marshalling from and into JavaScript Object types.
My biggest issue with Rust is the compiler. It flags functions as having errors when in fact the functions are correct and code that is calling them is having an error. Either that or I was having multiple brain malfunctions... which can happen :-)
How frustrating! That's not been my experience, I wonder when you tried out Rust? The error messages became WONDERFUL around 2020!
As I say in many of my videos, Rust's errors are the best in the business!
Ah yes bevy.... I did manage to put a little project I made there to github pages you know? can't say it wasn't easy tho. I had quite a bit of trouble. (in part cuz I had trouble understanding the instructions in the bevy cheat book.)
They've made it as easy as they could, but the domain is quite a complex one!
@@NoBoilerplate Indeed, it also doesn't help that I don't know how to write HTML much, so I kinda had to download a preset online.
@@costelinha1867 You'll never regret learning HTML 🙂
working with wasm i always counter sharedArrayBuffer n wasm size too big on mobile browsers. will rust can help me to solve these issues ? or its a general problem.
I'd love to see the code that's causing problems here. If you would like to post it on my discord, over in #programming, there's lots of people to help you, either by suggesting fixes for the old code, or telling you how it wouldn't be a problem in Rust!
@@NoBoilerplate thaamkss. i’ll post there. it’s wasm of ffmpeg.
@@catbb oh COOL that should be a very good thing to put into wasm!
@@NoBoilerplate looks like there’s no active crates for ffmpeg wasm in rust. :/ . found regular ffmpeg crates but not sure if they gnna work on browsers when compile into wasm
@@catbb good luck!
1:31 Is that screenshot from Mario Kart Tour?
holy shit dude yes, well spotted!
"focusing on fast and technical videos"
the video: 9 minutes long, full of water
Perhaps this one's a little slower than normal because it's Part #2? Check out #1 th-cam.com/video/P4LMfkFLRsI/w-d-xo.html
@@NoBoilerplate Well, that's cool and everything. However, most web apps still require SEO. Unfortunately, yew is pretty much dead, so SSR is not coming any time soon. Bundlers (like trunk and wasm-pack) are too far from being production-ready (no hashing, no compression, no plugins, no anything), and no one is working on that. I would love to use WASM but that just won't happen.
Wow
egui is not what you should pray for, it is perfect for real-time/game apps, but poor for desktop apps because of heavy CPU usage.
Basically, most of web frontend needs beautiful hypertext with some interactivity and simple animations and HTML/CSS + any modern JS framework would do the job better than WASM. For example, WASM is great for web games and rendering stuff, but not for marketplaces. Am I wrong?
I'm confused, wasm can interact with everything in the dom, which includes everything you've said?
Yew is faster than react. It's not yet faster than most, but it's faster than react!
@@NoBoilerplate My opinion is based on this video th-cam.com/video/PHvT3QShPTo/w-d-xo.html and some discussions on r/reactjs. Performance gain is not critical for business. When comparing the production costs of React and Yew projects (learning curve, availability of specialists in the market and their cost, production speed) React is the obvious winner.
@@NoBoilerplate and as far as I know WASM doesn't have direct DOM access, so there is an I/O overhead compared to JS
@@4sat564 Yes, for now that is the case. It shows just how much faster wasm is than js that even with this huge overhead, Yew.rs is faster than react!
@@4sat564 What an interesting problem zaplib had!
Theres one problem with Rust wasm... the working group has been largely inactive for about four years. wee_alloc, for example, has had a horrible issue that causes memory leaks that has been open for several months with _zero_ feedback from the working group. I can only hope that eventually someone else will take up maintaining the ecosystem.
INTERESTING! I've looked into this, why do you say the working group has been 'largely inactive' - what does that mean?
I do note that wee_alloc has recently become known to be legacy, but only in the last 6 months.
I see a comment on bevy thread
"The savings from using wee_alloc instead of the default dlmalloc are negligible in comparison with the size of bevy itself. In addition wee_alloc is slow and suffers a lot from memory fragmentation."
SO: the benefits of wee-alloc seem to be lost when using a framework such as bevy, egui, or bracket, as I mention in this video? The default allocator works fine!
I disagree with getting rid of the dom, it has so much built that make the web not terrible, like highlighting in copying text and screen reader support and being parsable by computer, or subpixel rendering
Totally agreed, I love it, and love frameworks (like yew from part 1) that use it. The dom might be the best ui framework we have ever seen, and now it can be paired with a language worthy of it, I'm so excited! Since publishing this video I (and the rust community) have discovered leptos.dev - just incredible!
May the Swartz be with you.
This is the way
I think you might be the only person I've ever met that loves the DOM...
Show me a better UI debugging tool than the browser inspector - billions of dollars and millennia of person-hours counts!
@@NoBoilerplate could i, uh, interest you in the gtk debugger? ._. the LEVEL of information is something else
@@edencreeper3223 ORLY *googles*
"...and I've used emacs" me too!! M-x doctor
org-mode changed my life! Also magit and org-babel!
Lmao I loved game design is my passion
I'm somewhat of a Gabe in that regard
WebGL is very cool but writing compute shader with it is a lot of painful hacks.
sounds it!
i love how u blur ur search history
Did I?
🦀
is this a reupload?
No, its part 2!
@@NoBoilerplate i recognized the part about the sound editor, the stylesheet and Rust + WebGL >>> WA screen. Was this in the previous one too?
@@sinterkaastosti988 yep, I used the sound editor example in the previous video. Same sponsor, too! The discussion about distribution and deep-dives into rust frameworks in the second half are different, though.
@@NoBoilerplate that explains it all, i thought i was having a massive Deja Vu or something 😭😭😭
Web shouldn't exists as it is now, and i think enforce Rust and even C++ and other languages as "web app language" is going to be a disservice to those languages.
Why i don't like the web? Because i saw what Plan 9 from Bell Labs and 9P are truly capable of. What we need is not the "web" but a file system through the network, with a protocol like 9P. Rust also has a library to make 9P servers and also FUSE for linux, and i think you will like it too.
Big fan of the Plan9 stuff. However, we've got what we have got. The web is here, and we can improve upon it!
@@NoBoilerplate Well, that's true, unfortunately. :/
I'm sorry Triss, but this all seems too good to be true, but I probably have some fundamental misunderstanding about the way that web pages (and web apps) work.
I'm gonna make a number of definitive statements, but think of them as each bearing an asterisk of "this is what I think happens."
Web App frameworks are fundamentally a really fancy way to get HTML to the browser. Sometimes you change that HTML, tell the browser that it's been changed, and the page is re-rendered.
No matter how fast your server side backend is, the rendering speed of the application is constrained by the design decisions made by the developers who work on Chromium, Webkit, and Firefox. Any client-side calculations made are similarly constrained by the browser process.
Those applications are written in C or C++ (with all of the performance advantages and memory pitfalls that aspect brings), but web browsers are notorious memory hogs. If I want to distribute an application that doesn't demand 4 GB of RAM for its exclusive use, I fundamentally *can not* do so as a web application, right?
WASM doesn't use html, that's the key thing missing from your understanding.
Here's DOOM ported to webassembly, no DOM here wadcmd.com
@@NoBoilerplate I'm so confused... Isn't the browser, at it's core, a process for rendering HTML? Sure, it needs to render some components of its own AI, and is that how WASM works? And from what I can tell, browser processes still hoard a lot of memory, even when they're not turning HTML into a UI.
@@chrs-wltrs You do sound confused, which is the first step to learning! Fireship always has great intro videos, check this one out th-cam.com/video/cbB3QEwWMlA/w-d-xo.html
@@NoBoilerplate Yeah, I did some research yesterday after we chatted, including the FS.io video and a great talk by Guy Royse (th-cam.com/video/3sU557ZKjUs/w-d-xo.html), from whom I always enjoy learning. I guess at a certain point, I just need to try making a test application in each of the options, and see how they perform.
a) Web App {Yew} (+ Distribution, - Performance)
b) Native {Tauri or Flutter} (+ Performance, - Distribution)
c) WASM {WebGL} (???)
@@chrs-wltrs I'd love to see the results of that! Do join the NB discord and tell us!
Can I still b part of the community I forgot how to be awesome like 10 years ago? Just trying to obey the guidelines.
Your politeness makes you awesome, welcome :-)
K I N G
WebGL will soon be replaced by the much higher performance WebGPU. There's a great Rust library wgpu. It can be used for Metal, Vulkan and DirectX 12
Discussed in the video
please watch the video before commenting
"soon". Probably closer to 5-10 years..
My bad on the premature comment! Should've watched the whole video
@@alexcampbell-black8543 no problem! There's some lovely people on my discord who are REALLY excited about WebGPU, come and chat to us!
I will build the most complex thing I know in Rust...
Hello World!
The way I look at it is this: Rust isn't optimised to make simple apps, it's optimised to make complex apps.
In most languages, simple things are easy, and hard things are possible.
In Rust, simple things are possible, and hard things are easy!
@@NoBoilerplate well thanks to some of your videos I decided to pick up Rust recently. Earlier tonight when re-attempting some simple code I hadn't been able to get working, I had a few "Ah ha!" moments and finally got the code working. Got a good kick out of it.
Looking forward to the point where I can actually write an app... but for now, I'll take the small wins.
@@thisisscotts congrats! It's a harder road to start than for javascript, but I promise it's an easier road to master!
Check out the rest of my rust series for exciting features you're gonna love, and then go for:
- fasterthanli.me/articles/a-half-hour-to-learn-rust and
- doc.rust-lang.org/stable/book/
Do join my discord and ask in #newbie-advice or #programming if you get stuck!
@@NoBoilerplate awesome mate, I'll likely drop into the #newbie-advice channel at some stage!
@@thisisscotts Fantastic! do tag me and say hi 🙂
1st
2nd
@@Speykious 3rd
not on my screen I'm afraid!
N-th
Ru-st
ah yes channel of rust propaganda
let me be very clear: My videos are mostly hype by design.
Most comments on my videos are by total Rust newbies. Some are even new to programming and are so excited by what they see. If you don't understand Rust, and someone explains it clearly, as I try to, it seems like magic. Rust is the #19th most popular language, but the scale is not linear. There is a lot of work to do if we are to not suffer the same fate as Haskell.
I want Rust to achieve escape velocity.
I see my job not as a details person, I am way under-qualified for that, I point people to fasterthanli.me for details. My focus is funneling new people to Rust, getting them so excited they can't help but push through the learning curve, and then from there language sells itself.
Back in 2020 I crashed out of learning Rust twice. First time due to multiple string types (haskell's biggest mistake made again, I thought to myself) and second due to lifetimes. At the time I had a great mentor (Shout-out to Alex!) who picked me up and helped me back on the path. Most people don't have this. They need the excitement of my hype videos to break through.
I will eventually run out of hype topics and move on to slightly more detail. But first, there's a few million developers I want to send to rustup.rs.
@@NoBoilerplate , how did you overcome the difficulties related to lifetimes? Are there any good resources?
@@mister-ace There's two ways to think about Lifetimes: As a liability and an asset.
I started off thinking about them as a liability - something annoying I HAD to do to satisfy the compiler. This is a totally fine way to start off with, and I have some suggestions as a beginner, in order:
1. Don't use references, use ownership and share nothing. Pass in variables into functions, and if you need them later, return them back out.
2. Copy and clone everything. Rust is 80x faster than python, you're probably not going to notice the performance hit!
3. Only use references when the compiler tells you to. This will eventually teach you how to use them.
When you've done (3) a few times you're ready to move on:
The intermediate way to think about lifetimes are not as an annoying piece of syntax, but something to enrich the model of your data.
Other languages allow you to model WHAT your data is. Rust, through lifetimes, allows you to model WHEN.
There's nothing magic to learn, just read The Book doc.rust-lang.org/stable/book/
And practice with github.com/rust-lang/rustlings
You'll get it! And do remember the reason you're learning all this: Rust has loads of features you simply can't get elsewhere: th-cam.com/video/PuMXWc0xrK0/w-d-xo.html
@@NoBoilerplate , I am very grateful for your answer)