There are some points brought up in the comments that I want to highlight. 1. The biggest one is that WebAssembly isn't *always* faster than JS. 2. Since V8 came out for chrome, it might not be using a JS interpreter anymore and uses a JIT compiler? (i think) 3. WASM code isn't run directly by a computer, it still has to go through some sort of "interpreter" or "compiler" that turns it into the correct binary for each system. So there's still some process going on, it's not just a complete elimination of a step. Thank you to all the comments addressing these!
There are some languages that compile to WASM but by no means do "all" languages compile to WASM. Just because WASM has a binary representation doesn't mean that it executes directly. In fact, the WASM rep needs to be translated into assembly instructions when it's loaded. That's faster than interpreting JS for sure but WASM's "binary" is not the same as native apps "binary." And finally, while WASM has the potential to be faster than JS over time, currently benchmarks are mixed.
@@tadaspetra No it doesn't. The WASM binary format is not processor or OS specific so it first has to be translated for the specific computer when its downloaded.
Sorry but this has some bad potential for people that would like to learn stuff, so I'll be harsh. If you don't know about what you are talking about, better not talk about it. 1 - WA isn't a replacement for JS, it is a solution for low-level performance critic code. It is made to used with JS, not replace it. 2 - JS *was* a interpreted language, it isn't since V8 came out, that's almost 15 years ago. Since that time, nearly all major javascript engines influenced by it. V8 is not an interpreter (a program that parses code and runs it line by line), it is a just in time compiler. It does compile stuff at the time of execution, has different levels of optimization. At first, it does compile the code quickly as possible, later collect data by examining how it works, and optimize it further. It is so optimized, nowadays it usually elides function calls in higher order functions like forEach, map, reduce etc. This is the reason why NodeJS is a thing *after* V8 came out, because it uses V8 internally. 3 - WA isn't faster than JS, in generic use. JS can output same performance as C++ while looping arrays or editing consistent data structures (though adjusting those structures is some kind of different beast). Main advantage of WA is about performance is, JS doesn't allow any low-level input from you, while WA does. So you can design your own structs and specific data types, optimize them by your own. But that doesn't mean WA is always faster, it is just faster in specific cases. One main example is photo editing software. Having access to low-level stuff allows you to optimize as you fit rather than JS engine guessing what is needed. 4 - WA isn't assembly, that's simply impossible because assembly can have differences between processors. It is just another layer of abstraction, an intermediate language, just like assembly, which converts to assembly rather than machine code. 5 - WA doesn't replace HTML or CSS, that's de jure and de facto way of building webpages. WA was using JS to change the DOM, but something was going to be implemented for WA for that purposes, not sure on current state of it. That being said, you are probably mixing what WebGPU is into WA. While they are *related* projects and can benefit from eachother, they are not the same thing. WebGPU is replacement for WebGL, which is used with canvas HTML element for custom low-level rendering instead of using HTML and CSS. What it does is, it allows stuff like games or custom applications that doesn't use HTML and CSS. If one uses WebGPU, they can make games, or their websites without using HTML and CSS. If your application is something like a usual website, then that would hit your SEO for sure. Bu that's not WA. So, let's talk about what is WA then: 1 - Allows specific low-level optimization for specific cases. 2 - Designed to be used with JS, not replacement of it. Though one can use it without ever touching JS (not sure if possible as of today, but that should be in future iirc). 3 - Allows to be compiled from different languages, so you can bring your favourite language and libraries and work with them (though there are major exceptions due to sandboxness of it). 4 - As you stated, it isn't just for web, it can be used anywhere where sandboxness is needed. One primary example is modding of games.
And I appreciate the corrections. I am always trying to learn more and make sure I have the correct information. But sometimes with my weekly schedule I miss some things. I appreciate you keeping me in check.
I hope its syntax won't as assambly (the lang before binary) might as well at that point learn binary and no compiler/ third party software needed and well its only 01 but in pattarns , now with the joks aside , looking forward to see webassambly progression i hate js "dinamic" syntax"
This video would make sense before V8 and chrome, but nowdays all engines have JIT that will kill most of performance gains you could hope to get from WASM. It is completely pointless to use wasm to replace javascript to build app, you should focus on specific problems that actuslly run too slow in javascript, and then try te get it working faster in WASM.
one thing to mention here is that through the explanation you did, you said that there will be only one step that will be changed which is the JS interpreter, but why is this related to SEO? AFAIK SEO will check HTML content in the first indexing wave, and will check for the second indexing wave when there is a rerendering action, can you clarify this point? (the second wave of indexing is being done after rerendering which means that shouldn't be affected by the used language correct me if I'm wrong) Thanks for that useful content. Ref JS SEO: ua-cam.com/play/PLKoqnv2vTMUPOalM1zuWDP9OQl851WMM9.html
There are some points brought up in the comments that I want to highlight.
1. The biggest one is that WebAssembly isn't *always* faster than JS.
2. Since V8 came out for chrome, it might not be using a JS interpreter anymore and uses a JIT compiler? (i think)
3. WASM code isn't run directly by a computer, it still has to go through some sort of "interpreter" or "compiler" that turns it into the correct binary for each system. So there's still some process going on, it's not just a complete elimination of a step.
Thank you to all the comments addressing these!
There are some languages that compile to WASM but by no means do "all" languages compile to WASM.
Just because WASM has a binary representation doesn't mean that it executes directly. In fact, the WASM rep needs to be translated into assembly instructions when it's loaded. That's faster than interpreting JS for sure but WASM's "binary" is not the same as native apps "binary."
And finally, while WASM has the potential to be faster than JS over time, currently benchmarks are mixed.
So the WASM code doesn't get run directly? Is there like a WASM Interpreter or something like that?
@@tadaspetra No it doesn't. The WASM binary format is not processor or OS specific so it first has to be translated for the specific computer when its downloaded.
Hi. Is there a way to escape writing CSS completely? I mean manage UI using wasm?
Awesome content! Thanks for sharing
Thank you so much! I really appreciate it Pedro 😊
I like the new videos! Keep it up, looking forward to learning more
Thank you so much. I enjoy making these new ones a lot more
How come that Edge is built on Chromium but somehow uses another rendering engine that is not V8?
Honestly, I have no idea
Loved the explanation 👏🔥🙌
Thank you Rivaan!
Sorry but this has some bad potential for people that would like to learn stuff, so I'll be harsh. If you don't know about what you are talking about, better not talk about it.
1 - WA isn't a replacement for JS, it is a solution for low-level performance critic code. It is made to used with JS, not replace it.
2 - JS *was* a interpreted language, it isn't since V8 came out, that's almost 15 years ago. Since that time, nearly all major javascript engines influenced by it. V8 is not an interpreter (a program that parses code and runs it line by line), it is a just in time compiler. It does compile stuff at the time of execution, has different levels of optimization. At first, it does compile the code quickly as possible, later collect data by examining how it works, and optimize it further. It is so optimized, nowadays it usually elides function calls in higher order functions like forEach, map, reduce etc. This is the reason why NodeJS is a thing *after* V8 came out, because it uses V8 internally.
3 - WA isn't faster than JS, in generic use. JS can output same performance as C++ while looping arrays or editing consistent data structures (though adjusting those structures is some kind of different beast). Main advantage of WA is about performance is, JS doesn't allow any low-level input from you, while WA does. So you can design your own structs and specific data types, optimize them by your own. But that doesn't mean WA is always faster, it is just faster in specific cases. One main example is photo editing software. Having access to low-level stuff allows you to optimize as you fit rather than JS engine guessing what is needed.
4 - WA isn't assembly, that's simply impossible because assembly can have differences between processors. It is just another layer of abstraction, an intermediate language, just like assembly, which converts to assembly rather than machine code.
5 - WA doesn't replace HTML or CSS, that's de jure and de facto way of building webpages. WA was using JS to change the DOM, but something was going to be implemented for WA for that purposes, not sure on current state of it. That being said, you are probably mixing what WebGPU is into WA. While they are *related* projects and can benefit from eachother, they are not the same thing. WebGPU is replacement for WebGL, which is used with canvas HTML element for custom low-level rendering instead of using HTML and CSS. What it does is, it allows stuff like games or custom applications that doesn't use HTML and CSS. If one uses WebGPU, they can make games, or their websites without using HTML and CSS. If your application is something like a usual website, then that would hit your SEO for sure. Bu that's not WA.
So, let's talk about what is WA then:
1 - Allows specific low-level optimization for specific cases.
2 - Designed to be used with JS, not replacement of it. Though one can use it without ever touching JS (not sure if possible as of today, but that should be in future iirc).
3 - Allows to be compiled from different languages, so you can bring your favourite language and libraries and work with them (though there are major exceptions due to sandboxness of it).
4 - As you stated, it isn't just for web, it can be used anywhere where sandboxness is needed. One primary example is modding of games.
Thank you for this comment, I learned a lot.
I brought up the key points and added them to a pinned comment so that people will see it.
@@tadaspetra Thanks, I just really don't like missing/wrong information for materials like these. Happy to see that you've made your corrections
And I appreciate the corrections. I am always trying to learn more and make sure I have the correct information. But sometimes with my weekly schedule I miss some things.
I appreciate you keeping me in check.
Great video! I look forward for the next explanation videos :)
Awesome, thank you!
The Microsoft Edge joke 🤣😂🤣
curious if flutter web would be able to translate to wasm... ;) great explanation! thks!
It does! It uses webassembly under the hood
@@tadaspetra cool, thought it's JS. thks for clarifying.
@@tadaspetra do you have any site reference for that?
But. There are two Butts.. lol
Great short video bro
thank you!
I hope its syntax won't as assambly (the lang before binary) might as well at that point learn binary and no compiler/ third party software needed and well its only 01 but in pattarns ,
now with the joks aside , looking forward to see webassambly progression i hate js "dinamic" syntax"
This video would make sense before V8 and chrome, but nowdays all engines have JIT that will kill most of performance gains you could hope to get from WASM. It is completely pointless to use wasm to replace javascript to build app, you should focus on specific problems that actuslly run too slow in javascript, and then try te get it working faster in WASM.
Thank you for bringing this up. I addressed it in a pinned comment. And your recommendation seems to be a good one
interesting
thanks for sharing your knowledge
Thanks for watching Sam
one thing to mention here is that through the explanation you did, you said that there will be only one step that will be changed which is the JS interpreter, but why is this related to SEO? AFAIK SEO will check HTML content in the first indexing wave, and will check for the second indexing wave when there is a rerendering action, can you clarify this point? (the second wave of indexing is being done after rerendering which means that shouldn't be affected by the used language correct me if I'm wrong)
Thanks for that useful content.
Ref JS SEO: ua-cam.com/play/PLKoqnv2vTMUPOalM1zuWDP9OQl851WMM9.html