Ah yes, the developer dream to replace standardized markup & data & protocols with big massive impenetrable mountains of running code. Zero visible internetworking ethos.
Its an interesting document. Lots and lots and lots of challenges.
"the developer dream to replace standardized markup & data & protocols with big massive impenetrable mountains of running code"
Should be the opposite, right? You can still have markup with this scheme and it'd be easier than now, because you could use whatever markup scheme is most appropriate for the task - Markdown, ReST, TeX, something custom or whatever format that's most appropriate to the task. Today you have to do everything as HTML even if there are big impedance mismatches and the resulting files are unintelligible forests of divs, or generated on the fly from a megabyte of minified JS.
Once you pick a non-HTML markup scheme you have the question of how to render it to pixels, and that's where the design document goes with the composition.
The next step after is to recognize that the input data doesn't have to be textual markup. It can be any data format. Now tools can get the data behind the page in a standardised way without being distracted by the challenges of screen scraping away the navigation chrome and other junk.
The section on "none of these things have the idea of links so we just will have a manifest of them in side data" to me illustrates why these other markups don't seem like something I want to see grow on the net: they're unconnected mediums, without real notions of the web & the global address space & links. They're just their own things, used for isolated documents & apps.
I want to be OK with uncoupling & choice & freedom on the net. But the only use cases I can imagine now seem regressive. And like a Fall Of Babel. The web's power is in part that there is a user agent, with extensions, and view source, and a kick ass devtools any user can hack around in. I want upstart alt-web-mediums to have at least a plausible case for being perhaps better for the user. 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.
The reason I oppose the freedom of platform for devs is because it seems in direct tension with the freedom of the user. The internet isn't for devs, the internet is for end users. https://www.rfc-editor.org/rfc/rfc8890
If I saw a malleable, user-enabling platform arise, I'd be more willing to entertain this
nobles' rebellion against html.
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 the...
Great replies. I remain pretty cynical here but it's great having some positive pro-user ideas named, to look for & measure by as these works materialize.
I mildly agree that extensions & web hackability have been under assault, but I also keep hoping we're near the breakthrough, and there continues to be interest in unwinding many of the mistakes. Alas the bulk of my remaining reply seems to be a small laundry list of hopes on this,
Web Bundles seem like a purer collection-of-files effort, and regain many of the compression wins lost by many-files shipping modes, which together with Early Hints may let us ship something less heavily wrapped.
React is still the tool of choice, and it's vdom does require extensions to quite aggressively stay at war with the self-rebuilding large. But we're also seeing ongoing experimentation with signals for more precise & direct updating data-flows, and it might not be super obvious/might be fringe still but webcomponents continue to be explored & built (github, YouTube), kind of a silent small revolution.
User styles have one notable can't-live-without win, Dark Reader, which is incredibly popular & fantastic. Extensions for tab management, password management, and form saving also seem incredibly popular & wide-spread, just radical revamp of the user experience in incredible ways everywhere.
Overall the situation with the malleability of the web is not, in my view, anywhere near as dark as portrayed. A little web skills can muddle through a huge range of situations & issues, just playing on the surface without getting deep into the source. And tools like Playwright make the scripting the web easy & fun in a other level. The dooms speaking & discarding of user agency, pretending like it's not important or not needed, or pretending like it's not still a major & distinguishing part of the web feels like a misportrayal, and the motives here are all to overexaggurate the extent of the problem, justifying the the "pixel perfect" post-web applicationized next-thing being developer-centric, leaving standards protocols & human editable/viewable markup behind.
You're absolutely spot on about mv3 & it's rewriting the contract out from under the feet of the users, and the horror/angst of these greatly-dis-aligned incentives (users vs appstore/platform owner).
I've barely scratched the surface of this quite interesting doc & your replies, apologies for not making better use of my word count, but speaking to what I know & can address so far, I think. Thanks for sharing.
> Web Bundles seem like a purer collection-of-files effort
I didn't know about this, seems interesting but Chrome abandoned it in February. I guess the reason is that Safari and Firefox ignored it. Chrome seems to be bottlenecked by Firefox's engineering capacity and Apple's lack of interest.
Agree completely re: dark reader. I use it all the time. Still, a dark reader equivalent for other UI toolkits should be pretty easy to write (maybe not for C++/Rust stuff that tends to be less hookable). They all have some data structures that represent centralized style. And thinking about it ... the reason you don't need a dark reader extension for mobile or desktop apps is that the OS already can restyle UI on the fly, right? Dark mode seems to be automatic for apps using native toolkits (at least on Mac).
W.R.T. changes to tab management, I think that could be much easier with a more modular platform because the window management would be a separate app. Instead of writing an extension for a mega-monolithic browser, it'd be more like on Linux where you can write/use a separate window manager that can be independent of the content being displayed.
Some of the navigating into a bundle stuff is indeed not presently happening.
But there's a bunch of specs for signed exchanges & subresources that underpin & allow resource exchange, and which do have recent drafts. Webpackage seems to be doing OK ish. But yeah we bundles specifically do seem to be all expired.
9 comments
[ 3.1 ms ] story [ 38.1 ms ] threadIts an interesting document. Lots and lots and lots of challenges.
"the developer dream to replace standardized markup & data & protocols with big massive impenetrable mountains of running code"
Should be the opposite, right? You can still have markup with this scheme and it'd be easier than now, because you could use whatever markup scheme is most appropriate for the task - Markdown, ReST, TeX, something custom or whatever format that's most appropriate to the task. Today you have to do everything as HTML even if there are big impedance mismatches and the resulting files are unintelligible forests of divs, or generated on the fly from a megabyte of minified JS.
Once you pick a non-HTML markup scheme you have the question of how to render it to pixels, and that's where the design document goes with the composition.
The next step after is to recognize that the input data doesn't have to be textual markup. It can be any data format. Now tools can get the data behind the page in a standardised way without being distracted by the challenges of screen scraping away the navigation chrome and other junk.
I want to be OK with uncoupling & choice & freedom on the net. But the only use cases I can imagine now seem regressive. And like a Fall Of Babel. The web's power is in part that there is a user agent, with extensions, and view source, and a kick ass devtools any user can hack around in. I want upstart alt-web-mediums to have at least a plausible case for being perhaps better for the user. 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.
The reason I oppose the freedom of platform for devs is because it seems in direct tension with the freedom of the user. The internet isn't for devs, the internet is for end users. https://www.rfc-editor.org/rfc/rfc8890
If I saw a malleable, user-enabling platform arise, I'd be more willing to entertain this nobles' rebellion against html.
> 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 the...
I mildly agree that extensions & web hackability have been under assault, but I also keep hoping we're near the breakthrough, and there continues to be interest in unwinding many of the mistakes. Alas the bulk of my remaining reply seems to be a small laundry list of hopes on this,
Web Bundles seem like a purer collection-of-files effort, and regain many of the compression wins lost by many-files shipping modes, which together with Early Hints may let us ship something less heavily wrapped.
React is still the tool of choice, and it's vdom does require extensions to quite aggressively stay at war with the self-rebuilding large. But we're also seeing ongoing experimentation with signals for more precise & direct updating data-flows, and it might not be super obvious/might be fringe still but webcomponents continue to be explored & built (github, YouTube), kind of a silent small revolution.
User styles have one notable can't-live-without win, Dark Reader, which is incredibly popular & fantastic. Extensions for tab management, password management, and form saving also seem incredibly popular & wide-spread, just radical revamp of the user experience in incredible ways everywhere.
Overall the situation with the malleability of the web is not, in my view, anywhere near as dark as portrayed. A little web skills can muddle through a huge range of situations & issues, just playing on the surface without getting deep into the source. And tools like Playwright make the scripting the web easy & fun in a other level. The dooms speaking & discarding of user agency, pretending like it's not important or not needed, or pretending like it's not still a major & distinguishing part of the web feels like a misportrayal, and the motives here are all to overexaggurate the extent of the problem, justifying the the "pixel perfect" post-web applicationized next-thing being developer-centric, leaving standards protocols & human editable/viewable markup behind.
You're absolutely spot on about mv3 & it's rewriting the contract out from under the feet of the users, and the horror/angst of these greatly-dis-aligned incentives (users vs appstore/platform owner).
I've barely scratched the surface of this quite interesting doc & your replies, apologies for not making better use of my word count, but speaking to what I know & can address so far, I think. Thanks for sharing.
> Web Bundles seem like a purer collection-of-files effort
I didn't know about this, seems interesting but Chrome abandoned it in February. I guess the reason is that Safari and Firefox ignored it. Chrome seems to be bottlenecked by Firefox's engineering capacity and Apple's lack of interest.
Agree completely re: dark reader. I use it all the time. Still, a dark reader equivalent for other UI toolkits should be pretty easy to write (maybe not for C++/Rust stuff that tends to be less hookable). They all have some data structures that represent centralized style. And thinking about it ... the reason you don't need a dark reader extension for mobile or desktop apps is that the OS already can restyle UI on the fly, right? Dark mode seems to be automatic for apps using native toolkits (at least on Mac).
W.R.T. changes to tab management, I think that could be much easier with a more modular platform because the window management would be a separate app. Instead of writing an extension for a mega-monolithic browser, it'd be more like on Linux where you can write/use a separate window manager that can be independent of the content being displayed.
https://groups.google.com/a/chromium.org/g/blink-dev/c/VS9Ug...
https://developer.chrome.com/docs/web-platform/web-bundles/
"The experimental implementation of navigation to Web Bundles was removed from Chrome in February 2023."
https://chromestatus.com/feature/5377722941440000
Implementation status: No longer pursuing (tracking bug)
But there's a bunch of specs for signed exchanges & subresources that underpin & allow resource exchange, and which do have recent drafts. Webpackage seems to be doing OK ish. But yeah we bundles specifically do seem to be all expired.
https://github.com/WICG/webpackage#specifications