5 ms·

I'm still skeptical about the whole Wasm ordeal. If you want to run code written in other languages in the browser, you could just as well compile to JavaScrip

• dgb23 1y ago
  It's difficult (and ugly/foreign) to write fast JS and at some point you hit a wall. Incidentally that's why/how Wasm got created in the first place.
• cheschire 1y ago
  It’s not a complete replacement for JS transpiling. It has some advantages for specific use cases. A couple benefits I like are: Not having the JS GC randomly pausing your process unpredictably. Sandboxing untrusted code, i.e. you sell a SaaS and you also want clients to be able to run untrusted plugins from a marketplace.
  • TekMol 1y ago
    You can use fixed data structures like Uint8Array in JavaScript just like you can (have to?) in Wasm. Then you won't have the GC do stuff, right?
• emaro 1y ago
  Even if this were true, 'a bit of a speed improvement' is still huge given the amount of JS that's run in our world.
• qoez 1y ago
  Wasm with simd can get things like physics simulation and some ML on the order of 2x faster. I'm finding it really useful.
  • pjmlp 1y ago
    Or let the GPU do it instead.
    • qoez 1y ago
      For physics it's in some cases way easier to implement on cpu. For ML using wasm means the model loads way faster (the user doesn't have to wait; and sometimes the performance is about the same). For some small models wasm can be faster. Mediapipe by google for instance gets better performance and better latency with their wasm model than the gpu one.
• macguillicuddy 1y ago
  We do high performance computer vision in the browser (at 30/60 fps) that's an order of magnitude faster in WASM than JS. It simply would not be fast enough without WASM.
  • pjmlp 1y ago
    You could offload to WebGL/WebGPU for that.
    • coffeeindex 1y ago
      Or you could use Wasm
      • pjmlp 1y ago
        WASM is slower, and the toolchain sucks for most languages.
        • adwn 1y ago
          > WASM is slower […] Without more details on their exact use case, their algorithms, and their data movement patterns, you have no way of knowing this. Doing stuff on the GPU isn't automatically faster than doing it on the CPU.
        • eviks 1y ago
          Why does "most" matter in this case wnen you just need 1 that suits your needs?
    • wtetzner 1y ago
      Sure, but that's much more complex to implement, and comes with its own overhead.
      • pjmlp 1y ago
        Not that WASM tooling is such an example of great developer experience.
• davidmurdoch 1y ago
  If JS had native SIMD, probably. But it doesn't, and it won't (because it's complex to do in JS, and you can just use Wasm instead), so it really can't compete because of just how much faster Wasm can be these days.
  • TekMol 1y ago
    So how much faster than JS is Wasm for typical use-cases?
    • panstromek 1y ago
      That's a bit of a trick question - typical use case for each is different, you don't use these interchengably, it doesn't make that much sense. Typical use case for JS is let's say a glue between network and DOM, where it doesn't really do much, most of that work is done by the browser anyway. If you add wasm to that, you'll just add one more indirection through the wasm sandbox and it'll probably be slower in many cases, because you have to copy data. Typical use case for Wasm is either porting existing native programs or something compute heavy. Figma uses this for the native layer, I used it for some image processing use cases or for board game solver backend. Doing that in JS is slower because JS semantics are not straightforward to optimize, even for basic numerical operations. I found something around 3-10x speedup for this kind of code is pretty common, but it depends on what it is doing - whether JS can represent the types and operations well.
  • jsheard 1y ago
    It's not for lack of trying either, there was a JS SIMD proposal which got pretty far along, but then everyone came to their senses and scrapped it to focus on WASM SIMD instead. https://github.com/tc39/ecmascript_simd https://github.com/tc39/ecmascript_simd
    • davidmurdoch 1y ago
      Yeah, that's what I meant by complex. But I still think/wish they should figure out a way to make SIMD accessible directly in JS.
• deleted 1y ago
  [deleted]
• intelVISA 1y ago
  Same, it still feels like too much of a grift for VC monies to me. Not a hater, though it's fun to run Doom in a browser tab... just can't see any business value in 99% of its ecosystem, especially with the drift away from web (the only niche where it made sense).
  • unrealhoang 1y ago
    There’re fundamental libraries that can be used on the web because of wasm: imagemagick, ffmpeg, opencv, duckdb, sqlite, figma’s render engine... Just because 95% of web apps are crud DOMs doesn’t mean such technology is not important.
• gr4vityWall 1y ago
  > If you want to run code written in other languages in the browser, you could just as well compile to JavaScript. That's how asm.js was conceived. You can compile other languages to a subset of JS that is super JIT-friendly and performs stupidly well. I think WASM came to be due to a desire to run that resulting code in a heavily sandboxed environment, with much more limited access to certain APIs than the rest of your JavaScript code. Unrelated, but it's not clear to me why you're getting downvoted. Your point sounded genuine and didn't look like flamewar bait.