I think I'd like to see a node-based "communications design & rendering environment" where you could use an HTML node if you want, use JS or CSS or other stuff if you want. Or you could drop in some text into a plaintext node and there's your output.<p>I'd expect that you could also create nodes of nodes, in other words distribute a bunch of nodes as a single node. Here's a "typical website" node, here's an "asm.js person" node. And here's a "discussion site" node.<p>But then, you could connect those nodes together, or to other things, and make nodes of _those_. Let's say you connect a "podcast bot" node to your "discussion site" and it defines a new endpoint that hosts a pretty good podcast out of what it finds on the discussion site.<p>The concept would focus more on what's going where, in what form, and try to abstract out the connection types a bit more, similar to how a networking stack already has made a good start at being invisible. If my connection between HTML and JS can be less of "which CDN do I use, sigh, here's another link element to maintain over time" and more of like, a line or visual connector, that's the kind of invisibility that would be really helpful.<p>The browser could then be more of a generic design & rendering platform aimed more squarely at users--ideally even giving users/visitors node editing access. Imagine if "View Source" looked more like a design environment, with full code access for those who want it. But in the meantime, start arranging and editing, and see what happens.<p>That could be pretty amazing for opening the web up again, and providing really exceptional accessibility. To gauge how well a browser can compete, we could ask how open the experience is, what node-level freedoms it gives to users, etc. Or we could ask what level it provides--at a basic level maybe a browser only renders text and HTML nodes, but it's easily expanded by specification. Or maybe by specification it shows you the full node network, highlighting only the parts it can work with.<p>It would also ask more of a "how much tech does a publisher really need" question which I think is important given the lumbering stacks many publishers are forced to maintain these days. For example, last year I had to let a science fiction author know that Laravel was displaying their DB credentials for about 500ms until it was covered by their article div. This isn't anybody's fault necessarily, but we are talking about a website with text, links, images.<p>Just some thoughts though. I'm sure it's also broken in some ways but it could be pretty cool...good q.<p>P.S. this is thinking in visual terms, but I'd expect full & logical accessibility for screen readers, etc.