Hacker News Reader

Comment by dktoao | Hacker News Reader

Looking to get the perspective of some HN'ers here. I am primarily an embedded engineer working with C. Our (small) software team also has a few web people that work on the web UI of our embedded Linux product. Obviously, there is a ton of potential for shared code between the two products utilizing WASM. I recently ported one of our C libraries to WASM as an experiment with emscripten and was blown away by how easy it was. I can't run the unit tests in the browser yet but it seems to have worked perfectly. However, the JS "glue" code that is produced by the emscripten compiler is really scary looking, and as I understand is basically an abridged C runtime that needs to run in the browser. My questions are therefore:

1) Is it too early to adopt WASM for production use in a small company with limited resources?

2) If we did decide to go all in on WASM, what sort of gotchas might we be dealing with?

Thanks everyone!

View on HN

> 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.

Thanks for asking for those clarifications,

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).

Will there be a DOM api for wasm?

Probably never an official one. That'd sort of defeat some of the point of WASM.

What already exists is multiple bridge libraries to make porting stuff from JS -> WASM and back again easier.

For example: https://rustwasm.github.io/wasm-bindgen/examples/dom.html

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.

[0]: https://github.com/WebAssembly/gc/blob/main/proposals/gc/Ove...

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.

I think WASM is ready for production use. Emscripten does produce big blobs of JavaScript. If it bothers you it's possible to do WASM without Emscripten. If your embedded code doesn't use a lot of libc then it might actually work for you. https://surma.dev/things/c-to-webassembly/

The big gotcha used to be debugging but Chrome dev tools actually has DWARF support now. Of course as an embedded developer you're probably already used to poor debugging support.

Heavy use of libc for file io and dynamic memory allocation, but not much else. Some of our code could be converted to using static memory buffers, but we also use some third party libraries that are not so easily changed. Thanks for the link, I will have a look!

Reply on news.ycombinator.com