Hacker News Reader

Comment by Nihilartikel | Hacker News Reader

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.

View on HN

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.

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

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

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

The difference is that Java bytecode is fundamentally insecure. Wasm seems to take inspiration from the research that went into NaCl/pNaCl.

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.

How is Java bytecode fundamentally insecure? (Example?)

Reply on news.ycombinator.com