Is the web not salvageable? Look at web assembly. The browser vendors added a VM and a bytecode format that runs on it. And they did it pretty quickly. In my mind, this is the way things are going to improve in web-land. Not "throw it all out and start over."
If someone/a company wants to build an "app browser" and associated protocols and publish it then the market will decide how that goes. I think it's a cool idea, but I doubt it would gain traction because almost everything enumerated in this post is a developer concern, not a user concern.
In software, there's always going to be that temptation to start all over again due to fundamental mistakes that were made years ago. But I feel there are far too many entangled interests in the web for that strategy to make sense. Hey, if someone wants to work on it, god bless them.
There have been many initiatives over the years to add more languages to the web platform than just JavaScript. I remember one from Google that tried to add a form of Java that had better integrated DOM access and didn't use a separate/traditional JVM (more like another mode on top of V8, iirc). There was NaCL, two attempts. Of course there were plugins as well. They were all killed off with justifications that ranged from the reasonable-sounding to the quite obviously ideological.
WebAssembly is the latest attempt to scale this wall, and what does it give us?
A new bytecode format that nothing uses and which is accepted by no hardware. It looks suspiciously similar to JVM bytecode, featuring a small set of bytecodes and a bytecode verifier, except that there's no support for expressing patterns that all high level languages have, like exceptions or garbage collected memory allocation.
The primary new capability, after years of work, seems to be that you can now embed C into a web page (as long as you bring your own C library, I guess) and run it slowly until it warms up. Although they handwavingly claim that in future they'll add GC support and that'll unlock support for other languages, it will come at a massive performance penalty that makes it effectively useless because such languages require complex JIT compiling runtimes to achieve good performance and you won't be able to do that sort of thing inside a wasm module.
The web's designers had many other options that would have been far more useful but they went with this one. What is their solution to avoid web apps now importing the world of manual memory management vulnerabilities? They don't have one: the best you get is preventing the C code from affecting the browser.
The only thing I find sadder than WebAssembly is the undeserved adulation it seems to be garnering from the web dev community. I get it - at least there's progress of sorts. But, sigh.
> I doubt it would gain traction because almost everything enumerated in this post is a developer concern, not a user concern.
That's true for any developer platform. Users ultimately don't care how software is built, unless problems of the platform hurts the quality of the apps.
Yes, I'm using C as shorthand for "C and C-like languages", i.e. ahead of time compiled with manual memory management. It can do C++ too if you ship your own STL.
TeaVM has some sort of experimental wasm backend. Presumably it has to ship its own GC and can't do any kind of runtime profiling, which turns out to be a 20% win for Java and far, far more for other languages (like scripting languages).
My view is: if you were looking to bring to the web better performance and higher productivity, let alone more security, why would you combine low performance with low level languages? That's the worst of all worlds! And WebAssembly will be low performance for a while - they have to redo all the work done so far on optimising JIT compilers.
It's better than pretending Javascript is a "bytecode for the web," and transpiling to that. It's better than Flash or Java applets. If we want to consider the long-term archiving of software and keeping it runnable through the web (and I think we really really should consider that), we need something better than what we have, and WebAssembly seems like a step in the right direction.
> I doubt it would gain traction because almost everything enumerated in this post is a developer concern, not a user concern
I'm not sure this is true. My Mom doesn't really know the difference between an app and a website, but if I showed her the Facebook web app instead of the Facebook iPhone app I'm sure she would complain that it was not quite as responsive or didn't implement the same touch gestures.
If someone/a company wants to build an "app browser" and associated protocols and publish it then the market will decide how that goes. I think it's a cool idea, but I doubt it would gain traction because almost everything enumerated in this post is a developer concern, not a user concern.
In software, there's always going to be that temptation to start all over again due to fundamental mistakes that were made years ago. But I feel there are far too many entangled interests in the web for that strategy to make sense. Hey, if someone wants to work on it, god bless them.