3 ms·
> we run [your custom code] inside a wasm-based sandbox, a compiled version of the QuickJS VM (yes, it's JS-in-JS). I'm curious about why. Is sychronicity the
by cxr 5y ago
> we run [your custom code] inside a wasm-based sandbox, a compiled version of the QuickJS VM (yes, it's JS-in-JS).
I'm curious about why. Is sychronicity the only reason? (And is it really worth it? `await` makes asynchronous code paths pretty unobtrusive.) Mirrors[1][2] are pretty interesting.
(Not sure that I agree that compile-to-WASM makes for JS-in-JS. WASM isn't JS. Why do people keep conflating them?[3])
1. <https://bracha.org/mirrors.pdf https://bracha.org/mirrors.pdf>
2. <http://www.wirfs-brock.com/allen/posts/228 http://www.wirfs-brock.com/allen/posts/228>
3. <https://news.ycombinator.com/item?id=29754432 https://news.ycombinator.com/item?id=29754432>
- conradev 5y agoI imagine that part of it is for security. Figma has a good overview of the different approaches they considered for their JavaScript plugin system, and JS-in-JS was one of them: https://www.figma.com/blog/how-we-built-the-figma-plugin-system/ https://www.figma.com/blog/how-we-built-the-figma-plugin-sys...
- cxr 5y ago> I imagine that part of it is for security. Sure, that much is clear. But we're discussing it in contrast with other security-preserving approaches. "For security" only really makes sense we were asking, "Why do any of these things at all?", but we're past that. What we're asking is "Why this thing specifically?"—especially where that thing is expensive. > Figma has a good overview of the different approaches they considered for their JavaScript plugin system, and JS-in-JS was one of them First: to reiterate, JS-in-WASM is not JS-in-JS. Secondly: Mirrors, notably, are not among the approaches they evaluated. I advocated for an evaluation of a similar Mirrors-based approach in the HN thread at the time that the Figma post was published: <https://news.ycombinator.com/item?id=20770105 https://news.ycombinator.com/item?id=20770105>