3 ms·

Then something like WASM, but avoiding the 1.5x or so slowdown over native. Perhaps WASM is the answer, but with improved runtime. What I'm driving at is - if

Then something like WASM, but avoiding the 1.5x or so slowdown over native. Perhaps WASM is the answer, but with improved runtime. What I'm driving at is - if we can dream, why not aim for maximal hardware performance and minimal overhead? Even if it comes down to just pre-compiling native code for common architectures like Android apps do. Right now, the browser is an idiosyncratic HAL burdened by its past... what would a really nice next generation be? Interesting thing to know about the LLVM IR - I'm only casually familiar.

pfraze 7y ago
Wasm comes to mind for a new browser arch because in theory it could be a userland replacement for traditional platform features like the UI. You could have a wasm module for HTML, for instance, which could be chosen for legacy sites, but replaced for a different approach (VR UI, cloud service which doesnt need one, etc). This would help minimize the browser core and make the execution environments swappable and reusable across browser cores. That said, I agree that performance may be a dealbreaker on that idea. HTML/DOM is also tightly integrated into a lot of browser behaviors, so I have no idea whether it's feasible to extract it into a swappable module. EDIT: It's still an idea that gets me pretty excited to try.
jhoechtl 7y ago
> Then something like WASM, but avoiding the 1.5x or so slowdown over native. Perhaps WASM is the answer, but with improved runtime. Once we are done with WASM we will look at it, compare it with Java Applets and say: Look, we already had that!
- hajile 7y ago
  The difference is that Java bytecode is fundamentally insecure. Wasm seems to take inspiration from the research that went into NaCl/pNaCl.
  - cesarb 7y ago
    The worst problem with the Java sandbox was not the bytecode (though it did have its share of bytecode validation bugs). The worst problem was the vast API surface with its "blacklist" security model: all methods which should not be called from the sandbox have to explicitly call a AccessController.checkPermission() or similar. Miss one, and you have a hole in the sandbox. WASM instead follows a "whitelist" approach, which is much more robust.
  - Pyxl101 7y ago
    How is Java bytecode fundamentally insecure? (Example?)
hajile 7y ago
https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
bb010g 7y ago
A working compiler from Wasm to native using LLVM: https://innative.dev/ https://innative.dev/

pfraze 7y ago

Wasm comes to mind for a new browser arch because in theory it could be a userland replacement for traditional platform features like the UI. You could have a wasm module for HTML, for instance, which could be chosen for legacy sites, but replaced for a different approach (VR UI, cloud service which doesnt need one, etc). This would help minimize the browser core and make the execution environments swappable and reusable across browser cores. That said, I agree that performance may be a dealbreaker on that idea. HTML/DOM is also tightly integrated into a lot of browser behaviors, so I have no idea whether it's feasible to extract it into a swappable module. EDIT: It's still an idea that gets me pretty excited to try.

jhoechtl 7y ago

> Then something like WASM, but avoiding the 1.5x or so slowdown over native. Perhaps WASM is the answer, but with improved runtime. Once we are done with WASM we will look at it, compare it with Java Applets and say: Look, we already had that!

hajile 7y ago
The difference is that Java bytecode is fundamentally insecure. Wasm seems to take inspiration from the research that went into NaCl/pNaCl.
- cesarb 7y ago
  The worst problem with the Java sandbox was not the bytecode (though it did have its share of bytecode validation bugs). The worst problem was the vast API surface with its "blacklist" security model: all methods which should not be called from the sandbox have to explicitly call a AccessController.checkPermission() or similar. Miss one, and you have a hole in the sandbox. WASM instead follows a "whitelist" approach, which is much more robust.
- Pyxl101 7y ago
  How is Java bytecode fundamentally insecure? (Example?)

hajile 7y ago

https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...

bb010g 7y ago

A working compiler from Wasm to native using LLVM: https://innative.dev/ https://innative.dev/