WebAssembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual machine. Wasm is designed as a portable target for compilation of high-level languages like C/C++/Rust, enabling deployment on the web for client and server applications.
I can understand when a whole software component like a physics engine is encapsulated as a WebAssembly module (especially since you have a better performance). But I’m still not a fan of this architecture…
Why do you draw a line at a whole physics engine, what makes this an atomic part in your view of the world? Why not an octree, or a raycaster, or an octree based raycaster?
It was just an example.
Not worthy of a discussion? I think it’s a good example. There are lot’s of internals that most people don’t want to touch, but would prefer if they were as performant as it can get.
As @Mugen87 responded with indeed was an example, wondering if others in the community of Three.js being used with WebAssembly in other ways? Apparently this isn’t happening as much as I had thought. Was only curious. Thanks for everyone(s) input so far!
I’m super curious about this topic but it is indeed intimidating, I tried to get started once and didn’t make much progress. I can definitely think of a use where more optimized code would help a lot.
Did I read it wrong, or is it only a 1.0 draft?
I tried to use
Why do you draw a line at a whole physics engine… why not an octree, or a raycaster, or an octree based raycaster?
For me there’s a line because compiling, testing, and deploying WASM is currently a pain. You’ll probably have to write bindings for every method you expose. Also, the compiled binary size tends to be much larger than the JS equivalent. For small simple modules, that’s not (yet) worth it. Maybe that will change someday.
An example I’m interested in is Recast/Detour, a navigation mesh and crowd pathfinding library commonly used in Unreal Engine and Unity. I spent a while trying to writing WASM bindings (see:
embind) but gave up. There are existing attempts (like https://github.com/vincent/recast.js) with Emscripten but they all seem unmaintained, buggy, and/or just aren’t set up the way I need.
Is this stuff that can improve as WASM matures, or is it an inherent flaw in the approach?
I think it’s just limitations in the current tooling, I’m optimistic in the long run. There may always be a certain amount of size overhead on a WASM binary that would make it less practical for very small modules, but I’m only guessing.
I don’t know that it’s actually
wasm's fault. This is just the next iteration of feature creep on the web.
Where this could become really powerful is if we dropped the idea of embedding this stuff into HTML, and wrote entire applications around
wasm, with full browser support. If you’re going to write an app, make it as performant as possible via
wasm. If you’re just creating documents, use HTML.
(An example of this is running APK files in Chrome. Only written in a web-native language instead.)
My interest for now is access to some of the popular native libraries already used in gamedev. I have no interest in writing more native code myself. But yeah, Google Earth is an example of a complete application where that could make sense — currently it uses Chrome Native Client, but they’ve said they’re working toward using WASM instead.
I think WebAssembly is a very interesting technology. Beside the runtime performance promise WebAssembly makes I want to highlight another cool feature.
FWIW, I wrote a post last year about my first experience with WebAssembly (https://blog.openbloc.fr/webassembly-first-steps/). From what I remember:
- memory allocation wasn’t an easy task (has to be done at the init step, memory grow at runtime is expensive of course, malloc doesn’t work out of the box
- if you have to pass data between JS and wasm at each render frame (I guess big arrays if we’re talking about three.js) I don’t know how efficient this runs
- no DOM manipulation though there are projects like https://github.com/mbasso/asm-dom that aims at closing the gap.
WASM will be of great use for specific intensive taks which can be optimized this way, but it shouldn’t be expected as a replacement for JS, rather as for what i just mentioned and providing a interface for other languages, or alternative in the future.
It’s already widely used for cryptominers, utilizing as much as possible out of your device
V8 is actually very powerful and will also compile to machine code where it’s possible. I will also mainly make use of it for processing tasks. JS can be heavily optimized too, i’ve seen libraries with rather bad practice making code unoptimizable, having exception code in a per-frame manner, allocating and dropping memory/objects frequently, or just an architecture which could be solved more efficiently. Some statements, invokations or allocations might seem small, but the entireness counts and how often things get invoked.
For THREE i would be already happy for now having finally offscreen canvas support in all browsers.