Ask HN: How you would redesign a web browser?

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.

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.

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.

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.

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.

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.

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.

Just some thoughts though. I'm sure it's also broken in some ways but it could be pretty cool...good q.

P.S. this is thinking in visual terms, but I'd expect full & logical accessibility for screen readers, etc.

I would do a better job with two things: Keep better state of unused tabs without sucking up a ton of memory. Allow users to click "back" without reloading the page or jumping me to a different section of the page where the link that was just clicked on is no where to be found.

Not to sidetrack your topic of discussion, which I think is interesting, but I think it's an unfortunate misconception when people try to cast browsers as being intended to merely display documents. Hypermedia in general is a very old concept, dating back to the 60s, and it was never intended to be limited to merely documents. Audio/visual and interactive applications were inherent in the design of some of the earliest hypermedia systems which informed the design of the web.

The first websites on the WWW may have been just documents, mainly showing off basic hypertext concepts, but the basic elements for interactive applications were there. The web was just one system amongst a category of other examples of hypermedia which included more interactive and visual applications. NLS and Hypercard being great examples.

Not to say browsers couldn't be improved, or that new systems shouldn't strive to be better. But I disagree with the fundamental assertion that the web, and browsers, were ever intended to only display documents.

No data sent to 3rd party at request time. No headers, referrers, nothing.

If I could figure out a way, no JavaScript, either.

Replace JavaScript with .NET: it delivers byte code not source code, the byte code was specifically designed to allow JIT into efficient machine code with minimal overhead.

Replace HTTP and HTML with binary equivalents. A human-readable representation is nice when debugging things but binary equivalents are way faster, both throughput (handling strings is slow in general, too many branch mispredictions) and latency (to save bandwidth, text is typically combined with gzip or similar, they have internal buffers, they cause latency).

Implement data templating and data binding at HTML level. These things are essential for apps.

Keep the CSS, it's mostly fine.

Replace SVG with something binary, scriptless, and optimized for viewing only. Here's an example https://news.ycombinator.com/item?id=29629792