Was WASM actually promised as a solution to performance problems in the browser? I always thought it was just meant to be a way to run code written in languages other than JS inside the browser. WASM itself doesn't have access to the DOM and still relies on JS bindings to modify the DOM, so wouldn't it be more performant to stay within the context of JS instead of needing to interop with another bytecode?
Regarding the latter part of your comment: I think Blazor (C#) basically ships WASM and interops with JS for the DOM API. They probably wouldn't do this if it was slower. I guess for very simple render processing calling a WASM module would be slower, but i bet that for many web apps out there written in React etc. it would be faster because the DOM isn't necessarily the slow part anymore. React popularized using a VDOM which is a massive reduction in DOM calls compared to what tools did before. And regardless of if you accelerate using a VDOM or VDOM-less like Solid.js or Svelte, i'm confident that they MIGHT be faster with WASM - it's just a MASSIVE amount of work and MUCH worse DX.
Yes, I suppose this was the reason for it, to use libs and code not written in JS, in the browser. Though, just as you have webAPIs querying and exposing browser capabilities, you could have something similar for hardware, some kind of WASM API querying and exposing OS capabilities. And yeah, native code meant for this or that specific hardware is always gonna be faster than any JS interpreting engine. WASM will win over JS, since not only there won't be any specific reason to pick JS, your capabilities on what you can and cannot do are gonna increase to near native level programs, and as a bonus, it's gonna run faster regardless of your lang of choice.
@@FunctionGermanyBlazor is slower compared to pretty much all solutions, but it does the job and well, most C# guys focus more on the business part and don't care if the app takes 3 seconds to load Most devs that I met that use blazor like it a lot
@@rawallon how would you know where to put the console.log lines in your JS (or even TS) file? imagine a world where people are writing typescript, which they're transpiling to javascript, which is being compiled to wasm, which is being ran in the browser. if something breaks, unless you have an innate understanding of wasm (which i certainly don't, and i don't mind reading x86_64 asm...), you better hope you have the source map for wasm -> js and the source map from js -> ts...
@@wi1h Your mom jokes aside, this exact "problem" is kind of, well, not real. The only problem is that the tools for debugging aren't up to snuff yet. C has had advanced linting and debugging for its static compilation targets for decades, JavaScript has literally never had a static compilation target until the past few years. These situations are not the same. If you want advanced debugging features for a statically-compiled javascript or typescript, then just wait for the tools to make it happen to become more advanced, and if you need it now, then make it (if you have the means to do so). The problem isn't that it's bad, the problem is that it's new. I for one will continue using a language which was designed for static compilation (i.e. Rust) for WASM until such time that the tools in question are in a good state, and it all starts with making the js to WASM compiler.
@@TressaDanvers seems like the problem is very real for the time being. you can say any problem will be fixed in the future, that doesn't mean it isn't a problem now
I constantly checking the state of wasm every year and i wrote some complex wasm apps in the past. Almost every time i tried the new technology, i came to the same conclusion: 1) rust is currently the best solution to get decent glue code and small sized wasm. It looks like it will not change until native GC support will be included 2) wasm and all compilers / frameworks etc. are lacking in developer tools or lets say not lacking: it could be better. That for, i think if the tech. chain is smaller less cross compilation etc. it helps a lot. 3) also the glue code is important, i mean compiling to wasm is one thing but writing glue code by yourself or not getting a viable one is a pain in the a***. Just my opinion and experience.
What I expected, when WASM come out, WASM can perform DOM operation as Javascript. Convert all the bulky JS into small and beautiful WASM binary. Until now, WASM is nothing changed. Very Disappointed.
If you're hoping for small WASM binaries, you're always going to be disappointed. In my experience, most WASM binaries are bigger than the equivelent js code, which you would expect for a low level vs high level language.
I love how you pronounce Hermes like the fashion brand Hermès 😂 It's actually named after the greek patron god of merchants, thieves, and travelers. They even named the Garbage Collector "Hades", the greek god of the underworld/dead as it cleans up all the "dead" memory... lol
A good example of when I'd use WASM today is with the Rapier physics engine. There's also a wrapper for react-three/fiber which integrates it really well.
One thing that's interested me about Porfor is, you get to control the execution in a way that you can't really in current JS runtimes, in a web app you can eval() and that code can run for as long as it wants. Sure you can put code in a Worker and stop it then, but you can't, say, intercept a call to alert() and have it behave the same way as it would if it went directly to the browser (i.e. you can't synchronously wait for something to happen in JS)
AssemblyScript doesn't allow plain js, and relies on types for compilation. It also has its own standard library, compared to porffor which implements javascript's
Try to pass array to assembly script and get it modified back. It will be slower than vanilla js... Time loss happen when it passes array between js and wasm.
WASM is really cool tech and I get so excited every time I see any developments in the WASM world because it has so much potential. That said, if you can run any language in the browser why JavaScript , like I get you still need JS for DOM manipulation but if you cause anything but JavaScript - why don't you. This feels like it take a problem WASM has and makes it worse
Blazor now supports server side components rendered with wasm. The memory management is probably a workload on the server being expensive but consumers will have a smooth experience that also supports typescript. Techempower has C# as one of the fastest languages to make API’s
server side components + WASM? what do you need WASM for when the server does the rendering? i thought blazor uses WASM for CSR - that's the only usage that makes sense to me.
Blazor actually works pretty nice in WASM. About the only bad thing about its implementation, is that the code is, well, trivial to decompile as dlls are sent to the browser - but there wasn't really a way around that. So you have to be extra careful of not storing secrets nor proprietary code there. That in combination with Blazor united / hybrid works beautifully for those scenarios where you want to server some static content while the rest of the application is being downloaded.
I kinda hate the entre JS runtime thing. First we ended up with thousands of frameworks, each incompatible with the others. Now we're effectively ending up with 5+ different JS flavours, simply because these new runtimes are popping up like mushrooms after a rainy day. One runtime would handle buffers its own way, another would handle connections and sockets differently, yet another will handle cryptography and compression differently and omg why did I go for JS and not something else...
WASM just physically can't be faster than JS compiler by V8, the only way to make it faster is to change how js works, perhaps by introducing real data structure and preventing you to append whatever to any object, only a subset of js can be faster than js.
You're running JS locally while running the WASM either on their servers or the browser. You should measure time under the same environment and same conditions.
@@theairaccumulator7144 but inside chrome it's running under chrome, outside of chrome it's running native no? Anyways, I would still do it to be super safe before I make any conclusions haha.
At first I was like "HA, another way to use WASM for CRUD apps! LAWL! Way to bring an uzi to a knife fight!" ... But really those memory usage and binary size gains are nothing to sneeze at. 🤔
If done right, this could have far better perf in cases where you have lots of "cold" code, where JIT would take a while to kick in. A simple for loop would not be much faster.
4:13 doesn't v8 automatically detect hot code (the isPrime function) and compile it further to "machine code"? i'm pretty sure that's the case, and if so, microbenchmarks like this probably don't showcase the power of porffor/js-to-wasm as much as most normal code bases would benefit
this is...just an uninformed take. No matter what, things like image manipulation, audio processing, games, low-level management of primitives like strings, etc. will always be slower and use more memory in JS. Memory usage is a big one, as JS' garbage collection implementation means you can only optimize it so far.
@@PraiseYeezus OP really needed to add ".. when used for the intended purpose" to their statement, agreed. Blazingly fast might be a stretch, but it is pretty decent & the skill issue aspect is valid.
The beginning example doesn't seem optimized to me, in terms of the WASM generated. The compiler accepts optimization switches. Though adding -O3 didn't help much. It does seem like it's running on their servers as the performance I'm getting is near identical to your's. But still for whatever reason number is an f64, while in fact it will never be a float. So it should be an i32 or i64. As it doesn't seem to work on typescript, it must be up to the compiler to determine what should be which type. Number has no business being a float.
All numbers in javascript are doubles (not including bigint). that is a possible opportunity for optimization though (determining what numbers never have decimals and optimizing into an integer type). v8 does that
The advantage of WASM is not in such simple programs - it's in advanced compile time optimizations. Ask C devs how different gcc is performance wise compared to the '90s. Yes, we have AoT, but it is always a trade off - if we can do all the static analysis at compile time then it is a pure gain.
Shouldn't ts -> wasm be faster than js -> wasm because of how you optimize with static types? Sounds like a natural progression with ts -> wasm throwing out the intermediate js. I get that's not what or why porffor, but as a general idea?
I do not ever see this working as a wide scale "just compile all JS to WASM" solution. The reason is that JS is full of all those WAT-style weidnesses around its operators and the variety of parameters they can take. You just don't know how much JS code may depend on some non-obvious behavior of the language. The code Perffor is producing (isPrime for example) is very numeric centric. Pass in a string or a null and that code will not behave the same as it did in JS. So, to truly make a function behave the same, you have to pepper your WASM with all the conditionals to emulate all that stuff, which would slow it back down to JS levels or probably even slower.
We've had quick.js for this for ages, how is this different? Pure JS implementation vs a C implementation, but I'm not sure that works in its favor? Also has "WIP" and "unstable" all over the porffor readme, doesn't seem anywhere close to being ready for prime time.
quick.js is an interpreter, so if you use it to run javascript as wasm, you have to bundle the whole quick.js runtime porffor does that ahead of time, so it doesn’t need all the bloat of a whole interpreter
Hold on .... when the javascript runtime is causing node.js to consume so much memory, why doesn't node.js have a mode that unloads all the interpreting and compiling stuff after it is done interpreting my javascript?
I think it's unfortunate that WASM got stuck with the component-model and interface-type proposals that would have allowed WASM to be a true JS replacement. The current state where you have to access the DOM via JS is a bit unfortunate, but performance-wise there are libraries like leptos that come very close to native JS. The most promising use case for WASM today is using WASM as a secure (and more portable) alternative to containers. Especially for edge use cases, WASM can scale much faster while being much more secure compared to bulky container images. The Kubernetes community is pushing WASM very hard for this, and with projects like WASI solving the I/O situation, it could be a good replacement for 80% of all containers.
WasmGC is what you are looking for as a JS replacement. It offers strongly statically typed garbage collected high level types that it interacts with and passes around, even into JS and back. Now is the perfect time for a language to take advantage of this and truly seemlessly integrate it into the JS ecosystem. In fact there is a TypeScript to WasmGC compiler which technically competes with Porfor, that isn‘t mentioned in the video.
WASM, with all its hype and interest, is moving really slow.It's far from a practical target for a lot of languages and frameworks yet. I don't think we necessarily need to support higher level features that are in JS, and it's understandable that it will always be a poor choice for dynamic languages but at least support calling the browser APIs, garbage collection, and finish the work on Interface Types. Until then, I don't see people deploying any web apps in WASM.
Is wasm a way to avoid someone stealing your code? Javascript nowadays is a serious programming language, the only thing that stop me to going pro is bc someone can steal all your files, so im thinking to go full kotlin multiplatfom.. in 3 months
@@QWERTIOXAll the browser engines essentially already internally lower JS to Wasm (or rather the same internal byte code, with Wasm being a stable shortcut to it), so doing it yourself achieves nothing meaningful for performance.
I have multiple videos about why it's good to be "behind" the curve. I'm relatively late to actually adopting new stuff, I just get excited and like sharing that excitement :)
WASM wasn't designed to address performance issues. It wasn't designed to enable other languages. It was designed as obfuscation and copy/paste barrier of corporate code, everything else is a coincidental feature, or rather clever phrasing to hide the intent.
@@cormickholland3855 "Design" the noun vs "to design" as verb. Think of it this way, there are design goals that are set at the start of project and might shift during a project. Then there's the process of implementing a design, which can influences the outcome and might not match the initial goals. Matching standing design goals exactly is sometimes extremely hard, or during implementation of a design goals turn out to be nonsensical. So the implementation of a design is as much part of design as the definitions of the design goals. So if you look at the current state of the implementation of the design, you notice the most often mention and criticized lack of DOM interoperability, but also the somewhat cumbersome JS interface. So I'm not implying malicious intent, just by judging the current state of WASM, it really serves the case of obfuscation a lot better than the case of JS equivalent runtime. Now go and check the WASM community chairs, and notice their affiliations. Now think about how consensus among such committees generally works and the power chairs hold over the consensus process just by personality alone. And because all people hold biases now you can see how certain biases in design goals and implementation could happen even completely without malicious intent.
Most webdev use js, but what's the issue? If another language is better, they will need to adapt and learn a new language, not a big deal If they only can use js because they only did a 6 months bootcamp, that's a different story
Personally, I think wasm is a huge disappointment. I'd rather see Java make a resurgence as a browser language over ever using wasm. Although, we should have a runtime like Java built into the browser and having multiple languages should be no problem. We just need a VM that is more open for usage and not actually the JVM. In fact, if the web browser was just a glorified renderer for some VM-based language, we'd be far better off.
The fact that you are benchmarking the log rather than the actual prime logic is triggering 🫠 (this is the whole point of using this custom porffor func instead of log)
Was WASM actually promised as a solution to performance problems in the browser? I always thought it was just meant to be a way to run code written in languages other than JS inside the browser. WASM itself doesn't have access to the DOM and still relies on JS bindings to modify the DOM, so wouldn't it be more performant to stay within the context of JS instead of needing to interop with another bytecode?
Regarding the latter part of your comment: I think Blazor (C#) basically ships WASM and interops with JS for the DOM API. They probably wouldn't do this if it was slower. I guess for very simple render processing calling a WASM module would be slower, but i bet that for many web apps out there written in React etc. it would be faster because the DOM isn't necessarily the slow part anymore. React popularized using a VDOM which is a massive reduction in DOM calls compared to what tools did before. And regardless of if you accelerate using a VDOM or VDOM-less like Solid.js or Svelte, i'm confident that they MIGHT be faster with WASM - it's just a MASSIVE amount of work and MUCH worse DX.
I think it’s more for doing less dom intensive workloads like video decoding where js might struggle
Yes, I suppose this was the reason for it, to use libs and code not written in JS, in the browser. Though, just as you have webAPIs querying and exposing browser capabilities, you could have something similar for hardware, some kind of WASM API querying and exposing OS capabilities. And yeah, native code meant for this or that specific hardware is always gonna be faster than any JS interpreting engine. WASM will win over JS, since not only there won't be any specific reason to pick JS, your capabilities on what you can and cannot do are gonna increase to near native level programs, and as a bonus, it's gonna run faster regardless of your lang of choice.
@@FunctionGermanyBlazor is slower compared to pretty much all solutions, but it does the job and well, most C# guys focus more on the business part and don't care if the app takes 3 seconds to load
Most devs that I met that use blazor like it a lot
WASM was never meant to be promised as a solution to performance problems inside the browser, but it was hyped as such.
Debugging that pipeline would be a nightmare
Why? Do you guys not have console.log?
@@rawallon how would you know where to put the console.log lines in your JS (or even TS) file? imagine a world where people are writing typescript, which they're transpiling to javascript, which is being compiled to wasm, which is being ran in the browser. if something breaks, unless you have an innate understanding of wasm (which i certainly don't, and i don't mind reading x86_64 asm...), you better hope you have the source map for wasm -> js and the source map from js -> ts...
@@wi1h Like this:
.log('im calling ur mom')
res = mom()
.log('ur mom gave me ', res)
@@wi1h Your mom jokes aside, this exact "problem" is kind of, well, not real. The only problem is that the tools for debugging aren't up to snuff yet. C has had advanced linting and debugging for its static compilation targets for decades, JavaScript has literally never had a static compilation target until the past few years. These situations are not the same. If you want advanced debugging features for a statically-compiled javascript or typescript, then just wait for the tools to make it happen to become more advanced, and if you need it now, then make it (if you have the means to do so). The problem isn't that it's bad, the problem is that it's new. I for one will continue using a language which was designed for static compilation (i.e. Rust) for WASM until such time that the tools in question are in a good state, and it all starts with making the js to WASM compiler.
@@TressaDanvers seems like the problem is very real for the time being. you can say any problem will be fixed in the future, that doesn't mean it isn't a problem now
I constantly checking the state of wasm every year and i wrote some complex wasm apps in the past. Almost every time i tried the new technology, i came to the same conclusion: 1) rust is currently the best solution to get decent glue code and small sized wasm. It looks like it will not change until native GC support will be included 2) wasm and all compilers / frameworks etc. are lacking in developer tools or lets say not lacking: it could be better. That for, i think if the tech. chain is smaller less cross compilation etc. it helps a lot. 3) also the glue code is important, i mean compiling to wasm is one thing but writing glue code by yourself or not getting a viable one is a pain in the a***. Just my opinion and experience.
What I expected, when WASM come out, WASM can perform DOM operation as Javascript. Convert all the bulky JS into small and beautiful WASM binary. Until now, WASM is nothing changed. Very Disappointed.
If you're hoping for small WASM binaries, you're always going to be disappointed. In my experience, most WASM binaries are bigger than the equivelent js code, which you would expect for a low level vs high level language.
@@aenguswright7336 you might want to try actually watching the video
@@aenguswright7336 enter porffor.
DOM access requires garbage collection and that is in the works for WebAssembly for quite some time.
@@CoDEmanX47 DOM access is like the least important reason to use WASM
I love how you pronounce Hermes like the fashion brand Hermès 😂
It's actually named after the greek patron god of merchants, thieves, and travelers.
They even named the Garbage Collector "Hades", the greek god of the underworld/dead as it cleans up all the "dead" memory... lol
A good example of when I'd use WASM today is with the Rapier physics engine. There's also a wrapper for react-three/fiber which integrates it really well.
Why did I read the title as "por favor"? As in Spanish for please compile your JS to WASM 😅
I read it as "porffor", and the logo was purple, so they weren't lying (atleast in Welsh)
One thing that's interested me about Porfor is, you get to control the execution in a way that you can't really in current JS runtimes, in a web app you can eval() and that code can run for as long as it wants. Sure you can put code in a Worker and stop it then, but you can't, say, intercept a call to alert() and have it behave the same way as it would if it went directly to the browser (i.e. you can't synchronously wait for something to happen in JS)
this is made by someone I was in the same corp with in the game hackmud
Restart the clock. But also very cool
canadahonk is unbelievably cracked
This is something I've been aspiring to work on.
Good job Porffor team 👏🏽👏🏽
The thought of getting to choose an area within your 2d chart in a project sounds great! Different pros/cons to weigh for your best version of an app
I can see Figma investing in this fast
What about AssemblyScript
Yep, I'd rather have some control of my types
nvm it supports TS apparently, although AssemblyScript gives better control for specific number types
AssemblyScript doesn't allow plain js, and relies on types for compilation. It also has its own standard library, compared to porffor which implements javascript's
Try to pass array to assembly script and get it modified back. It will be slower than vanilla js... Time loss happen when it passes array between js and wasm.
What a cool name, Cymru! 🏴
WASM is really cool tech and I get so excited every time I see any developments in the WASM world because it has so much potential. That said, if you can run any language in the browser why JavaScript , like I get you still need JS for DOM manipulation but if you cause anything but JavaScript - why don't you. This feels like it take a problem WASM has and makes it worse
Blazor now supports server side components rendered with wasm. The memory management is probably a workload on the server being expensive but consumers will have a smooth experience that also supports typescript. Techempower has C# as one of the fastest languages to make API’s
server side components + WASM? what do you need WASM for when the server does the rendering? i thought blazor uses WASM for CSR - that's the only usage that makes sense to me.
Blazor actually works pretty nice in WASM. About the only bad thing about its implementation, is that the code is, well, trivial to decompile as dlls are sent to the browser - but there wasn't really a way around that. So you have to be extra careful of not storing secrets nor proprietary code there.
That in combination with Blazor united / hybrid works beautifully for those scenarios where you want to server some static content while the rest of the application is being downloaded.
The WASM that was promised...
I kinda hate the entre JS runtime thing.
First we ended up with thousands of frameworks, each incompatible with the others.
Now we're effectively ending up with 5+ different JS flavours, simply because these new runtimes are popping up like mushrooms after a rainy day.
One runtime would handle buffers its own way, another would handle connections and sockets differently, yet another will handle cryptography and compression differently and omg why did I go for JS and not something else...
I want to be able to build in WASM without having to use any JS anywhere at all!
You can certainly do that...
Blazor:)
wasmtime
Can do that with any llvm language
@@jonas2955 is it just me that sees wasmtime and thinks of MC Hammer?... stop.. wasmtime
WASM just physically can't be faster than JS compiler by V8, the only way to make it faster is to change how js works, perhaps by introducing real data structure and preventing you to append whatever to any object, only a subset of js can be faster than js.
You're running JS locally while running the WASM either on their servers or the browser. You should measure time under the same environment and same conditions.
Chrome and Node use the same engine so it's going to be similar
@@theairaccumulator7144 but inside chrome it's running under chrome, outside of chrome it's running native no? Anyways, I would still do it to be super safe before I make any conclusions haha.
At first I was like "HA, another way to use WASM for CRUD apps! LAWL! Way to bring an uzi to a knife fight!"
... But really those memory usage and binary size gains are nothing to sneeze at. 🤔
The StdOut to terminal is killing any actual performance margins you could observe.
Theo, hear me out next video can you try a The riddler outfit. Love the perspectives from you I watch you everyday after work to recharge
If done right, this could have far better perf in cases where you have lots of "cold" code, where JIT would take a while to kick in. A simple for loop would not be much faster.
you may concider talking about the ventoy security issue (issue 2795)
I like this kind of content, T.
What is the tool used by you for drawing things on computer, looks neat.
lol backend history bleeding through at 7:34
porffor is Welsh for purple
4:13 doesn't v8 automatically detect hot code (the isPrime function) and compile it further to "machine code"? i'm pretty sure that's the case, and if so, microbenchmarks like this probably don't showcase the power of porffor/js-to-wasm as much as most normal code bases would benefit
Hot take: JS is already blazingly fast if you’re using it properly. If your application is slow, it’s because your logic is bad.
❤️
Or you're using it for something that you probably need to be able to manually manage memory for
Yeah, yeah, I've seen this argument 10 times already in different technologies over last 25 years: "the X is not bad, you're just a poor programmer".
this is...just an uninformed take. No matter what, things like image manipulation, audio processing, games, low-level management of primitives like strings, etc. will always be slower and use more memory in JS. Memory usage is a big one, as JS' garbage collection implementation means you can only optimize it so far.
@@PraiseYeezus OP really needed to add ".. when used for the intended purpose" to their statement, agreed. Blazingly fast might be a stretch, but it is pretty decent & the skill issue aspect is valid.
The beginning example doesn't seem optimized to me, in terms of the WASM generated. The compiler accepts optimization switches. Though adding -O3 didn't help much. It does seem like it's running on their servers as the performance I'm getting is near identical to your's. But still for whatever reason number is an f64, while in fact it will never be a float. So it should be an i32 or i64. As it doesn't seem to work on typescript, it must be up to the compiler to determine what should be which type. Number has no business being a float.
All numbers in javascript are doubles (not including bigint). that is a possible opportunity for optimization though (determining what numbers never have decimals and optimizing into an integer type). v8 does that
The advantage of WASM is not in such simple programs - it's in advanced compile time optimizations. Ask C devs how different gcc is performance wise compared to the '90s. Yes, we have AoT, but it is always a trade off - if we can do all the static analysis at compile time then it is a pure gain.
10:04 node also has to be bundled unless it's preinstalled
The summersalts we have to do just figure out how to deal with JS shit
it's not too late to become a farmer if you're not into it...
Shouldn't ts -> wasm be faster than js -> wasm because of how you optimize with static types? Sounds like a natural progression with ts -> wasm throwing out the intermediate js. I get that's not what or why porffor, but as a general idea?
I do not ever see this working as a wide scale "just compile all JS to WASM" solution. The reason is that JS is full of all those WAT-style weidnesses around its operators and the variety of parameters they can take. You just don't know how much JS code may depend on some non-obvious behavior of the language. The code Perffor is producing (isPrime for example) is very numeric centric. Pass in a string or a null and that code will not behave the same as it did in JS. So, to truly make a function behave the same, you have to pepper your WASM with all the conditionals to emulate all that stuff, which would slow it back down to JS levels or probably even slower.
The hype lord himself
We've had quick.js for this for ages, how is this different? Pure JS implementation vs a C implementation, but I'm not sure that works in its favor? Also has "WIP" and "unstable" all over the porffor readme, doesn't seem anywhere close to being ready for prime time.
quick.js is an interpreter, so if you use it to run javascript as wasm, you have to bundle the whole quick.js runtime
porffor does that ahead of time, so it doesn’t need all the bloat of a whole interpreter
I am waiting for some dev to convert react into wasm now.
JS will suck until it gets good multithreading support
For most of the video, I thought a group of ex Firefox devs were working on this
Reminds me of compiling Python into C code...
Hold on .... when the javascript runtime is causing node.js to consume so much memory, why doesn't node.js have a mode that unloads all the interpreting and compiling stuff after it is done interpreting my javascript?
I think it's unfortunate that WASM got stuck with the component-model and interface-type proposals that would have allowed WASM to be a true JS replacement. The current state where you have to access the DOM via JS is a bit unfortunate, but performance-wise there are libraries like leptos that come very close to native JS. The most promising use case for WASM today is using WASM as a secure (and more portable) alternative to containers. Especially for edge use cases, WASM can scale much faster while being much more secure compared to bulky container images. The Kubernetes community is pushing WASM very hard for this, and with projects like WASI solving the I/O situation, it could be a good replacement for 80% of all containers.
WasmGC is what you are looking for as a JS replacement. It offers strongly statically typed garbage collected high level types that it interacts with and passes around, even into JS and back. Now is the perfect time for a language to take advantage of this and truly seemlessly integrate it into the JS ecosystem.
In fact there is a TypeScript to WasmGC compiler which technically competes with Porfor, that isn‘t mentioned in the video.
WASM, with all its hype and interest, is moving really slow.It's far from a practical target for a lot of languages and frameworks yet. I don't think we necessarily need to support higher level features that are in JS, and it's understandable that it will always be a poor choice for dynamic languages but at least support calling the browser APIs, garbage collection, and finish the work on Interface Types. Until then, I don't see people deploying any web apps in WASM.
Compile your js to asm and use exploits to run it in the client browser or even kernel.
wasm isnt asm
@@mrkostya008 I meant what I said.
It seems that to you anything more complicated than JS is pure magic that can do anything, just because you don't understand it.
Good luck debugging it on your next bug ticket.
Is wasm a way to avoid someone stealing your code?
Javascript nowadays is a serious programming language, the only thing that stop me to going pro is bc someone can steal all your files, so im thinking to go full kotlin multiplatfom.. in 3 months
doesnt v8 do this on the fly already
How is wasm supposed to be fast if it is still constrained like that?
not related to the video topic lol....but does anyone know what color theme is the editor/text in the thumbnail is using?
its transpil code to wasam not compie it to Wasm.
Do people really think they can beat years of V8 development in wasm. Sounds borderline impossible to me without some major compromises.
Did you see wasm performance outside of the browsers? It's speed is comparable to jvm based apps so still faster than js that need parsing to work
In terms of performance ?
Everything is replaceable and the smartest people, are replaced with smarter people.
@@QWERTIOXAll the browser engines essentially already internally lower JS to Wasm (or rather the same internal byte code, with Wasm being a stable shortcut to it), so doing it yourself achieves nothing meaningful for performance.
Isn’t the bun binary smaller than the node binary?
fuck this shit. i'm gonna make a BIG and SLOW JS Compiler.
I am not very into my browser running (binary) code that is near impossible to read.
Soo Gleam gets another target for free? ^^
sometimes i feel like theo only makes these vids so that he can mention that he was ahead of the curve at some point in the future lol.
I don't think he cares about being ahead of the curve, more so than he is just excited about new technologies in general
I have multiple videos about why it's good to be "behind" the curve. I'm relatively late to actually adopting new stuff, I just get excited and like sharing that excitement :)
@@t3dotgg you're a poopy head
He's def the, "I called it" guy 😂
CanadaHonk loves to abandon projects a lot, so that might die after what 3 weeks?
18:39 That huge hole is being filled by React
Pyodide is cool
That's just running CPython in the browser, not compiling python to wasm
Why do North Americans pronounce WASM like WOSM?
or we could just stop using js for the server :)
Not a bot
WASM wasn't designed to address performance issues. It wasn't designed to enable other languages. It was designed as obfuscation and copy/paste barrier of corporate code, everything else is a coincidental feature, or rather clever phrasing to hide the intent.
what makes you think there’s malicious intent behind it? you shouldn’t throw out accusations like that without anything backing it up
@@cormickholland3855 "Design" the noun vs "to design" as verb. Think of it this way, there are design goals that are set at the start of project and might shift during a project. Then there's the process of implementing a design, which can influences the outcome and might not match the initial goals. Matching standing design goals exactly is sometimes extremely hard, or during implementation of a design goals turn out to be nonsensical. So the implementation of a design is as much part of design as the definitions of the design goals. So if you look at the current state of the implementation of the design, you notice the most often mention and criticized lack of DOM interoperability, but also the somewhat cumbersome JS interface. So I'm not implying malicious intent, just by judging the current state of WASM, it really serves the case of obfuscation a lot better than the case of JS equivalent runtime. Now go and check the WASM community chairs, and notice their affiliations. Now think about how consensus among such committees generally works and the power chairs hold over the consensus process just by personality alone. And because all people hold biases now you can see how certain biases in design goals and implementation could happen even completely without malicious intent.
Rhino suxxxx
some JS mods use it and it's dumb, imo.
Most webdev use js, but what's the issue? If another language is better, they will need to adapt and learn a new language, not a big deal
If they only can use js because they only did a 6 months bootcamp, that's a different story
The point is to make browsers language independent, so you can use whatever language you want, because in the end it will still be compiled to WASM.
At the end of the day you are down to a RUclips bot
tbh wasix is way more interesting than browser wasm
sadly the wasix developers tried to trademark "WebAssembly", so nobody likes them anymore 👎
Personally, I think wasm is a huge disappointment. I'd rather see Java make a resurgence as a browser language over ever using wasm. Although, we should have a runtime like Java built into the browser and having multiple languages should be no problem. We just need a VM that is more open for usage and not actually the JVM. In fact, if the web browser was just a glorified renderer for some VM-based language, we'd be far better off.
First 😅
klklkl
Please no
The fact that you are benchmarking the log rather than the actual prime logic is triggering 🫠 (this is the whole point of using this custom porffor func instead of log)