Current (desktop) operating systems were not designed for a world where you routinely run code from someone on the other side of the planet who you have no relationship to, and don't trust, so you can see cat pics or read a forum.
Browsers have a lot of problems, but their security model and ephemeral install model are inspired designs, which directly enable the safety of the modern internet.
Having to fall back to classic desktop apps for real speed or power is a terrible thing for end-user security. Either browsers need to get more powerful, or desktop OSes need to take on a browser-like security model.
So the process model is not fundamentally different than the browser model, but WebAssembly enjoys two advantages:
1. The browser security model sagely segmented privileges by origin rather than user.
2. Like bytecode, WebAssembly AST does not target a specific processor.
I see no reason why each domain couldn't have a chroot for example, the browser doesn't need to implement those things.
Actually it can sandbox them already.
Web browsers have been like operating systems all along, because they execute programs, albeit with different performance and safety characteristics. That the two are converging upon the same solution to the problem of hosting apps should be reassuring, not concerning.
And before that in the 80s, there was UCSD Pascal. I know it was available for the Apple ][ (used it in high school) and the IBM PC (one of three operating systems available when IBM launched the IBM PC in August of 1981) and probably a few other platforms I'm blanking on. A defined VM and "executables" could run on any platform running UCSD Pascal.
And even before that, IBM pioneered VMs for their own hardware, which is probably what inspired UCSD Pascal in the first place.
- The JVM takes forever to spin up
- The JVM tries to do too much with tons of class libraries
- The JVM is insecure
- The JVM is proprietary. While there are open source
implementations, it is still tethered to Sun and now
Oracle. They call the shots on the features and have
sued both Google and Microsoft for implementing their
own versions.
Similar arguments can be made against Flash.We shouldn't expect WebAssembly to have the same pitfalls, since
- WebAssembly does not take forever to spin up
- WebAssembly doesn't try to do too much. There is no huge
standard library. For now it doesn't even include a GC.
- WebAssembly isn't insecure. Why would it be? I assume
applet exploits are a product of the large standard
library (more attack vectors) and privilege escalation
(certain exploits let you break out of its security
settings to gain control). All of this seems like it's
because web applets are monkeypatched on top of the
existing JVM.
- WebAssembly isn't proprietary.Cross platform is a red herring. The iOS and Android app stores are not cross platform. Ease of use is also increasingly a red herring. The Windows and Mac app stores have been around for a long time and are quite easy to use. Yet they have not ushered in a shift away from Web apps on the desktop.
I think we should be looking at why Web apps have been successful on the desktop rather than pretending they have no advantages.
I think there is a perception of "try before you buy" with web apps that is appealing. Even when apps/programs are free, you feel like you are giving something away by installing them.
The number of layers of in our software stacks grow faster than Moore's law can handle.
Then why isn't the Mac App Store (to name an example) a runaway success?
Er, because that would be really silly.
I like reading HN from time to time. I would never install an app, because I don't use it frequently enough. I definitely would never go through the pain of installing a HN app every time I wanted to read HN. I really doubt I'm alone or even abnormal in that regard.
That's the beauty of a browser: I can be reading HN in under a second when I want to, with no cluttering of my desktop just so I can read HN from time to time.
I think maybe application sandboxing is an OS job, and the browser should do the caching and invoking of the operating system sandbox.
Because users want it to be. Whenever there isn't a significant performance hit people will always choose the browser solution. The only reason people download apps is because of performance and data limitations. Take those away and people will use the web based version.
You should look at the data on that.