Doing security through language-machines (Java Applets / Flash / JavaScript) hasn't worked so well either. Spec-ex has pushed this from bad to worse.
If the idea is to run untrusted foreign code on our machines, I think some kind of emulator wrapped inside of a full-blown VM--with a super-easy interface for connecting/disconnecting peripherals, and a chrome-debugger-simple way to snoop and/or filter network traffic--would be a dramatic improvement over what's currently out there.
Totally academic discussion though. We know how to do better. Google and Apple dictate what we actually do. Facebook made a fairly successful end-run around them with React Native. The situation is obviously f'ed when Facebook is the underdog.
Even given the flaws of javascript as a language and the ugliness and perils of the web app model, it's still easily the most successful and widely used application platform ever. It's a stretch to say it hasn't worked very, very well, despite itself.
And it wasn't really "bolted on." The script tag was introduced in HTML 4, it, and the use of scripting in web pages, is as valid an element as everything else. People can reasonably disagree about the utility of javascript in the web, especially since it goes way beyond simply being a way to add simple interactivity to the DOM, but running applications on the web is not a violation of the web's intent, it is a part of the web's intent.
>I think some kind of emulator wrapped inside of a full-blown VM (...)
If we don't screw it up, I hope this is where webassembly will lead us in a few years.
Arguing it for things like the IBM PC, or Web 2.0--massive steps backward, taken purely due to the circumstances of whichever corporate overlord happened to dominate at the time--is denial.
The web won not because it was efficient, or well designed, or worse-is-better, or even sane. The web won because it was the closest thing we had in computing to a detente.
If we could write a native app without having to worry about getting squished by Apple or Google or Microsoft as soon as we start to make waves, we'd have left HTTP/HTML as the same old docs protocol/format TBL cooked-up.
A universal application platform with "download and go" deployment semantics is obviously a winner.
A distributed information publishing/viewing system is nice too (HTML/CSS/HTTP). Merging that and the application platform kinda compromises both, but also avoids the need for a distinction. If you were doing it from scratch though, building the information viewer on top of the application platform would be sane (rather than the other way around like we have now).
Sockets are good (We kinda already knew that). WebSockets are not as good a real sockets, and it'd be nice to have the real thing sometimes ...
A universal text-based marshaling mechanism is useful. JSON is maybe not the best it could be, but perfect is the enemy of good enough, I guess.
A universal RPC machines is too. Running XHR over HTTP is kinda broken, but ...
Half of what's done in browsers duplicates (often poorly) what's done in the underlying OS.
All that said, the vast majority of what you would change is basically pointless to think about because the deployed base is so large. Legacy code is always what gets you.
2. No CSS, no colors/fonts at all from sites, they should be system specified.
3. Something a bit like frames to handle updates of the browser defined content area rather than javascript.
4. Much richer tags. Enough to make a site like HN with <comment user="flukus" time="2019-02-08">foo</comment> and to have the browser render that.
5. No Video.
IME giving sites control of the display and layout is where the web went wrong.
Pertinent bit to your question starts at https://www.youtube.com/watch?v=oKg1hTOQXoY&t=1284