> Is it too early to adopt WASM for production use in a small company with limited resources?
It really depends on what you are doing with it.
For things like "I've got this C lib that I want to be able to call from the web" it's probably fine. For things like "I want to write my whole webpage in wasm" it's not ready for that (and, frankly, likely never will be).
It's a matter of finding the right fit.
> If we did decide to go all in on WASM, what sort of gotchas might we be dealing with?
Depends on what you mean by "all in" if you mean, "I want ALL my webapp logic to live in wasm" then the biggest gotcha you'll face is shipping stuff into and out of the VM (including DOM elements) is really painful. IMO, UX continues to best be done with Javascript or compile to javascript langauges (typescript, for example). Using a language like C, C++, or Rust to do UX work will simply not be pleasant, will be hard to hire for, and will complicate a lot of your build system.
Now, if by all in you mean "This logic only lives in this library and we are shipping that out as a WASM module" then I think wasm will work well there. Better, in fact, than other options like kotlin to native or J2CL (IMO).
That said, there are fledgling UX frameworks written entirely for WASM. However, they are all relatively young and AFAIK, not exactly well established.
This becomes an engineering decision and balancing act that I don't think can be 100% answered for your company.
I don't expect any of the UI work will ever be done in WASM (because it doesn't need to be shared with the embedded side of things). It is more porting standalone libraries that would be useful for both like file parsing and networking libraries. (In particular, the library I ported was a file parser).
In that case, yeah, it will work. You just have to realize that WASM has a REALLY tight sandbox around it, so getting a file/network stream into it will be somewhat of a pain.
WASM works best in cases of strict CPU and limited GPU processing (through webgl).
Never say never, but the DOM and JavaScript environment relies pretty heavily on garbage collection. WASM is inherently not garbage collected, and that makes it really hard to share data between the environments, so I'd say that it is unlikely.
There's nothing about WebAssembly that's "inherently" not garbage collected. There is a "Host GC" proposal [0] along with a "reference type" proposal that would allow holding handles to DOM or JS objects from WebAssembly and using the JS GC for WebAssembly objects.
That's not an issue if you have a way to pin/unpin references as they move into the non-GCed world; a lot of GCed languages like Java/Python have native bridging.
It is a good way to get memory leaks, but a lot of websites already have those.
It really depends on what you are doing with it.
For things like "I've got this C lib that I want to be able to call from the web" it's probably fine. For things like "I want to write my whole webpage in wasm" it's not ready for that (and, frankly, likely never will be).
It's a matter of finding the right fit.
> If we did decide to go all in on WASM, what sort of gotchas might we be dealing with?
Depends on what you mean by "all in" if you mean, "I want ALL my webapp logic to live in wasm" then the biggest gotcha you'll face is shipping stuff into and out of the VM (including DOM elements) is really painful. IMO, UX continues to best be done with Javascript or compile to javascript langauges (typescript, for example). Using a language like C, C++, or Rust to do UX work will simply not be pleasant, will be hard to hire for, and will complicate a lot of your build system.
Now, if by all in you mean "This logic only lives in this library and we are shipping that out as a WASM module" then I think wasm will work well there. Better, in fact, than other options like kotlin to native or J2CL (IMO).
That said, there are fledgling UX frameworks written entirely for WASM. However, they are all relatively young and AFAIK, not exactly well established.
This becomes an engineering decision and balancing act that I don't think can be 100% answered for your company.