I have this idea that if they split off WebAssembly, WebGL and WebAudio into a external format for applications it would be easier to implement than a full browser.
Your ideas is actually really cool (very tech noir).
But that's not what my idea is. My idea isn't really a browser. It's just a separate format/mimetype (.app or .game) for a app runtime.
Small projects could implement it. We can have it embeddable as a object in browsers. Clients other than major web browsers (Gopher, Dillo) could embed it. Embedded devices (Roku) could include support for it. It could even be used in a physical media like SDcards or DVDs.
Here's what I'm trying to reconcile: if the idea is to break off the awesome subset of multimedia web tech, because it would be easier to implement than a full browser -- I 100% agree! -- then why is there a need for a new mimetype/format?
Many things could be done better than the current HTML-as-laundry-list approach, but if we invent a new format, that adds the extremely difficult problem of getting everyone on board, rewriting things for it. The brilliance of asm.js (which gave birth to WASM) was that everyone had already implemented it before it existed.
Like you say it would be a subset. It's all just standard WebAssembly. The APIs of course would need to be made callable from WebAssembly but that's already planned for in browsers anyway.
Until browsers supported the mimetype they could just be served as .wasm files. Not that the mimetype is important at all I just think it more clearly states it's intended use.
You could probably do this now as a standalone Node app, if you want more explicit control over which APIs are available and where code can be run from.
The browser is indeed quite complex (and not just because of the massive historical baggage), but its job is to give the user control while safely downloading untrusted code and running it locally.
So, if your goal is to just have a simple standalone app I think you could stay largely compatible with APIs available in the browser environment.
> Easier implementation is the goal. There are currently only four companies working on a web implementation.
Easier implementation of a browser? You might find it interesting to see what Servo has chosen to implement and what they have not. Some things you'd think would be easily removable (such as document.write) turn out to not be so simple to skip.
One of the most valuable things about the Web is the care taken around backwards compatibility.
I do think it'd be quite interesting if you had a user agent that did the DOM differently (not sure what you have in mind specifically re: "documents didn't automatically gain the same privileges as applications") and focused just on providing a GL canvas and audio APIs.
I think you might find that these APIs aren't quite as nice when it comes to re-implementing things that CSS and DOM make easy, and it'd be hard for such a browser to really compete with existing browsers given the backwards-compat situation on the web (mandating GL would leave some devices behind, and web authors as a whole don't really adapt all that quickly).
In any case I think it might still be useful as a reference implementation / proof-of-concept on how minimal a web user agent can be, if it was just focused on hosting applications.
There's interest in wasm-land about having "non-web embeddings", which wouldn't assume things like JS APIs exist at all.
I think in that sort of world, you could probably find nicer APIs to target than WebGL and WebAudio... however if you don't mind still having a JS interpreted available then it'd probably be easy to build this sort of thing today using Node.
