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.
@awesome-coding10 ай бұрын
Good points! Thanks for mentioning them!
@9SMTM610 ай бұрын
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.
@pokefreak211210 ай бұрын
@@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.
@pokefreak211210 ай бұрын
@@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.
@ristekostadinov282010 ай бұрын
@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.
@crab-cake10 ай бұрын
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.
@awesome-coding10 ай бұрын
Interesting take
@dameanvil9 ай бұрын
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.
@seya19945 ай бұрын
Just done PoC with wasm go, simple function weight is almost 1mb and it was slower than js. The function were just counting some basic physics things
@dmitriidemenev52589 ай бұрын
Rust is amazing. And it's great for WebAssembly.
@wlockuz446710 ай бұрын
You never fail to present something unique compared to everyone else.
@awesome-coding10 ай бұрын
Thank you so much! It really means a lot 😊
@manosragiadakos392810 ай бұрын
the problem with Go's WASM is the size and it does not compile CGo to WASM.
@9SMTM610 ай бұрын
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.
@dmitriidemenev52589 ай бұрын
I don't think Rust has this issue. It's on par with C and C++.
@9SMTM69 ай бұрын
@@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.
@henson2k10 ай бұрын
When I was much younger something like that was called Java applet or OCX or ActiveX
@awesome-coding10 ай бұрын
Java Applets :)) that’s a blast from the past…
@SirusStarTV9 ай бұрын
But wasm supposed to run on mobile also
@Bourn7710 ай бұрын
C# also supports fully fledged wasm development using Blazor framework, it's pretty much usable as a web framework these days
@Makeshitjusbecuz10 ай бұрын
It wasn't as performant last I checked. But I hope it's much faster now.
@crab-cake10 ай бұрын
@@Makeshitjusbecuz it's still extremely slow. if you look at js framework benchmark it's dead last. you can feel the clunkiness.
@Gruak710 ай бұрын
It regularly bottoms the krausest benchmark.
@orterves10 ай бұрын
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
@SirusStarTV9 ай бұрын
It's fkng slow and assembly (dlls) are huge in size.
@DoktorKumpel10 ай бұрын
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"?
@yoanhg42110 ай бұрын
We have gone full circle to writing vanilla js in go to gain 0.5seconds in speed 😅.
@TheRafark9 ай бұрын
500ms is A LOT
@yoanhg4219 ай бұрын
@@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.
@kephas-media9 ай бұрын
0.5 seconds, that's amazing, what did you do?
@kephas-media9 ай бұрын
@@TheRafarkhere I was thinking I was the only one thinking this
@bugged121210 ай бұрын
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.
@awesome-coding10 ай бұрын
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.
@vitalyl13278 ай бұрын
Besides JS simply being the crappiest of the languages that ever existed?
@bugged12128 ай бұрын
@@vitalyl1327 And yet has the most high paying jobs eh.
@StingSting8449 ай бұрын
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.
@dazzaondmic9 ай бұрын
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
@trappedcat36159 ай бұрын
Workers might be a better option. WASM can be laggy user experience for heavy computation, especially on mobile.
@Jamo0089 ай бұрын
To block forever, usually we do: select {}
@TheRafark9 ай бұрын
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.
@awesome-coding9 ай бұрын
who is "they"?
@trumpetpunk429 ай бұрын
@@awesome-codingKanye West reference
@aka58 ай бұрын
@@trumpetpunk42I won't say what race, what people, "they" are... It was a Jewish "they"
@amonmcranny26542 ай бұрын
WASM has a stack-based execution model, but what else could it be based on? Unless quantum computing is different I thought that all modern assemblies used register push/pop instructions to execute functions. Or are you saying that there are higher level languages/instruction sets that can hide push/pop operations and instead make use of e.g. global variables?
@JasonStanton-s9s9 ай бұрын
I am fedup with blazor WASM. It's bulky and can't compare it with react or angular.
@amit_go10 ай бұрын
2024 is for Go 💙
@typicalhog10 ай бұрын
Rust
@Y-JA10 ай бұрын
@@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%.
@typicalhog10 ай бұрын
@@Y-JA Yeah, I agree! Also, I mostly dislike Go because of the garbage collector.
@justafreak15able10 ай бұрын
@@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.
@kasper36910 ай бұрын
I was thinking of learning Go but I got seduced by Assembly Script
@arabculture920110 ай бұрын
Awesome in the European version of Fireship :)
@awesome-coding10 ай бұрын
Somehow this sounds like a really bad thing :))
@TechBuddy_10 ай бұрын
@@awesome-codingsounds like a compliment to me tho 🤷
@mangopopjuice9 ай бұрын
Apart from the fact that there is no humour. Which is the one thing that makes fireship stand out. Good vid though
@TechBuddy_9 ай бұрын
@@mangopopjuice humour is hard!! And it's even harder to make everyone watching smile / laugh
@awesome-coding9 ай бұрын
@@TechBuddy_ @mangopopjuice so you guys are implying I'm not funny?! 🥲
@a-bites320310 ай бұрын
Is threading in wasm now actually supported when using go?
@yogeshrathod95310 ай бұрын
Will the debugging will be easy for wasm?
@awesome-coding10 ай бұрын
Yes - you have some tools you can work with. Check out this video: kzbin.info/www/bejne/jHOweaatndqhY9U
@motoboy66669 ай бұрын
Can we just stop or pause the learning of new stuff … for a … while … year?
@awesome-coding9 ай бұрын
What should we do in the meantime? :))
@motoboy66669 ай бұрын
@@awesome-coding do webdevelopement .. without the constant parallell learning process and evaluation of tools 🤪☺️
@laas2910 ай бұрын
The last time I had to compile js -> wasm, the resulting code was slower.
@awesome-coding10 ай бұрын
It's possible for certain. It's a matter of use cases.
@pweddy15 ай бұрын
I feel like Web assembly is reinventing Java byte code. Decades after we got rid of Java applets because they weren’t safe.
@edism9 ай бұрын
Another great contribution to the devops KZbin community 🎉
@axMf3qTI10 ай бұрын
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?
@awesome-coding10 ай бұрын
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.
@aldrius0010 ай бұрын
It still need js for DOM jobs.
@justintie9 ай бұрын
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.
@angmathew43777 ай бұрын
Did you try blazor?
@sajan_paul8 ай бұрын
Go aint good for WA because of runtime memory footprint
@akinoreh10 ай бұрын
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.
@akinoreh9 ай бұрын
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! kzbin.info/www/bejne/p4S0pX6qos9ng5I 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 kzbin.info/www/bejne/aWXVXoODhMl2mKM
@eypandabear74836 ай бұрын
en.wikipedia.org/wiki/Vocal_fry_register
@lethal_larry2 ай бұрын
so where does this magic "glue" code from go come from? simply running make does not generate it, you mention nothing about it.
@x0z5910 ай бұрын
Bro, may I know the colorthemes of your editor from this video? thanks
@awesome-coding10 ай бұрын
Hey! It's the default dark theme offered by IntelliJ IDEA.
@x0z599 ай бұрын
What intellij editor, bro. thanks @@awesome-coding
@awesome-coding9 ай бұрын
@@x0z59 www.jetbrains.com/idea/
@x0z599 ай бұрын
thanks mate @@awesome-coding
@zsmain10 ай бұрын
That's an amazing video, thank you
@awesome-coding10 ай бұрын
Glad you liked it! Thank you!
@clashcon1110 ай бұрын
And you here in this site with js?
@robertcruz27752 күн бұрын
Is this video still valid, seems like web assembly became silent
@ulrich-tonmoy10 ай бұрын
In term of WASM SPA Blazor is great
@awesome-coding10 ай бұрын
I hear only good things about .net world these days
@jordanstewart22510 ай бұрын
Great video! The global scopes terrify me
@awesome-coding10 ай бұрын
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.
@Fake72179 ай бұрын
AssemblyScript A TypeScript-like language for WebAssembly. No any resons to use go in front 😅
@elhaambasheerch705810 ай бұрын
Dont think it would be wise to replace JS in the browser.
@awesome-coding10 ай бұрын
Curious to find out why :)
@ThomasSselate10 ай бұрын
It is urgent to replace JS everywhere 😅
@djcaesar9114Ай бұрын
Sorry but I really can't see any motivation for me as a web developer. What am I missing?
@awesome-codingАй бұрын
It's fun, it is fairly well paid, there is a low barrier of entry, and it is all disappearing quickly because of AI :)
@browaruspierogus21827 ай бұрын
why we still use js for gods sake
@awesome-coding7 ай бұрын
😅
@salman0ansari10 ай бұрын
biggest turn-off for me is binary size.
@awesome-coding10 ай бұрын
That's fair. Go is not the best example here. You'll get way better results with C or Rust.
@hurb91889 ай бұрын
Maybe in the future we can make games on browsers
@licokr10 ай бұрын
Awesome!
@FzsHotDogInDonut10 ай бұрын
Can it be hosted on c-panel?
@awesome-coding10 ай бұрын
The wasm module is a static file you can host any way you like.
@FzsHotDogInDonut10 ай бұрын
@@awesome-coding niceee 💕
@grinsk3ks10 ай бұрын
And now someone will compile bun to wasm to run js faster in the browser
@awesome-coding10 ай бұрын
😂 we've come full circle
@AchwaqKhalid10 ай бұрын
Let's *GO* 🚀
@genomexp9 ай бұрын
Uptalk uptalk uptalk
@fishxsea9 ай бұрын
I like the burp at the end of every sentence.
@awesome-coding9 ай бұрын
😂 you guys make me really self conscious about my voice.
@TheTimeProphet9 ай бұрын
Naa I think I will stick with Angular.
@awesome-coding9 ай бұрын
That's a good idea, especially now that Angular is really getting simpler and better.
@ThePandaGuitar6 ай бұрын
just keep in mind, vanilla js is actually 15% faster than any wasm or rust to wasm library
@awesome-coding6 ай бұрын
Are there any official stats you could share?
@ThePandaGuitar6 ай бұрын
@@awesome-coding check js-framework-benchmark or leptos creator video The Truth about Rust/WebAssembly Performance
@awesome-coding6 ай бұрын
@@ThePandaGuitar Thanks!
@naninano88139 ай бұрын
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
@awesome-coding9 ай бұрын
In all fairness, JS is in a better shape now (especially with TS).
@fullstack428410 ай бұрын
Its like using a machine gun to kill fly
@awesome-coding10 ай бұрын
Isn't this the best way to do it?
@fullstack428410 ай бұрын
@@awesome-coding This is the way
@keshavakumar982810 ай бұрын
Please release a go course
@dionysis_9 ай бұрын
1:00 burp 😂
@Bond-zj2ku9 ай бұрын
Const Video = yourChannelName ;
@alvinin9 ай бұрын
Error 404
@Bond-zj2ku9 ай бұрын
@@alvinin oh there was a bug. Const greatVideoResource = thisChannelName ;
@robchr9 ай бұрын
Now do kotlin multiplatform
@awesome-coding8 ай бұрын
Thank you for the suggestion! It is on the list ✌️
@MagicNumberArg10 ай бұрын
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.
@awesome-coding10 ай бұрын
Ah... the good old "write once, debug everywhere" promise!
@MagicNumberArg10 ай бұрын
@@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".
@zoladkow9 ай бұрын
Ah... all the web needed is more obfuscated stuff
@minor128289 ай бұрын
Still too complex
@kasper36910 ай бұрын
Js dev: but wait, we have a secret wepon its called *Assembly Script* Muhahaha
@James-l5s7k8 ай бұрын
32 bit. It's 32 bit.
@mlvki10 ай бұрын
can you make something about PHP?
@awesome-coding10 ай бұрын
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!
@TechBuddy_10 ай бұрын
@@awesome-codinglarvel is fantastic!! And modern pho is better than php 4
@msahu259510 ай бұрын
♥️
@evccyr10 ай бұрын
Glad it's not the deno channel
@awesome-coding10 ай бұрын
haha why is that?
@namaefumei10 ай бұрын
Every year they said this lol It's not gonna happen Web is not that easy even if they could make it possible
@awesome-coding10 ай бұрын
Yea.. that' was like the first thing I joked about right when the video started...
@Malix_Labs10 ай бұрын
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
@TechBuddy_10 ай бұрын
@@Malix_Labsdepends! 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
@TechBuddy_10 ай бұрын
Man I had a looong comment and it disappeared into the ether lol 😂
@namaefumei10 ай бұрын
@@awesome-coding I know I know I am just saying. It's not about what you said in the video. Just stating the fact
@eygs4935 ай бұрын
i like your image example
@yifeiren80049 ай бұрын
really can't see such a inconvenient thing could take off at any time. It is terrible.
@IAmOxidised75253 ай бұрын
rust
@zlackbiro10 ай бұрын
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!
@ApodicticScott10 ай бұрын
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
@awesome-coding10 ай бұрын
@blackzerosrb Are you arguing that JavaScript is more performant than WASM? 😅
@EdwinManual10 ай бұрын
@blackzerosrb probably you are an intern or never grown out from that knowledge level
@eypandabear74836 ай бұрын
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++.