71–80 of 111 posts
WASM first appeared in 2017. It still hasn't really reached a breakthrough. Billions use HTML+CSS+JavaScript. Who really uses WASM? There are of course users, but very, very few in absolute numbers. Many projects are not web-based really. For Autodesk Fusion, as one example for many, I have some mega-slow application that takes forever to work with in some cases on my laptop (it is not the fastest laptop, but I recen…
Earlier quoted context omitted.
we still need js shim for dom access :(
Asking for 0% js 100% wasm website is like wanting a C-free linux distro
The really big issue in this case is network effect, which is why I hope something can come out from the momentum building behind WASM.
Earlier quoted context omitted.
It works in the browser already: https://github.com/bytecodealliance/jco
It works in the browser already, by bundling another browser runtime engine into wasm. You need a whole fork of Mozilla's SpiderMonkey engine, compiled to wasm, running in whatever browser you have, to run wasm components today. I confess I was quite frustrated at first when browsers all said no to wasi / wasm components. But honestly, it was the right call. It's taken so long to make wasm components happen, to get t…
> It works in the browser already, by bundling another browser runtime engine into wasm.
Note that that's not how JCO works: JCO unbundles a Component, emitting core wasm modules plus JS glue code. JCO also is a toolchain that can orchestrate turning JS into a Component, and that does bundle a JS runtime (StarlingMonkey), but that's not for running Components in JS/browsers, but for running JS in Component runtimes, such as Wasmtime.
Earlier quoted context omitted.
Use cases I am more excited about: 1) Replace webhooks in web apps with wasm binaries provided by the customer, but that run in the web app servers. 2) Safer plugin system for professional software (plugins for photoshop, plugins for IDEs, etc) 3) Safer mod system for games and server-side mods that run on the game-maker server.
We had that in the 90's with Java. Why would this approach succeed today?
Earlier quoted context omitted.
It is exactly the same for WASM outside of the browser, and Java has Android as counter part to built in runtime.
Java's vm does not start in milliseconds nor has dozen independent implementations in every ecosystem
Maybe they should broaden their horizons.
https://en.wikipedia.org/wiki/List_of_Java_virtual_machines
And some like PTC or microEJ are missing from the list.
Earlier quoted context omitted.
No you don't, because WASM is only compute, and you need exactly runtime specific code and third party frameworks for everything else as imported functions.
That's what WASI is for
Earlier quoted context omitted.
According to https://chromestatus.com/metrics/feature/timeline/popularity... WebAssembly runs on about 6.11% of Chrome page loads, up from 3.37% in January 2024.
Probably all of that is Figma.
It’s great we are past the “wasm is not replacing JavaScript” phase. Or “you don’t need DOM for wasm . That’s what JavaScript is for”
I don't get it why you need direct DOM access. Just wrap it in JS calls. It's not like current websites are super fast and creating a wrapper will slow it down unnecessarily.