|
Top-level
I think that may be it. The JavaScript JITs are insane, and that they aren't subject to more OMG breakages, and the browsers these days split the rendering engine per origin into a separate process (with all the process isolation on top), the browser folks have a lot of experience. Also, I think WASM started much smaller, and the only outside world is through the JavaScript framework rather than direct probably helps too. 6 comments
  One weakness in Java was JNI because at some point you have to get data in/out of real devices. If my webcam is some janky Costco $6 special, with a buggy, vulnerable terrible driver, does WASM protect me from malicious web pages that want to tickle my vulnerable webcam driver? Or is it just orthogonal? I.e. not WASM’s circus, so not WASM’s monkeys? I think they handle that by basically EVERY bit of I/O has to go through the JavaScript, so it isn't adding to that problem space. I've been playing with safe WASM plugins for resource edition in @capyloon and one super-power is that the "host" code can check which functions are imported by plugins. That makes it possible to enforce eg. privacy policies or permission models. |
Gregory's Server
@simon @ncweaver yeah i think the fundamental win is that it started much narrower, and the tooling and stack are more defined, instead of being a sort of under-defined mess. It’s much more opinionated by convention (if not necessarily by implementation) and that makes it a lot more accessible.