4 ms·

I highly doubt it. Reading this I honestly struggle to understand the value. In the article it says it is not faster than JavaScript except for intense computat

I highly doubt it. Reading this I honestly struggle to understand the value. In the article it says it is not faster than JavaScript except for intense computations. So, I could understand the existence of WASM libraries for certain computations that are actually faster, but for UI stuff and simple calculations (most of what frontend needs to do) you might as well stick to JavaScript as its WAAAY faster in dev time and equal in performance (or at least equal enough that it is imperceptible by the end user), and in some cases it might even be slower since you have to take the time to serialize the data to send it between JS and WASM.

SeanAnderson 3y ago
Bit of a chicken-and-egg scenario here. Frontends focus on simple, cheap UI's (<form>'s) because that's what they're good at. That doesn't mean they should be limited to just that. Where are our cloud-based DAWs? Where's CAD? There's a lot of OS-based tooling that never made the leap to web-based because of how limiting the web environment is and WASM is a great step towards solving that. Additionally, the sandboxing is suuuuper useful in today's world. Docker either wouldn't exist, or wouldn't have the clout it has today, if WASM had been fully fleshed out when Docker took off (https://thenewstack.io/when-webassembly-replaces-docker/ https://thenewstack.io/when-webassembly-replaces-docker/) Also, it's nice being able to opt-out of garbage collection by compiling a non-GC'ed language to WASM. Latency-sensitive applications (real-time gaming) don't want to aggressively manage object lifetimes in JavaScript. Like, yeah, you could, in theory, avoid excessively allocating strings and strongly prefer mutating existing objects vs immutability, but those decisions lead to more fragile code and ultimately limit the depth/quality of tooling you can create.
- itslennysfault 3y ago
  JavaScript is pretty powerful these days and not really the limiting factor for most use cases. Tinker CAD feels great and it is built with JS/HTML with the 3D view done in WebGL/Canvas: https://www.tinkercad.com/ https://www.tinkercad.com/ I could maybe see it for gaming at some point, but it is a long way to go. All screen drawing (canvas, DOM manipulation, etc) are still going through JavaScript. So none of that is any faster.
  - SeanAnderson 3y ago
    Tinker CAD seems fine, but is quite clearly not the full package. Contrast this with the ability to compile CAD to WASM and drop it in. We will see a lot more of that going forward - legacy packages that have had a lot of work put into them becoming web-accessible. It's not necessarily about being faster, but about predictability. You're correct in identifying gaming as one use case. Personally, I am trying to build a basic 2D sim game (think RimWorld) that runs in the browser. I prototyped a demo using TypeScript. React isn't viable because the reconciler isn't intended for handling <canvas /> writes and becomes the perf bottleneck. After that, the GC becomes a bottleneck because of all the allocations. So, my choices were to either write very special JavaScript that intentionally minimized allocations by pooling objects and favoring mutation over immutability, or choose a better language more suited for the task. JavaScript is absolute garbage if you care about micromanaging performance. You have no idea what you're going to get because V8 optimizations constantly change in subtle ways. I've since rewritten my approach in Rust + WASM to address those concerns. It would be nice to be able to have a shared memory buffer that <canvas /> reads from to eliminate the need to call back into JS. I doubt we'll ever get there due to WASM sandboxing, but that has yet to be the limiting factor for me. FWIW, others smarter than me have come to similar conclusions. https://maxbittker.com/making-sandspiel https://maxbittker.com/making-sandspiel documents someone creating an app three times: in JS, in Lua, and then in Rust to get it back into the web. They aren't advocating for UI to be written in Rust, but Rust + WASM did solve a need for them, too.
  - kaba0 3y ago
    Hell, one could write a full 3D FPS game with online interactivity almost a decade ago with WebGL (someone at my uni had such a thesis work). It definitely wouldn’t beat some ray-traced AAA game, but it is surely enough for most things.
- pjmlp 3y ago
  Easy, by adopting the timesharing model, they will run server side with browser only showing the GUI. CAD is already taken for. https://www.infoq.com/presentations/autocad-webassembly/ https://www.infoq.com/presentations/autocad-webassembly/ > if WASM had been fully fleshed out when Docker took off It was already there, as Java and .NET application servers, which Kubernetes + WASM containers are now re-inventing as something "revolutionary", now with YAML spaghetti instead of XML config files.

SeanAnderson 3y ago

Bit of a chicken-and-egg scenario here. Frontends focus on simple, cheap UI's (<form>'s) because that's what they're good at. That doesn't mean they should be limited to just that. Where are our cloud-based DAWs? Where's CAD? There's a lot of OS-based tooling that never made the leap to web-based because of how limiting the web environment is and WASM is a great step towards solving that. Additionally, the sandboxing is suuuuper useful in today's world. Docker either wouldn't exist, or wouldn't have the clout it has today, if WASM had been fully fleshed out when Docker took off (https://thenewstack.io/when-webassembly-replaces-docker/ https://thenewstack.io/when-webassembly-replaces-docker/) Also, it's nice being able to opt-out of garbage collection by compiling a non-GC'ed language to WASM. Latency-sensitive applications (real-time gaming) don't want to aggressively manage object lifetimes in JavaScript. Like, yeah, you could, in theory, avoid excessively allocating strings and strongly prefer mutating existing objects vs immutability, but those decisions lead to more fragile code and ultimately limit the depth/quality of tooling you can create.

itslennysfault 3y ago
JavaScript is pretty powerful these days and not really the limiting factor for most use cases. Tinker CAD feels great and it is built with JS/HTML with the 3D view done in WebGL/Canvas: https://www.tinkercad.com/ https://www.tinkercad.com/ I could maybe see it for gaming at some point, but it is a long way to go. All screen drawing (canvas, DOM manipulation, etc) are still going through JavaScript. So none of that is any faster.
- SeanAnderson 3y ago
  Tinker CAD seems fine, but is quite clearly not the full package. Contrast this with the ability to compile CAD to WASM and drop it in. We will see a lot more of that going forward - legacy packages that have had a lot of work put into them becoming web-accessible. It's not necessarily about being faster, but about predictability. You're correct in identifying gaming as one use case. Personally, I am trying to build a basic 2D sim game (think RimWorld) that runs in the browser. I prototyped a demo using TypeScript. React isn't viable because the reconciler isn't intended for handling <canvas /> writes and becomes the perf bottleneck. After that, the GC becomes a bottleneck because of all the allocations. So, my choices were to either write very special JavaScript that intentionally minimized allocations by pooling objects and favoring mutation over immutability, or choose a better language more suited for the task. JavaScript is absolute garbage if you care about micromanaging performance. You have no idea what you're going to get because V8 optimizations constantly change in subtle ways. I've since rewritten my approach in Rust + WASM to address those concerns. It would be nice to be able to have a shared memory buffer that <canvas /> reads from to eliminate the need to call back into JS. I doubt we'll ever get there due to WASM sandboxing, but that has yet to be the limiting factor for me. FWIW, others smarter than me have come to similar conclusions. https://maxbittker.com/making-sandspiel https://maxbittker.com/making-sandspiel documents someone creating an app three times: in JS, in Lua, and then in Rust to get it back into the web. They aren't advocating for UI to be written in Rust, but Rust + WASM did solve a need for them, too.
- kaba0 3y ago
  Hell, one could write a full 3D FPS game with online interactivity almost a decade ago with WebGL (someone at my uni had such a thesis work). It definitely wouldn’t beat some ray-traced AAA game, but it is surely enough for most things.
pjmlp 3y ago
Easy, by adopting the timesharing model, they will run server side with browser only showing the GUI. CAD is already taken for. https://www.infoq.com/presentations/autocad-webassembly/ https://www.infoq.com/presentations/autocad-webassembly/ > if WASM had been fully fleshed out when Docker took off It was already there, as Java and .NET application servers, which Kubernetes + WASM containers are now re-inventing as something "revolutionary", now with YAML spaghetti instead of XML config files.