4 ms·
Having some random thoughts about the comments here, some of which talk about having a "browser" drive large parts of what we consider today an "operating syste
by xtrapolate 9y ago
Having some random thoughts about the comments here, some of which talk about having a "browser" drive large parts of what we consider today an "operating system". I agree that certain aspects of what most modern operating systems do today can be abstracted away behind a unified, convenient (and perhaps browser-accessible) API. The entire user-experience stack comes to mind immediately, but there are counter examples as-well. The answer to non-unified execution environments (as in different operating systems and architectures) was the rise of high-level, interpreted languages (in addition to corresponding VMs), and runtime environments which exposed a platform-independent set of APIs. We've been exploring the possibilities of implementing bytecode VMs in hardware (https://en.wikipedia.org/wiki/Java_processor https://en.wikipedia.org/wiki/Java_processor), or running a managed code operating system (Microsoft's Midori) for a while now, so the concept itself isn't particularly new. What is WASM's advantage over, say, Java's bytecode? Did we really have to go through so many hoops (reinvent another instruction set and a VM that can execute it across multiple platforms)? Why wasn't an existing technology re-used here to achieve the same/similar goals?
- vbezhenar 9y agoI think it just happens that browser is the most widely installed VM independent of a single major vendor, pretty cross-platform and with enough features to build applications of any complexity. If you would design that from scratch, I think that something much simpler could be designed, much simpler than JVM, for example. But how would you install it to every computer out there? Nobody would use it if it's not installed everywhere.
- chuckdries 9y agoWell, what would you have replace it? Like most things that become very popular, the web is becoming an os-like platform because it solves a problem. Putting your application at a URL is hugely more accessible than asking someone to download something. Maybe not to us HN readers, but to my mom, who's skeptical to a fault of anything that says download, it's huge. HTML+CSS+JS is everywhere and complete in a way that literally nothing else is. Yeah C is everywhere but (before nowish) you couldn't write a C application once and have it run the same pretty much everywhere. But chuck, you say, HTML has notoriously bad compatibility and working with it is frustrating. I propose to you that HTML and CSS have so many compatibility problems because of how pervasive it is and has been for so long, and how many different implementations of it exist. Anything is bound to develop compatibility issues when it gets as large as the web. But you're right, it's suboptimal and other tech has tried to be everywhere. Java and Flash did try, but have you ever used a java applet? They're fine I guess, but they're stuck in a square on the page. You can make a java or flash object take up the whole page and completely control the website but then you run into accessibility issues and complexity on your part. Javascript has grown organically over the past decades for a reason, and it's being used in this fucked up way because, all things considered, it's the best platform for the job right now
- xtrapolate 9y agoAppreciate your insights. I don't really have an answer to your question. I respect the popularity factor, I just can't help but think that we've had (and still currently have) competing technologies which are far more mature and capable. Not saying WASM won't end up on top in the future. There are plenty of applications today that build on parallelisation, synchronisation primitives, IO, IPC... all of which are already perfectly possible today over the JRE/JVM (as an example), but the same can't be said about browsers today (no doubt that with enough work, it can all change sometime in the future). Just feels like reinventing the wheel.
- pjmlp 9y agoAs usual, politics.
- imtringued 9y ago>What is WASM's advantage over, say, Java's bytecode? Precise control over memory layout and allocation which can translate into massive performance gains of several orders of magnitude. LLVM IR isn't stable accross LLVM versions. Webassembly is the solution to a problem that stayed unsolved for decades. There is no alternative to webassembly. It is in it's own category. Probably the closest competitor you could find is LuaJIT with it's FFI module but LuaJIT wasn't designed as a compilation target. It'd suffer from the same problems that asm.js did. JVM bytecode is stable but high level. LLVM IR is unstable and low level. WebAssembly is stable and low level.
- xtrapolate 9y agoPrecise control over memory layout and allocation which can translate into massive performance gains of several orders of magnitude. "Can translate" is not "translates to". Performance gains can be achieved when executing an efficient instruction set over a performant VM. Are you arguing that the JVM falls short as opposed to a browser in that regard? Also, with most operating systems, physical memory is abstracted from user-mode processes entirely. Kernel-mode is a different story, but I fail to see how a browser/WASM in user-mode do better than a JVM in user-mode in that regard. LLVM IR is unstable and low level. Interesting. What makes an instruction set "stable"? Is this about being backwards/forward compatible? About being encoded/decoded efficiently? What about the actual APIs exposed by the browser to WASM? Are those considered "stable"? Browsers today "break" all the time - inconsistencies between minors of the same browser, let alone different browser vendors.