Here are some thoughts:
- We need to decouple semantic structure definitions from browser releases. AXR gets this, but we can go further.
- Further, we ought to somehow retain HTTP as a transport layer and keep the content text-based but still remove the reliance on SPECIFIC languages.
What I imagine is very similar to AXR, only it would be something you could build AXR on TOP of. If you have a better idea than AXR, you could build that as well. Let the market decide. In fact, traditional HTML/CSS/JS could also be built on top of the new system.
As you're probably guessing, I'm imagining some sort of "assembly language" + object model that exposes the core primitives of structure, presentation, and behavior. Now when I say "object model" I don't mean the DOM. I mean something more primitive than that in which the traditional DOM and other things could be implemented.
The nice thing about this model is that the site can specify the location and version of the "compilers" it needs the browser to use to understand whatever it is sending. Most of the time, these would be well-known software components that ship with all browsers by default and are updated via standards bodies (just like now). The difference is that the standards can evolve independently of the browsers. Also, sites are free to use whatever they want as long as they can come up with it and the user agrees to download the components. When you think about it, this is really no different than "plugins", only now the content is not opaque.
Browsers now become exercises in implementing the primitive "HTTP VM" (or whatever it's called) in the most efficient way possible, adding end-user features like tabs and private browsing, and implementing new VM versions as they are released by the WhatWG or W3C. Hopefully, these can move more slowly because you shouldn't need new primitives as often.
It doesn't need to be said, but the HTTP VM can also be implemented server-side.
I know this idea is half-baked and has some major problems, like:
- How do you define what's "primitive" without getting into decade-long ontological discussions?
- How does this change how web crawlers work? Presumably, sites like Google would have to act like web clients and also download and run the compilers needed to parse each site. Could this be done with acceptable performance?
- What does this "assembly language" look like? If it looks like XML, aren't we back to AXR?
- If we keep going down to abstractions, we might as well just send LLVM code through HTTP and have web clients implement some "idealized real computer" with I/O and memory and all that. Then what are we doing? Isn't this something totally different? Why not just build that and hope it gains traction?
- JS JIT compilers are very finely-tuned. Will going down to a lower level of abstraction actually make performance suffer because there are less high-level things that can be recognized and inlined?
- Are HTML/CSS/JS ALREADY this assembly language of which I speak? If we just add the ability to define arbitrary HTML tags, allow them to "derive" existing tags, and define their default structure, presentation and behavior through JS calls or declarations on some "meta tagdef" element, aren't we mostly there? With so many browser vendors and versions, it's much easier to evolve than replace.
That said, my point is that no matter how good you can imagine the "next" HTML/CSS/JS, why fight the battle to bake it into all web browsers only to have to fight that battle AGAIN in another 20 years. Sure, revolutionize the platform. But revolutionize it toward abstractions and language independence.