Hacker News Reader

Comment by peutetre | Hacker News Reader

You can do both of those things in JavaScript.

WebAssembly brings every language to the web and does it with higher performance than JavaScript.

For sandboxing in JS, we can use sandboxed iframes or webworkers. Both of those communicate to hosted code via postmessage which serializes an object and this can be used as a base for implementing function calls.

Whereas if I understand correctly, WASM can be provided with host approved JS functions to call directly in importObject. This seems more convenient and fast.

But for a plugin system, many people would prefer to write plugins in JS itself, so for WASM plugins, they might have to be compiled to WASM first. Dont know how if there is a mature implementation of JS->WASM.

> But for a plugin system, many people would prefer to write plugins in JS itself, so for WASM plugins, they might have to be compiled to WASM first. Dont know how if there is a mature implementation of JS->WASM.

Not everyone tho, which is kinda the point of abstracting away your language for plugins. People like Python, Lua, Go, Rust, etc... Some do like JS of course, but not everybody. Re: mature implementations, I would guess worst case QuickJS probably can compile to WASM and it's small enough that your runtime will probably offset the extra blob size.

Javy project seems more active.

> I would guess worst case QuickJS probably can compile to WASM

That's actually exactly what Figma is doing for their plugins. [1] Seems to be working ok, though not without some pain [2].

[1] https://www.figma.com/blog/an-update-on-plugin-security/

[2] https://macwright.com/2024/03/29/figma-plugins

Reply on news.ycombinator.com