Hacker News Reader

Comment by shalabhc | Hacker News Reader

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.

View on HN

Add 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.

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

> Add metrics and advertising obsessed companies into the mix and the only result could be a complete clusterfuck.

Case in point: The Web.

I 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.

The alternative is advertising built into the OS like Ubuntu did and MS and Amazon still do, tracking built into the OS like Google and MS do, etc. Having the trackers run in a sandbox is not great but it's a little better than letting them all run natively.

I am hoping to time my exit from the field to coincide with this clusterfuck singularity.

Ah yes. The fall and rise of JavaScript.

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

Replace “WebAssembly VM” with “JVM” and you will see how it’s already available, and why it won’t catch on.

The 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.

At 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.

JVM 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.

Plus the java installer would sneak in some junkware/toolbars in the process

Yes, thankfully no web browser vendor would ever do such a thing.

The JVM doesn't compete with C or C++.

JVM 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.

Webassembly 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.

Swing is a very good improvement over HTML UI hacks.

Java doesn't require Swing or AWT either.

Reply on news.ycombinator.com