6 ms·

Ah yes, the developer dream to replace standardized markup & data & protocols with big massive impenetrable mountains of running code. Zero visible internetwork

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.

mike_hearn 4y ago
Thanks for reading it! "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.
- rektide 4y ago
  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 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.
  - mike_hearn 4y ago
    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.

mike_hearn 4y ago

Thanks for reading it! "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.

rektide 4y ago
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 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.
- mike_hearn 4y ago
  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.