Now is The Best Time to Learn WebAssembly
Вставка
- Опубліковано 27 лют 2024
- A Web Assembly Crash Course.
💬 Topics:
- What is Web Assembly?
- Why use Web Assembly?
- Web Assembly use cases;
- Web Assembly vs JavaScript;
- Build apps with Go;
- Go and Web Assembly;
✉️ Join the Newsletter - newsletter.awesome.club/
🥇 Become a Member - / @awesome-coding
📖 Blog Article - www.awesome.club/blog/2024/no...
You should be very careful when making performance claims about WASM. Unoptimized WASM is often slower than js, and optimized js (using array buffers and workers) can often result in near identical or better performance than WASM. A lot of number crunching tasks like image processing are also better suited for the GPU than the CPU, so using webGPU instead of WASM would make more sense.
The real reason to use WASM is simply that you can run your non-js code in the browser or any other WASM environment.
Good points!
Thanks for mentioning them!
I'm MOSTLY with you.
But performance optimizing JS code manually is painful, and not always well documented. In addition, if you test your JS in one browser to find what should be optimized, this may not transport to other browsers (particularly mobile browsers tend to be worse at dynamically optimizing code). And most JS libraries will not be performance optimized, so you've got to do everything yourself.
So if you need reliable performance and don't want to write everything yourself, WASM is worth it. But in that case you probably don't want to use Go to do it, but something like Rust, which is better at having predictible performance for CPU intensive tasks.
Very much with you when it comes to WebGPU, but that is also even harder to target for a "normal" developer, if you target it yourself. Understanding shader code, and what shader code is performant on GPUs is not trivial, and again often not portable between GPUs.
@@9SMTM6 Funny you mention js performance stuff being poorly documented, because I found the WASM documentation to be so awful I just kinda reverse-engineered the binary format to get a feel for it instead of reading docs. Agree about most js not being optimized, which is why I don't use that many third party libraries.
My point is that if you're expecting your performance to skyrocket by rewriting your logic from js to some language targeting WASM you *should* be benchmarking the result, because JS is a lot more optimized (and WASM is a lot slower) than most people think.
Go and Rust are actually both good examples of languages that could lead to poor WASM performance. Go has GC and Rust has implicit allocations. If you want to go fast you *need* to minimize your allocations, regardless of if you're writing JS, Go or Rust. None of these languages are slow, but cloning millions of objects every frame is.
And sure GPU programming is not trivial but I'm not really interested in making code "junior friendly", I just want to ship applications that are actually good. And you can always upskill people if needed. None of this stuff is hard, it's just a bit niche.
@@9SMTM6 To give you a concrete example of allocations mattering more than language: There's this frontend framework called Yew that's basically a clone of React but written in Rust. Their VDOM is very optimized and they don't have GC to worry about, so predicably it's a bit faster than React.
However javascript frameworks that do not use VDOM are still significantly faster than Yew, because they simply do less work and allocate less.
@eak2112 i've been saying wasm can reach the mainstream only when browsers implement features for manipulating dom (there is no such proposal for now, and the creators have said already that js is not going anywhere) via wams rather than interop js. Wasm is useful for cloud service providers, building general purpose function and exposing it to multiple languages and of course re-using code for desktop apps like what Autodesk does.
one thing that's missing in most languages that i'd like to see in wasm is a web-sys equivalent. it's a rust crate that automatically generates dom bindings from webidl definitions. in other words, you can manipulate the dom from rust without js glue code. the js glue stills exists, but it's handled under the hood for you. that's why and how there are so many pure rust wasm frameworks.
Interesting take
JavaScript is only “alive and well” because they don’t want to give us direct access to the DOM. That’s the only reason JavaScript is still relevant in the browser.
who is "they"?
@@awesome-codingKanye West reference
@@trumpetpunk42I won't say what race, what people, "they" are... It was a Jewish "they"
2024 is for Go 💙
Rust
@@typicalhogI share the sentiment (i do too prefer rust) but it seems like 2024 will be equaly great for both. If we can trust the Jetbrains survey, both Go and Rust have the highest expected growth rates based on the intentions of surveyed developers to either learn or migrate to a new language in 2024. Rust ranked at the top at 13% and Go was a close second at 11%.
@@Y-JA Yeah, I agree! Also, I mostly dislike Go because of the garbage collector.
@@typicalhogThe performance hit of GC is very negligible for a small app or even for a pretty big scale app. If you're running discord level servers sure it will hurt but go has already optimised their GC. You're an engineer and you are tasked with picking the right tools. Not just writing code in one programming language. Go is easy as fk and it's very easy to onboard new devs to a codebase. Picks what's best for the task and leave the bickering to junior devs.
I was thinking of learning Go but I got seduced by Assembly Script
Another great contribution to the devops UA-cam community 🎉
You never fail to present something unique compared to everyone else.
Thank you so much! It really means a lot 😊
Let's *GO* 🚀
Rust is amazing. And it's great for WebAssembly.
Don't you miss out on even more type safety by doing things like js.Global().Call('alert', 'x')?
Or will it error if you mistype "alert"?
That's an amazing video, thank you
Glad you liked it! Thank you!
0:00 🌐 WebAssembly expands the scope of web development by enabling high-performance applications on the web.
1:31 🧰 WebAssembly is type safe, offering a significant improvement over JavaScript's dynamic typing.
1:45 🎯 WebAssembly serves as a compilation target for other languages, allowing developers to leverage the performance of different languages for web development.
3:07 🛠 WebAssembly enables seamless interaction with the DOM and browser APIs, enhancing web app development.
4:11 ⚡ WebAssembly offers near-native performance, making resource-intensive tasks feasible on the client-side.
5:02 📡 WebAssembly facilitates client-side computations, reducing the need for server round trips in web applications.
6:00 🖥 WebAssembly allows complex tasks like image processing to be efficiently executed in the browser, enhancing user experience.
7:31 🛡 Despite JavaScript's dominance, WebAssembly provides undeniable advantages, such as type safety and mature tooling, in web development.
C# also supports fully fledged wasm development using Blazor framework, it's pretty much usable as a web framework these days
It wasn't as performant last I checked. But I hope it's much faster now.
@@Makeshitjusbecuz it's still extremely slow. if you look at js framework benchmark it's dead last. you can feel the clunkiness.
It regularly bottoms the krausest benchmark.
Its niche is still internal business apps in my opinion, and only if you're already a C# dev shop. But in that context, I like it a lot
It's fkng slow and assembly (dlls) are huge in size.
We have gone full circle to writing vanilla js in go to gain 0.5seconds in speed 😅.
500ms is A LOT
@@TheRafark it’s all relative. It may or may not be worth it depending on what you are doing, the libraries available, your expertise with the language, and product deadline. Always use the right tool for the job.
0.5 seconds, that's amazing, what did you do?
@@TheRafarkhere I was thinking I was the only one thinking this
Awesome!
Is threading in wasm now actually supported when using go?
To block forever, usually we do: select {}
Most of the apps would do fine with just JS, the stuff that one might need this for would be audio/video/image processing. Maybe live streaming data processing, something like stocks data stream. But I can't seem to think of major use cases beyond some niche ones.
I agree with you on the short time. On the long term there is an argument to be made that a lot more stuff will be moved into the browser, and the applications will grow in complexity.
Besides JS simply being the crappiest of the languages that ever existed?
@@vitalyl1327 And yet has the most high paying jobs eh.
I have begun to see web assembly as a means to reduce compute costs for actions that are traditionally done in a server. We are thinking to offload some data computation for our data intensive dashboards to WASM on the client's browser itself. The server would just stream the data and all processing can be done by them locally.
Did you have any success with this? I want to do the same for my dashboard as I've a lot of computationally expensive tasks that I think might give me performance improvements if I do them with WASM
Workers might be a better option. WASM can be laggy user experience for heavy computation, especially on mobile.
the problem with Go's WASM is the size and it does not compile CGo to WASM.
To be fair, the equivalents of the last point are present in every language except probably C(++) itself, as far as I am aware.
Rust has the same issue. Kotlin does too.
I don't think Rust has this issue. It's on par with C and C++.
@@dmitriidemenev5258 while Rust, in contrast to Go, may have the capability to archive the same things as C tools, linking against C libraries while targeting WASM is not really possible, at least not without WASM specific work, which is difficult expecially if it's a dependency of a dependency - though, to be fair, probably possible, Cargo allows you to apply patches to libraries.
Be aware that this is more from heresay from library devs, and that in a quick search to confirm, I could only find workarounds such as mentioned above. Particularly the thread I remembered was on rustybuzz, in a deprecation issue (closed now).
The workarounds are of the nature of compiling both to WASM seperately and then finding a way to link them using adapters in the embedding (so mostly JS glue code).
The 2nd point MAY at some point be solved with the component model, but as is, that standard is still in development and once finished it'll probably take some time until it gets into the toolchains.
Awesome in the European version of Fireship :)
Somehow this sounds like a really bad thing :))
@@awesome-codingsounds like a compliment to me tho 🤷
Apart from the fact that there is no humour. Which is the one thing that makes fireship stand out. Good vid though
@@mangopopjuice humour is hard!! And it's even harder to make everyone watching smile / laugh
@@TechBuddy_ @mangopopjuice so you guys are implying I'm not funny?! 🥲
When I was much younger something like that was called Java applet or OCX or ActiveX
Java Applets :)) that’s a blast from the past…
But wasm supposed to run on mobile also
I am fedup with blazor WASM. It's bulky and can't compare it with react or angular.
And you here in this site with js?
Great video! The global scopes terrify me
Thank you!
Yep, I know what you mean. There are some ways to avoid the global scope with WASM and Go, but I kept it simple for demo purposes.
Will the debugging will be easy for wasm?
Yes - you have some tools you can work with.
Check out this video: ua-cam.com/video/VBMHswhun-s/v-deo.html
So to show something on a page you'll always have to use the DOM? Let's say I want to animate a bitmap image, manipulate it over time through code. I'd have to use a canvas, write code, compile it to wasm and have that binary instruct the canvas on my page, Is this correct?
Yes, at the end of the day, you need plain old HTML (Canvas is"just" an HTML element at the end of the day) do display stuff on the page.
It still need js for DOM jobs.
Maybe in the future we can make games on browsers
Uptalk uptalk uptalk
♥️
Go aint good for WA because of runtime memory footprint
AssemblyScript A TypeScript-like language for WebAssembly. No any resons to use go in front 😅
just keep in mind, vanilla js is actually 15% faster than any wasm or rust to wasm library
Are there any official stats you could share?
@@awesome-coding check js-framework-benchmark or leptos creator video The Truth about Rust/WebAssembly Performance
@@ThePandaGuitar Thanks!
Pretty messy I would say. I think doing this specific task would be easier on the server. It seems that WA makes more sense for heavier stuff like Photoshop or games.
Did you try blazor?
Can we just stop or pause the learning of new stuff … for a … while … year?
What should we do in the meantime? :))
@@awesome-coding do webdevelopement .. without the constant parallell learning process and evaluation of tools 🤪☺️
The last time I had to compile js -> wasm, the resulting code was slower.
It's possible for certain. It's a matter of use cases.
I like the burp at the end of every sentence.
😂 you guys make me really self conscious about my voice.
Can it be hosted on c-panel?
The wasm module is a static file you can host any way you like.
@@awesome-coding niceee 💕
Bro, may I know the colorthemes of your editor from this video? thanks
Hey! It's the default dark theme offered by IntelliJ IDEA.
What intellij editor, bro. thanks
@@awesome-coding
@@x0z59 www.jetbrains.com/idea/
thanks mate
@@awesome-coding
In term of WASM SPA Blazor is great
I hear only good things about .net world these days
biggest turn-off for me is binary size.
That's fair. Go is not the best example here. You'll get way better results with C or Rust.
Naa I think I will stick with Angular.
That's a good idea, especially now that Angular is really getting simpler and better.
why we still use js for gods sake
😅
Please release a go course
WASM is awesome. aWASMe 😊. Its the next incarnation of "write once, run anywhere" having learned from JVM and CLR and improved upon them. Surprisingly, it feels like it's getting more interest on the backend than the front. There are even plans to have WASM-based containers.
Ah... the good old "write once, debug everywhere" promise!
@@awesome-coding it's got to come true one day. I mean, look at Docker at what it has done for "runs the same everywhere".
Ah... all the web needed is more obfuscated stuff
Its like using a machine gun to kill fly
Isn't this the best way to do it?
@@awesome-coding This is the way
And now someone will compile bun to wasm to run js faster in the browser
😂 we've come full circle
I thought I heard a burp, but now I'm not sure. There seems to be some audio imperfections:
01:00 model
02:00 model
02:52 module
07:15 app
07:31 undeniable
Is the voice AI-generated? They seem too strange to be authentic. I think.
I came across your videos before, but haven't noticed this before.
Being curious, I took a look at the previous video and the first video. The previous one seems to have similar issues.
React 19 - This Has To Stop!
ua-cam.com/video/qSQtKtmj4M0/v-deo.html
00:38 simple
01:26 dilemma
The first video has a different voice. It's much lower and clean. Had some spikes though.
Build APIs with Spring and Kotlin
ua-cam.com/video/34r-PMOdCbA/v-deo.html
en.wikipedia.org/wiki/Vocal_fry_register
Now do kotlin multiplatform
Thank you for the suggestion! It is on the list ✌️
32 bit. It's 32 bit.
Still too complex
1:00 burp 😂
Js dev: but wait, we have a secret wepon its called *Assembly Script* Muhahaha
Glad it's not the deno channel
haha why is that?
Dont think it would be wise to replace JS in the browser.
Curious to find out why :)
It is urgent to replace JS everywhere 😅
can you make something about PHP?
It's on my list - I want to spend more time with it first, to make sure I have a good understanding of the more recent versions.
Thank you for your suggestion!
@@awesome-codinglarvel is fantastic!! And modern pho is better than php 4
Every year they said this lol
It's not gonna happen
Web is not that easy even if they could make it possible
Yea.. that' was like the first thing I joked about right when the video started...
WASM will not kill JS
JS will still be the first language to interact with the DOM
Everything else (web related) could be replaced to WASM
@@Malix_offdepends! If wasm could run standalone without any js glue code it could replace js. Also for most languages wasm is an afterthought so the final binaries are huge which is a main blocker. Dart team and the go team are working to make this better thi, we'll see where this goes
Man I had a looong comment and it disappeared into the ether lol 😂
@@awesome-coding I know I know I am just saying. It's not about what you said in the video. Just stating the fact
Const Video = yourChannelName ;
Error 404
@@alvinin oh there was a bug.
Const greatVideoResource = thisChannelName ;
wasm would be cool if they actually let us use it for mutating dom and interacting with web api. i never want to have to work with JS. I have trauma from deciding to code in JScript 20 years ago for one of my assignments. what a truly repugnant garbage
In all fairness, JS is in a better shape now (especially with TS).
really can't see such a inconvenient thing could take off at any time. It is terrible.
Come on!!! You mentioned five steps in this procedure and you three times included JavaScript to make stuff running! How this can be more performant compared to pure JavaScript in 5 lines if code? Don't be stupid... BTW, the community for WASM compared to JavaScript is pure zero!
It’s performant depending on the task, because of going through a major compiler outside of WASM’s you can take C code, Rust code, etc and use it in your project. I would recommend reading on Figma’s journey of using it. They have a js navbar in there app but the rest iirc is written in C
@blackzerosrb Are you arguing that JavaScript is more performant than WASM? 😅
@blackzerosrb probably you are an intern or never grown out from that knowledge level
I’m not a web dev but I suspect when you call stuff like “js.Global()….” that just calls the JavaScript runtime, different from “including Javascript”. The JS runtime is usually native compiled C++.