Yes, that makes sense and I was expecting that feedback. There's a "future work" section where extensions and hyperlinking is listed, although linking can easily work as it does today (just to a .object file instead of directly a page). It's the next round of work when I find time/energy.

> But we go from a legible known shared base to a fractured maze of different illegible WebAssembly based platforms, that seem to offer strictly worse terms of use in every way to users.

Users, or developers? Mobile apps don't have those things but users preferred them anyway; apparently other than ad blocking there isn't a deep bench of killer extensions. And only devs can actually hack or modify things. For everyone else they have to rely on devs to do it for them.

There's another way to look at this though, which is that the web isn't actually that great at being hackable and it should be possible to do much better. Ian Hickson touches on this in some of his comments too. Maybe it was once but these days pages are so complex and often being generated on the fly from a big pile of minified JS, that the amount you can modify sites is fairly minimal unless you sign up to an endless break/fix treadmill of constantly repairing fragile selector expressions and you can forget about hot-patching JS entirely. User agent stylesheets never really happened either. And just like how browser makers killed off plugins, the power of extensions has been going down over time too. We've gone from Firefox extensions (can do anything), to Chrome extensions (can do far less but more robust), to Manifest v3 extensions (can do even less).

So how can it be done better?

The idea of an object being a graph of many other files is a decent start. Cleaner separation of code and data (no templating) means that there will be more APIs than before, just like how the rise of mobile apps caused many services that previously used only PHP/ASP style templating to develop proper APIs. When a site isn't important enough to justify an API, the "data" can simply be connection details for guest access to an RDBMS which the UI logs in to. In all these cases, you can then write custom tools on top of the data more easily.

Additionally view source barely works on the web any more, but a default.object can have multiple edges, one for an optimized minified piece of code and another for the un-optimized "view source"-able version. You can't easily express that with HTML today.

Unlike Hixie's index.wasm proposal, this one isn't specific to WebAssembly. You could in theory have a JVM based renderer too. I use the JVM as an example because it has a kind of extension mechanism, it's even called "agents", which allow you to inject code that can arbitrarily hook and rewrite other code on the fly. Agents are very powerful because they can change anything about the behavior of the app and the libraries it depends on, the nominal class-oriented type system helps here because the code you're looking for is more likely to have a stable name.

Finally, because object sites would be cleanly layered and each layer is signed a viewer can easily recognise a piece of code that's widely used and then swap it out for something else. Due to how caching and compilation work on the web, an extension that tries to detect a widely used library today would really struggle with that.

So that's three examples of how the proposed scheme could be more easily hackable than the web.

Now you might say, what's the guarantee? The focus on implementability and flexibility is a double-edged sword. On one hand, a highly implementable system is less in hoc to one or two giant corporations to provide the de-facto standard browsers. You could easily have dozens or hundreds written from scratch. On the other hand, such a system must inherently be more decentralized, and in a decentralized system you don't have a benign dictator telling people what they can and can't do. I personally would like a bit more decentralization, but it's totally expected that some people will say no, we want the Chrome team to be the dictators because we like their overall stances on things. You should recognize though that the hackability of the web isn't really guaranteed by its design, it's mostly dependent on whatever the Chrome team want to do, which is why Manifest v3 has kicked up such a fuss.