5 ms·
Next we'll get to a webassembly-only VM that will replace the OS. All 'apps' will run on this VM instead of being native, and most will be cross platform. They'
by shalabhc 9y ago
Next we'll get to a webassembly-only VM that will replace the OS. All 'apps' will run on this VM instead of being native, and most will be cross platform. They'll talk to each other via messaging (using Javascript semantics) instead of bytes-over-pipes as they do today. An integrated globally available, namespaced data store API might replace the filesystem. Each app+version will be accessible by a distinct URL. 'My computer' will finally be fully virtual - a well defined collection of 'apps/data' URLs that materializes wherever I can open one of these webassembly VMs.
With this webassembly VM, early bound (precompiled) lower level languages may not have a strong advantage over late bound, dynamic ones, because the compiler is part of the OS layer (as it should be).
The world seems to be slowly moving, in a roundabout way, towards the OS-browser idea from Alan Kay.
- tzahola 9y agoReplace “WebAssembly VM” with “JVM” and you will see how it’s already available, and why it won’t catch on.
- C14L 9y agoThe big difference is that the "Browser VM" has well defined permissions to access resources on the host machine. Just like phone OSes do today. Bluetooth API, Files API, Location API, etc.
- fleitz 9y agoAt which point you have an OS... except adding the word ‘webassembly’ somehow imbues it with properties OS’s don’t already because somehow web assembly compiles to assembly with extra security with no performance reduction.
- deleted 9y ago[deleted]
- int_19h 9y agoJVM had to be installed, and it was far from seamless the way OP describes it. The advantage of wasm is that all the people running Chrome today already have it.
- deleted 9y ago[deleted]
- imtringued 9y agoThe JVM doesn't compete with C or C++.
- imtringued 9y agoJVM Bytecode is not a low level bytecode. It doesn't support value types or aribtrary pointer manipulation within a sandboxed memory area. It has a lot of java semantics baked in. Performance in most cases is better than javascript but it still is in the same order of magnitude because you have little control over the memory layout. Webassembly solves a problem that existing low level bytecodes like LLVM IR do not intend to solve. LLVM IR is not stable across LLVM versions and usually is optimized for a specific architecture. JVM bytecode is stable but high level. LLVM IR is unstable and low level. WebAssembly is stable and low level. They all solve different problems.
- mailslot 9y agoWebassembly doesn't require you to install Oracle software, or lag your computer for 30 seconds while it starts up... And it doesn't require Swing or AWT. So, there are those minor improvements.
- pjmlp 9y agoSwing is a very good improvement over HTML UI hacks.
- AnIdiotOnTheNet 9y agoJava doesn't require Swing or AWT either.
- blub 9y agoAdd metrics and advertising obsessed companies into the mix and the only result could be a complete clusterfuck. The major issue with web apps is that the customer (or depending on the company bag of meat that watches the ads) has no control over the app or the data. They will be abused by the company in all sorts of creative ways. And yes, those VMs could be local-only, but why would Google, MS or Mozilla want that? The former two are heavy in the cloud+ads business, the latter was pushing FirefoxOS. Why would web developers want that? All the stuff they write is online-first.
- wslh 9y ago> Add metrics and advertising... I assume the ads would be at the messaging system, so even if a variable contains 'iphone' the ads start to appear. Joking aside, we need a better security system because we never know if an arbitrary compiler is not embedding a malware payload.
- AnIdiotOnTheNet 9y ago> Add metrics and advertising obsessed companies into the mix and the only result could be a complete clusterfuck. Case in point: The Web.
- nerdponx 9y agoI already see plenty of obfuscated JavaScript out in the wild. Script names have opaque GUIDs and slugs, and the code itself is inscrutable: defining single-character constants and recombining them later, dynamically constructing scripts to be dynamically injected into the page and then run, etc. I would like to believe that this is done in the name of performance, but my gut tells me this is done in the name of keeping one step ahead of the ad blockers. As it stands now, I feel that I as a user have no defense against tracking and fingerprinting except by monitoring and controlling access to the DOM at the level of individual operations. I am afraid this is only going to get worse with WebAssembly. "Audit the code yourself" no longer a viable solution except for a handful of experts. On the bright side, perhaps WebAssembly will lead to fewer ways of interacting with the DOM, which could make it easier to detect malicious/undesired interactions.
- sp332 9y ago
- mtrycz2 9y agoAh yes. The fall and rise of JavaScript. https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...