It’s good to see people asking the right questions, but unfortunately this post seems to be mostly wrong answers.
I think this situation is a lot like the Scheme programming language around the release of r6rs; everyone was dissatisfied with how big it got, and in the next rev it got split into r7rs-small which addressed the needs of people who wanted something easy to implement and good for teaching, and an r7rs-big superset which was for people who wanted maximal practicality to build cool applications in. A solution like that would be a much better fit than going off to create something that’s gratuitously incompatible.
But we don’t have a hard distinction like “students” to work with here. A browser that looked like a regular browser and worked with some pages, but then failed to work when clicking on a hyperlink, such a browser would run pretty hard into the uncanny valley. The word people would call it is “broken”.
There’s no such thing as a little compatible. The only way to stop supporting Turing-complete features in the document web is to own that we’re going our own way, and set expectations appropriately on every single page that the browser visits.
A browser that looked like a regular browser and worked with some pages, but then failed to work when clicking on a hyperlink, such a browser would run pretty hard into the uncanny valley. The word people would call it is “broken”.
This is literally the experience I get in my primary browser where I run noscript, and I love it, because good web sites are so fast, but shitty web sites are … still shitty. I have a backup browser I use for shitty web sites and web applications. If more people made web sites that worked as web sites and we saved web applications for things that actually needed to be web applications, it would be even better.
Noscript sounds interesting, and I’m going to check it out. That sounds like something I would like, but that unfortunately does not sound like something everyone would want. Compatibility is mostly binary if people are to accept something as “working”
Well you could simply require a special HTTP header like: X-New-Web: true for anyone to opt in. If the browser doesn’t see that header, then it can just break.
A major point is that I would like to publish my content on the new web and the old web. I don’t want to make two different versions of the site.
I would change the HTML of http://www.oilshell.org to accomodate some “new web”, if someone drafted a spec and had a minimal browser (similar to SerenityOS or something). As long as it’s more or less a subset of HTML, CSS, JS. I got rid of Google Analytics quite awhite ago, so it should work fine.
Making a whole other build toolchain from Markdown is possible, but not really desirable. And my Markdown contains HTML. So those posts would be too much work to convert to the new web.
A dirt simple HTML parser is very easy to write. I already wrote one and I’m tempted to do some kind of simple “batch” HTML renderer myself…
That works from the writer/publisher’s perspective, but look at it from your viewer’s perspective. If they use newBrowser they can read your site, but you risk a bad experience anytime you link to something from the old web. In practice your viewers will get frustrated using newBrowser.
We’ve had 25 years now to support screenreaders and other niche apps, and they show us what happens to niche use cases. The only way to make this use case work is to commit to it entirely. It’ll take a longer time to build an audience, but I think the growth has a better chance of being monotonic, where a more compatible attempt will start from a higher base but also find it difficult to break through some ceiling.
Now that I think about it, this disagreement about compatibility also explains our respective projects :)
No matter what, you will have URLs on the new web. Just like there are URLs on billboards.
I guess the browser could pre-fetch the links and for X-New-Web: true it could display it in a different color. You would have red links for current web, and green links for new web, etc.
Also, it occurs to me that “a new web” was already invented, and in probably the most promising place: the transition from desktop to mobile, mobile devices vastly outnumbering desktop these days:
iPhone could have used it. It was meant for such devices. And making Safari run on a phone wasn’t easy. But they went with the compatible web instead …
Prefetching links is klunky. You can’t link to red sites too often. No matter what you do, trying to change the web in incompatible ways must be accompanied by changes to behavior. The medium has to influence the message. Trying to ignore the representation is a siren. If you want to do that, just stick with the current web.
Now, that’s just my opinion, and I may be wrong. Starting from scratch may also not work. But I started this thread responding to the idea of subsetting html. Regardless of whether you agree with my approach, I hope the problems with the subsetting approach are at least equally plausible.
Yeah at this point it’s theoretical – I don’t think either solution really works… “Replacing the web” or “a clean start for the web” is close to impossible. It will take at least 100 years, i.e. I wouldn’t bet on it in my lifetime.
I would liken it to “replacing Windows”. Well that never happened. OS X became a lot more popular, but it’s still like 5% market share I’d guess. Linux never replaced Windows. Thousands of businesses still run on Windows.
But what did happen is iOS and Android. Windows became less important. So the web isn’t going to be replaced by anything that looks like it. It won’t be replaced by a simple alternative that serves Markdown, or any subset of HTML/CSS/JS.
There will have to be some compelling new functionality for people to adopt and move there. I don’t know what that is, but subsetting alone doesn’t work. (If I had to place my bets, it would be something involving video, but that’s a different discussion)
I don’t think there’s anything wrong with letting the OS/Browser/Client choose the behavior of handling out-of-band links. I believe that one of the things that led to the huge scope creep of the web was the insistence of handling everything over the web: images, text, videos, real time streams, games, etc. All of that has caused tremendous bloat in the HTTP protocol (everything from ETags to HTTP pipelining) and still makes HTTP a “jack of all trades, master of none” protocol.
I’m also a big fan of purpose-built apps myself, because they offer me control on how I consume content. I often scrape sites or host local proxies to let me browse portions of the web with the experience I prefer. With the current system of the web handling everything, this sort of behavior is difficult and not-encouraged. I’d love to see a world where individuals controlling their content was encouraged.
Looks like you edited the comment after my previous response. By no means am I suggested killing all links. There are precedents for groups of pages that can link within the group but not between groups. Links from www to gopher don’t work without special software, so in practice they often behave like separate universes. I think that’s fine, even great.
I would change the HTML of http://www.oilshell.org to accomodate some “new web”, if someone drafted a spec and had a minimal browser (similar to SerenityOS or something). As long as it’s more or less a subset of HTML, CSS, JS. I got rid of Google Analytics quite awhite ago, so it should work fine.
Gemini (mentioned in the article) has a Markdown-adjacent format (which I informally called “Gemtext”) and has several server and client implementations that exist, and the protocol is simple enough that even clients poorly maintained still are widely compatible with the rest of the ecosystem. It remains to be seen if this continues, but I would love to see Oil Shell’s presence on Gemini!
Making a whole other build toolchain from Markdown is possible, but not really desirable. And my Markdown contains HTML. So those posts would be too much work to convert to the new web.
This is a tough one, but HTML is not really designed for reified document representation. HTML’s “ancestor” SGML fit that role more tightly, but after the WHATWG dispute was resolved, HTML became purely a presentation layer with some vestiges of its SGML past. XHTML was an attempt to make a reified document representation, but due to the aforementioned WHATWG dispute, XHTML was abandoned. Nowadays, HTML is a moving target that is meant to be a language for web presentation and an intermediate language for web applications. Relying on HTML feels a little fraught to me given this status.
This doesn’t really remove the pain of maintaining documents in both a reified form (Markdown or something else) and then having to concretize them into HTML and other formats. In Gemini space, there’s been a lot of talk of the experience (read: pain) of having to unify Gopher, HTML, and Gemini content into Markdown or some other reified format. I’ve wondered idly myself whether XML deserves a refresh, because I see creeping ad-hoc alternatives (Pandoc, Docbook, Jupyter Notebooks, etc) instead of a single reified document format.
I don’t understand the last 2 paragraphs. I don’t know what “reified document representation” is. IMO HTML is a perfectly good format for documents. It’s not a great format for writing, but that’s why Markdown exists. However, Markdown needs HTML to express tables, image tags, etc.
I have many scripts that generate HTML, that do not use Markdown, like:
It is perfectly fine to have a design goal for a simple document format and network protocol. However I would not call that a “new web” (not that you did). It’s something else.
I would make an analogy to shell here. I assume that the user is busy and has other things to do. Shell is a tool to get a job done, which may be a minor part of a larger project.
That is, I don’t think that everyone is going to spend hours poring over shell scripts. I imagine they have some crappy bash script that is useful and they don’t want to rewrite. So Oil is purposely compatible and provides a smooth upgrade path.
Likewise, a website is usually a minor part of a larger project. If there’s no upgrade path, and it doesn’t provide unique functionality, then I’m not going to bother to look at it. That’s not to say that other people won’t be attracted to simplicity, or another aesthetic goal.
But in terms of “getting work done” I don’t see the appeal to a new format. Just like I don’t care to rewrite thousands of lines of shell scripts (which I have) in another language just for fun.
It’s for that reason I stick with HTML 4.01 for my blog. Yes, there are a few tags in HTML5 that would be nice to use, but HTML5 is a moving target. I’ll stick with HTML 4, thank you very much.
This confuses me. HTML5 is still very backwards-compatible. I believe there have been a handful of breaking changes but overall it’s basically additive. The “state of the art” (with SPAs and whatnot) changes, sure, but I mean… you can just ignore that. I do.
This is a subject I have considered quite often, and I don’t think “starting from scratch” is a realistic solution. At this point I’d argue the web is similar to x86 bytecode. Extremely complicated, and very few companies can design chips for it (browsers). The solution is that we need higher level code that compiles to the HTML/CSS/JS used by the browsers. I think things like Svelte and Solid are a step in the right direction.
Once we have tools that treat the browser as essentially being a bytecode, then something like Arm can come around and the same code can be cross-compiled to that. A simpler spec, but just as full-featured.
I just don’t think there will ever be a quick replacement for the web – and I really wish there could be. Its simply too standard and “good enough” to be wholesale replaced. The browser mono-culture is a huge shame, but I’m hopeful with better tooling the situation can be improved, and over time migrated entirely away from.
The solution is that we need higher level code that compiles to the HTML/CSS/JS used by the browsers
Yikes, adding even more layers I don’t think is going to help anything.
But the web actually is reasonably compatible. You can go to lots of websites with lynx still, to this day. I think all we really need to do is to start encouraging the “viewable with any browser” ethos again, only using the features you actually need, and utilizing their capability to gracefully degrade to keep the experience workable.
I completely agree with you but I also think that will never happen. I’ve been at too many companies and worked with too many people who have used React because “we might need it someday.” The complexity is there and it will continue to grow, due to things like “developer velocity.”
We already have hundreds of layers for a crappy, bloated web. This is just changing what the layers above do. Rather than incrementally improving the HTML/CSS/JS workflow, which the layers do now, a new layer should (and will) be built which completely replaces it (and compiles down to it).
I would love for the web to go back to its roots, and for webpages that is just text to not use JS to render the text. But that won’t happen.
I don’t see how it is worse, we already have things like Babel and Typescript which compile down to JS and treat JS as effectively a bytecode. I’m saying we extend that idea to HTML/CSS so we have a cohesive bytecode – not just JS that then generates the other two.
Why can’t we have a language/tooling which lets people output just optimized HTML and CSS, and then easily extends with JS as interactive features are needed? Its the same concept as what we have now but just taken further.
Yes – the root of the problem is that the HTML, CSS, etc is ridiculously complicated and hard to implement correctly and performantly. There’s no tractable path for a modern, competitive browser to exist without a megacorp funding it.
Compiling things HTML doesn’t fundamentally change things. It just adds more layers that need to be understood and debugged. Nothing is simplified – it’s complexified. Browsers remain ridiculously expensive to maintain, and Google remains a monoculture. But now there’s an extra layer of goop between what developers write and what shows up on the screen. It also makes the code that gets delivered to the user far more opaque.
I’d take the current situation, bad as it is – but with fewer layers, over adding another layer that needs to be understood, maintained, and debugged through.
the root of the problem is that the HTML, CSS, etc is ridiculously complicated and hard to implement correctly and performantly. There’s no tractable path for a modern, competitive browser to exist without a megacorp funding it.
I agree with you here. However that complexity has been built up over time, and arguably only a subset of HTML/CSS/JS is actually needed. The rest is due to legacy reasons, and adds a considerable amount of artificial complexity.
Compiling things HTML doesn’t fundamentally change things. It just adds more layers that need to be understood and debugged. Nothing is simplified – it’s complexified.
Yes, complexity always goes somewhere. But compiling to HTML/CSS/JS does fundamentally change things – it moves that complexity to the developer side rather than the client side. With an abstraction on top of HTML/CSS/JS that outputs only the most modern subset of HTML/CSS/JS the client side of things is simplified. If miraculously everyone started making their websites with this new abstraction, then browsers would only need to support the feature-set that this abstraction uses – not the entire spec (which cuts down on complexity drastically).
Of course there are plenty of issues with this approach – such as any abstraction on top of HTML/CSS/JS is going to be incredibly complicated by itself, or that not enough people will use this abstraction to fundamentally shift the complexity load of browsers.
I think there are many parallels to x86 and Arm. LLVM, despite being another “layer” has made it trivial to build software that runs on both x86 and Arm (and RISC-V), where the newer alternatives are significantly simpler.
In my experience, that’s simply not true. A good design can eliminate a huge amount of complexity – and a huge amount of complexity comes from bolting things on to something that’s not fit for purpose.
In my experience, that’s simply not true. A good design can eliminate a huge amount of complexity – and a huge amount of complexity comes from bolting things on to something that’s not fit for purpose.
Accidental complexity, yes; essential complexity, no.[1] Most of web development as it stands is primarily accidental complexity – I think we can all agree on that. The issue with browsers is that they have to compensate for all of that accidental complexity, which I also think we can agree on.
My argument is that there is a subset of the current web standards that encompasses the essential complexity of the web – the core complexity needed to render and manage an interactive user interface. You’re arguing that people should just use this subset as is – which I agree, would be nice if that was done. However, people are clearly not doing this.
But if there was an abstraction built on top of the current web standards which abstracts away all of this accidental and essential complexity from the developers, we can more easily migrate away from all of the accidental complexity and agree on the essential complexity. Once that is done, then browsers can just implement the subset of the web that have the essential complexity.
Differentiating between essential complexity and accidental complexity is absolutely crucial here, because building a “simple” abstraction on top of essential complexity leaves holes and edge-cases.
Many of the listed problems would be solved by simply disabling JavaScript for “the document web”, block remote resources, etc. No need to reinvent everything. We could optionally go back to XHTML 1.0 (or HTML 4 Strict), use object tags for video/audio and call it a day. As for CSS, we’d need to remove its Turing completeness to avoid it becoming “the next JS”. If any functionality is missing, they can be reintroduced as HTML elements after careful consideration. I do like the HTML5 tags like <nav> and <aside> which can be be used by screen readers etc. to focus on the content on of the page.
We could also keep JS, but put a sleep(0.01) between every JS statement that needs to be executed making it slow on purpose and forcing developers to only write the JS that is really needed to optimize some aspects of the site.
Why in the world would anyone opt in to that, though?
On my (static) website, you can read almost everything but if you let me load JavaScript, then you get some cute toys I wrote and you get to see Webmentions loaded from webmention.io. I’ve mostly written my website “the right way”, but I’m disincentivized from switching to the “document web” because it breaks a few things for no benefit.
“Well yes, but you’d do it because you want to be disciplined and support a new kind of experience.” If everyone had this kind of discipline, we wouldn’t have this problem in the first place because everyone would write good semantic HTML and bare-minimum JS.
“Sure, but it wouldn’t be opt-in because we’d get all the browsers to enforce these restrictions for the document web, and everyone would be forced to change.” How would you figure out what’s the document web and what’s the application web? In particular, without pages being able to lie about being on the application web?
I’d propose the distinction between “application web” and “document web” is this: if you need JS (at all) it is the “application web”. If a site works without requiring any JS, it is part of the “document web”, even if it has optional JS to tweak some little UI/UX things otherwise not available/possible.
Webmentions can also be used without any JS in the browser, at least back when I implemented support for it. That has the benefit of increasing the performance for your users and does not require them to leak the sites they visit to a (centralized?) service.
It requires a little bit of discipline yes, and not everything is possible. This is something everyone has to decide for themselves obviously. For me figuring all this stuff out is part of the fun! I avoid centralized systems, especially “big tech” or surveillance capitalists, try to protect my users and make it as fast as possible. I want to be part of the decentralized “document web”…
Interesting and thoughtful. Thanks. Some random comments:
I think this is largely that the application stack for building websites has replaced the document stack in a lot of places. Where we would use Jekyll or server-side rendering, we now use React or Vue.js
It’s not only that. I’ve built a wonderful little blogging engine just using standalone Vue.js. The problem isn’t Vue, it’s “standalone”. People start doing something with documents, like blogging, then they decide they’d like a little “sizzle”, so they want to add something. There’s no natural stopping point for this, though. I was happy using standalone Vue, but most people who pick it up start using it in a pipeline, perhaps with some back-end thrown in. They’ve almost instantly gone from “I’d like something that looks cool” to “Holy cow! I’m an application programmer!”
If you built a simple markdown pipeline, know what would happen? People would be instantly clamoring for new stuff to cram into markdown. It’s what happened with html and it’d happen again for the same reasons. People want their documents to have some cool gadget that distinguishes them (Facebook feed, anyone?), and there’s no natural stopping point between beginning to act on that desire and trying to cram a video game into the browser, which is approximately where we are now.
I like the idea of separating the concepts. I’d almost think you’d want separate protocols, though, and some clear acid test for determining what went in each camp. Otherwise we’d be right back here in another 20 years with the same problems.
First, you need a minimal, standardized markup language for sending documents around … Markdown’s strict specified variation, Commonmark, seems like a pretty decent choice
Markdown isn’t a subset of HTML. I think the point was that if you have something that’s a syntactically compatible subset of HTML, people won’t feel compelled to drop their current web browsers.
It has a subset of the functionality. I don’t think a non-syntactically-compatible subset will compel people any more than a syntactically-compatible subset.
My solution is just to not write bloated pages. Periodically I check that pages I care about can render even in ancient browsers (for gits and shiggles I have a Solbourne S3000 with an old version of Netscape Navigator which serves splendidly for this purpose), though for retrocomputing I still think Gopher ticks more boxes.
Markdown is too limited for proper document authoring in my opinion, especially if (as it is appearently suggested by the original article) no CSS is allowed for styling. It is the purpose of a document to convey information, and the presentation should support this goal to the highest extend possible. For instance, with pure markdown you cannot have real figures with labels as Markdown only supports inline images. Trying to properly get that in a Markdown document without resorting to HTML is very difficult. There are other cases than this one, and that’s why I’m against using Markdown for a new, minimal document web, albeit I like the idea of such a document web. Before we make a choice on the markup language to be used, there should be a proper evaluation of what is actually needed for both simple and complex (think e.g. scientific) documents.
I was going to say this as well. Any document system for the ‘new web’ should be robust enough to reproduce hand-typeset 16-century documents, in addition to CSS-styled documents of today. It seems like a very programmer-centric view to say that everyone should be limited to documents that can be comfortably read in an 80x24 monochrome VTT.
but markdown supports embedded html tags… so to “fully” support it means supporting html too! (I really don’t understand why people like markdown) Of course it could be a subset :)
Which is mainly due to the fact that the web is rendered on a broad range of devices nowadays. Which is a good thing for web-developers.
Apart from that, I think tooling for web development is better than ever. Frameworks like React allow developers to create frontends that handle complexity on an unprecedented scale. Even CSS improved. There is flexbox, whereas in the past one was forced to use some JavaScript library for a responsive layout.
Frameworks like React allow developers to create frontends that handle complexity on an unprecedented scale.
I would argue (from professional experience) that most frontend developers don’t “handle” complexity at all in React, and further that the goal should be to reduce the complexity.
It’s good to see people asking the right questions, but unfortunately this post seems to be mostly wrong answers.
I think this situation is a lot like the Scheme programming language around the release of r6rs; everyone was dissatisfied with how big it got, and in the next rev it got split into r7rs-small which addressed the needs of people who wanted something easy to implement and good for teaching, and an r7rs-big superset which was for people who wanted maximal practicality to build cool applications in. A solution like that would be a much better fit than going off to create something that’s gratuitously incompatible.
But we don’t have a hard distinction like “students” to work with here. A browser that looked like a regular browser and worked with some pages, but then failed to work when clicking on a hyperlink, such a browser would run pretty hard into the uncanny valley. The word people would call it is “broken”.
There’s no such thing as a little compatible. The only way to stop supporting Turing-complete features in the document web is to own that we’re going our own way, and set expectations appropriately on every single page that the browser visits.
This is literally the experience I get in my primary browser where I run noscript, and I love it, because good web sites are so fast, but shitty web sites are … still shitty. I have a backup browser I use for shitty web sites and web applications. If more people made web sites that worked as web sites and we saved web applications for things that actually needed to be web applications, it would be even better.
Noscript sounds interesting, and I’m going to check it out. That sounds like something I would like, but that unfortunately does not sound like something everyone would want. Compatibility is mostly binary if people are to accept something as “working”
Well you could simply require a special HTTP header like:
X-New-Web: truefor anyone to opt in. If the browser doesn’t see that header, then it can just break.A major point is that I would like to publish my content on the new web and the old web. I don’t want to make two different versions of the site.
I would change the HTML of http://www.oilshell.org to accomodate some “new web”, if someone drafted a spec and had a minimal browser (similar to SerenityOS or something). As long as it’s more or less a subset of HTML, CSS, JS. I got rid of Google Analytics quite awhite ago, so it should work fine.
Making a whole other build toolchain from Markdown is possible, but not really desirable. And my Markdown contains HTML. So those posts would be too much work to convert to the new web.
A dirt simple HTML parser is very easy to write. I already wrote one and I’m tempted to do some kind of simple “batch” HTML renderer myself…
I really wonder if people calling for a gratuitously incompatible markdown-based “new web” understand that HTML documents are valid markdown…
That works from the writer/publisher’s perspective, but look at it from your viewer’s perspective. If they use newBrowser they can read your site, but you risk a bad experience anytime you link to something from the old web. In practice your viewers will get frustrated using newBrowser.
We’ve had 25 years now to support screenreaders and other niche apps, and they show us what happens to niche use cases. The only way to make this use case work is to commit to it entirely. It’ll take a longer time to build an audience, but I think the growth has a better chance of being monotonic, where a more compatible attempt will start from a higher base but also find it difficult to break through some ceiling.
Now that I think about it, this disagreement about compatibility also explains our respective projects :)
Well say I want to link to this thread on lobste.rs.
The alternative to linking is to write on the new web “open up your old web browser and visit https://lobste.rs/s/tmzyrk/clean_start_for_web”. Is that really better?
No matter what, you will have URLs on the new web. Just like there are URLs on billboards.
I guess the browser could pre-fetch the links and for
X-New-Web: trueit could display it in a different color. You would have red links for current web, and green links for new web, etc.Also, it occurs to me that “a new web” was already invented, and in probably the most promising place: the transition from desktop to mobile, mobile devices vastly outnumbering desktop these days:
https://en.wikipedia.org/wiki/Wireless_Application_Protocol
iPhone could have used it. It was meant for such devices. And making Safari run on a phone wasn’t easy. But they went with the compatible web instead …
Prefetching links is klunky. You can’t link to red sites too often. No matter what you do, trying to change the web in incompatible ways must be accompanied by changes to behavior. The medium has to influence the message. Trying to ignore the representation is a siren. If you want to do that, just stick with the current web.
Now, that’s just my opinion, and I may be wrong. Starting from scratch may also not work. But I started this thread responding to the idea of subsetting html. Regardless of whether you agree with my approach, I hope the problems with the subsetting approach are at least equally plausible.
Yeah at this point it’s theoretical – I don’t think either solution really works… “Replacing the web” or “a clean start for the web” is close to impossible. It will take at least 100 years, i.e. I wouldn’t bet on it in my lifetime.
I would liken it to “replacing Windows”. Well that never happened. OS X became a lot more popular, but it’s still like 5% market share I’d guess. Linux never replaced Windows. Thousands of businesses still run on Windows.
But what did happen is iOS and Android. Windows became less important. So the web isn’t going to be replaced by anything that looks like it. It won’t be replaced by a simple alternative that serves Markdown, or any subset of HTML/CSS/JS.
There will have to be some compelling new functionality for people to adopt and move there. I don’t know what that is, but subsetting alone doesn’t work. (If I had to place my bets, it would be something involving video, but that’s a different discussion)
I don’t think there’s anything wrong with letting the OS/Browser/Client choose the behavior of handling out-of-band links. I believe that one of the things that led to the huge scope creep of the web was the insistence of handling everything over the web: images, text, videos, real time streams, games, etc. All of that has caused tremendous bloat in the HTTP protocol (everything from ETags to HTTP pipelining) and still makes HTTP a “jack of all trades, master of none” protocol.
I’m also a big fan of purpose-built apps myself, because they offer me control on how I consume content. I often scrape sites or host local proxies to let me browse portions of the web with the experience I prefer. With the current system of the web handling everything, this sort of behavior is difficult and not-encouraged. I’d love to see a world where individuals controlling their content was encouraged.
Looks like you edited the comment after my previous response. By no means am I suggested killing all links. There are precedents for groups of pages that can link within the group but not between groups. Links from www to gopher don’t work without special software, so in practice they often behave like separate universes. I think that’s fine, even great.
Gemini (mentioned in the article) has a Markdown-adjacent format (which I informally called “Gemtext”) and has several server and client implementations that exist, and the protocol is simple enough that even clients poorly maintained still are widely compatible with the rest of the ecosystem. It remains to be seen if this continues, but I would love to see Oil Shell’s presence on Gemini!
This is a tough one, but HTML is not really designed for reified document representation. HTML’s “ancestor” SGML fit that role more tightly, but after the WHATWG dispute was resolved, HTML became purely a presentation layer with some vestiges of its SGML past. XHTML was an attempt to make a reified document representation, but due to the aforementioned WHATWG dispute, XHTML was abandoned. Nowadays, HTML is a moving target that is meant to be a language for web presentation and an intermediate language for web applications. Relying on HTML feels a little fraught to me given this status.
This doesn’t really remove the pain of maintaining documents in both a reified form (Markdown or something else) and then having to concretize them into HTML and other formats. In Gemini space, there’s been a lot of talk of the experience (read: pain) of having to unify Gopher, HTML, and Gemini content into Markdown or some other reified format. I’ve wondered idly myself whether XML deserves a refresh, because I see creeping ad-hoc alternatives (Pandoc, Docbook, Jupyter Notebooks, etc) instead of a single reified document format.
I don’t understand the last 2 paragraphs. I don’t know what “reified document representation” is. IMO HTML is a perfectly good format for documents. It’s not a great format for writing, but that’s why Markdown exists. However, Markdown needs HTML to express tables, image tags, etc.
I have many scripts that generate HTML, that do not use Markdown, like:
https://www.oilshell.org/release/0.8.pre10/test/spec.wwz/survey/osh.html
https://www.oilshell.org/release/0.8.pre10/benchmarks.wwz/osh-parser/
It is perfectly fine to have a design goal for a simple document format and network protocol. However I would not call that a “new web” (not that you did). It’s something else.
I would make an analogy to shell here. I assume that the user is busy and has other things to do. Shell is a tool to get a job done, which may be a minor part of a larger project.
That is, I don’t think that everyone is going to spend hours poring over shell scripts. I imagine they have some crappy bash script that is useful and they don’t want to rewrite. So Oil is purposely compatible and provides a smooth upgrade path.
https://news.ycombinator.com/item?id=24083764
Likewise, a website is usually a minor part of a larger project. If there’s no upgrade path, and it doesn’t provide unique functionality, then I’m not going to bother to look at it. That’s not to say that other people won’t be attracted to simplicity, or another aesthetic goal.
But in terms of “getting work done” I don’t see the appeal to a new format. Just like I don’t care to rewrite thousands of lines of shell scripts (which I have) in another language just for fun.
It’s for that reason I stick with HTML 4.01 for my blog. Yes, there are a few tags in HTML5 that would be nice to use, but HTML5 is a moving target. I’ll stick with HTML 4, thank you very much.
This confuses me. HTML5 is still very backwards-compatible. I believe there have been a handful of breaking changes but overall it’s basically additive. The “state of the art” (with SPAs and whatnot) changes, sure, but I mean… you can just ignore that. I do.
This is a subject I have considered quite often, and I don’t think “starting from scratch” is a realistic solution. At this point I’d argue the web is similar to x86 bytecode. Extremely complicated, and very few companies can design chips for it (browsers). The solution is that we need higher level code that compiles to the HTML/CSS/JS used by the browsers. I think things like Svelte and Solid are a step in the right direction.
Once we have tools that treat the browser as essentially being a bytecode, then something like Arm can come around and the same code can be cross-compiled to that. A simpler spec, but just as full-featured.
I just don’t think there will ever be a quick replacement for the web – and I really wish there could be. Its simply too standard and “good enough” to be wholesale replaced. The browser mono-culture is a huge shame, but I’m hopeful with better tooling the situation can be improved, and over time migrated entirely away from.
Yikes, adding even more layers I don’t think is going to help anything.
But the web actually is reasonably compatible. You can go to lots of websites with lynx still, to this day. I think all we really need to do is to start encouraging the “viewable with any browser” ethos again, only using the features you actually need, and utilizing their capability to gracefully degrade to keep the experience workable.
I completely agree with you but I also think that will never happen. I’ve been at too many companies and worked with too many people who have used React because “we might need it someday.” The complexity is there and it will continue to grow, due to things like “developer velocity.”
We already have hundreds of layers for a crappy, bloated web. This is just changing what the layers above do. Rather than incrementally improving the HTML/CSS/JS workflow, which the layers do now, a new layer should (and will) be built which completely replaces it (and compiles down to it).
I would love for the web to go back to its roots, and for webpages that is just text to not use JS to render the text. But that won’t happen.
+1 for Svelte, it truly is a joy to work with.
That sounds like a worse situation than today’s web.
I don’t see how it is worse, we already have things like Babel and Typescript which compile down to JS and treat JS as effectively a bytecode. I’m saying we extend that idea to HTML/CSS so we have a cohesive bytecode – not just JS that then generates the other two.
Why can’t we have a language/tooling which lets people output just optimized HTML and CSS, and then easily extends with JS as interactive features are needed? Its the same concept as what we have now but just taken further.
Yes – the root of the problem is that the HTML, CSS, etc is ridiculously complicated and hard to implement correctly and performantly. There’s no tractable path for a modern, competitive browser to exist without a megacorp funding it.
Compiling things HTML doesn’t fundamentally change things. It just adds more layers that need to be understood and debugged. Nothing is simplified – it’s complexified. Browsers remain ridiculously expensive to maintain, and Google remains a monoculture. But now there’s an extra layer of goop between what developers write and what shows up on the screen. It also makes the code that gets delivered to the user far more opaque.
I’d take the current situation, bad as it is – but with fewer layers, over adding another layer that needs to be understood, maintained, and debugged through.
I agree with you here. However that complexity has been built up over time, and arguably only a subset of HTML/CSS/JS is actually needed. The rest is due to legacy reasons, and adds a considerable amount of artificial complexity.
Yes, complexity always goes somewhere. But compiling to HTML/CSS/JS does fundamentally change things – it moves that complexity to the developer side rather than the client side. With an abstraction on top of HTML/CSS/JS that outputs only the most modern subset of HTML/CSS/JS the client side of things is simplified. If miraculously everyone started making their websites with this new abstraction, then browsers would only need to support the feature-set that this abstraction uses – not the entire spec (which cuts down on complexity drastically).
Of course there are plenty of issues with this approach – such as any abstraction on top of HTML/CSS/JS is going to be incredibly complicated by itself, or that not enough people will use this abstraction to fundamentally shift the complexity load of browsers.
I think there are many parallels to x86 and Arm. LLVM, despite being another “layer” has made it trivial to build software that runs on both x86 and Arm (and RISC-V), where the newer alternatives are significantly simpler.
In my experience, that’s simply not true. A good design can eliminate a huge amount of complexity – and a huge amount of complexity comes from bolting things on to something that’s not fit for purpose.
Accidental complexity, yes; essential complexity, no.[1] Most of web development as it stands is primarily accidental complexity – I think we can all agree on that. The issue with browsers is that they have to compensate for all of that accidental complexity, which I also think we can agree on.
My argument is that there is a subset of the current web standards that encompasses the essential complexity of the web – the core complexity needed to render and manage an interactive user interface. You’re arguing that people should just use this subset as is – which I agree, would be nice if that was done. However, people are clearly not doing this.
But if there was an abstraction built on top of the current web standards which abstracts away all of this accidental and essential complexity from the developers, we can more easily migrate away from all of the accidental complexity and agree on the essential complexity. Once that is done, then browsers can just implement the subset of the web that have the essential complexity.
Differentiating between essential complexity and accidental complexity is absolutely crucial here, because building a “simple” abstraction on top of essential complexity leaves holes and edge-cases.
[1] https://en.wikipedia.org/wiki/No_Silver_Bullet
Many of the listed problems would be solved by simply disabling JavaScript for “the document web”, block remote resources, etc. No need to reinvent everything. We could optionally go back to XHTML 1.0 (or HTML 4 Strict), use object tags for video/audio and call it a day. As for CSS, we’d need to remove its Turing completeness to avoid it becoming “the next JS”. If any functionality is missing, they can be reintroduced as HTML elements after careful consideration. I do like the HTML5 tags like
<nav>and<aside>which can be be used by screen readers etc. to focus on the content on of the page.We could also keep JS, but put a sleep(0.01) between every JS statement that needs to be executed making it slow on purpose and forcing developers to only write the JS that is really needed to optimize some aspects of the site.
See also this pyramid from this talk.
Why in the world would anyone opt in to that, though?
On my (static) website, you can read almost everything but if you let me load JavaScript, then you get some cute toys I wrote and you get to see Webmentions loaded from webmention.io. I’ve mostly written my website “the right way”, but I’m disincentivized from switching to the “document web” because it breaks a few things for no benefit.
“Well yes, but you’d do it because you want to be disciplined and support a new kind of experience.” If everyone had this kind of discipline, we wouldn’t have this problem in the first place because everyone would write good semantic HTML and bare-minimum JS.
“Sure, but it wouldn’t be opt-in because we’d get all the browsers to enforce these restrictions for the document web, and everyone would be forced to change.” How would you figure out what’s the document web and what’s the application web? In particular, without pages being able to lie about being on the application web?
I’d propose the distinction between “application web” and “document web” is this: if you need JS (at all) it is the “application web”. If a site works without requiring any JS, it is part of the “document web”, even if it has optional JS to tweak some little UI/UX things otherwise not available/possible.
Webmentions can also be used without any JS in the browser, at least back when I implemented support for it. That has the benefit of increasing the performance for your users and does not require them to leak the sites they visit to a (centralized?) service.
It requires a little bit of discipline yes, and not everything is possible. This is something everyone has to decide for themselves obviously. For me figuring all this stuff out is part of the fun! I avoid centralized systems, especially “big tech” or surveillance capitalists, try to protect my users and make it as fast as possible. I want to be part of the decentralized “document web”…
Interesting and thoughtful. Thanks. Some random comments:
It’s not only that. I’ve built a wonderful little blogging engine just using standalone Vue.js. The problem isn’t Vue, it’s “standalone”. People start doing something with documents, like blogging, then they decide they’d like a little “sizzle”, so they want to add something. There’s no natural stopping point for this, though. I was happy using standalone Vue, but most people who pick it up start using it in a pipeline, perhaps with some back-end thrown in. They’ve almost instantly gone from “I’d like something that looks cool” to “Holy cow! I’m an application programmer!”
If you built a simple markdown pipeline, know what would happen? People would be instantly clamoring for new stuff to cram into markdown. It’s what happened with html and it’d happen again for the same reasons. People want their documents to have some cool gadget that distinguishes them (Facebook feed, anyone?), and there’s no natural stopping point between beginning to act on that desire and trying to cram a video game into the browser, which is approximately where we are now.
I like the idea of separating the concepts. I’d almost think you’d want separate protocols, though, and some clear acid test for determining what went in each camp. Otherwise we’d be right back here in another 20 years with the same problems.
Proceeds to propose a web like it was 30 years ago. :facepalm:
Even more so:
and then:
This contradiction is stark!
Markdown isn’t a subset of HTML. I think the point was that if you have something that’s a syntactically compatible subset of HTML, people won’t feel compelled to drop their current web browsers.
It has a subset of the functionality. I don’t think a non-syntactically-compatible subset will compel people any more than a syntactically-compatible subset.
This is my solution to today’s modern web bloat https://mkws.sh/.
My solution is just to not write bloated pages. Periodically I check that pages I care about can render even in ancient browsers (for gits and shiggles I have a Solbourne S3000 with an old version of Netscape Navigator which serves splendidly for this purpose), though for retrocomputing I still think Gopher ticks more boxes.
I am intrigued by this concept.
Markdown is too limited for proper document authoring in my opinion, especially if (as it is appearently suggested by the original article) no CSS is allowed for styling. It is the purpose of a document to convey information, and the presentation should support this goal to the highest extend possible. For instance, with pure markdown you cannot have real figures with labels as Markdown only supports inline images. Trying to properly get that in a Markdown document without resorting to HTML is very difficult. There are other cases than this one, and that’s why I’m against using Markdown for a new, minimal document web, albeit I like the idea of such a document web. Before we make a choice on the markup language to be used, there should be a proper evaluation of what is actually needed for both simple and complex (think e.g. scientific) documents.
I was going to say this as well. Any document system for the ‘new web’ should be robust enough to reproduce hand-typeset 16-century documents, in addition to CSS-styled documents of today. It seems like a very programmer-centric view to say that everyone should be limited to documents that can be comfortably read in an 80x24 monochrome VTT.
but markdown supports embedded html tags… so to “fully” support it means supporting html too! (I really don’t understand why people like markdown) Of course it could be a subset :)
I’d hate to use something like that because of how counterintuitive and surprising Markdown is, not to mention inflexible.
This is, to a first approximation, Gemini (albeit with a different protocol).
Which is mainly due to the fact that the web is rendered on a broad range of devices nowadays. Which is a good thing for web-developers.
Apart from that, I think tooling for web development is better than ever. Frameworks like React allow developers to create frontends that handle complexity on an unprecedented scale. Even CSS improved. There is flexbox, whereas in the past one was forced to use some JavaScript library for a responsive layout.
I would argue (from professional experience) that most frontend developers don’t “handle” complexity at all in React, and further that the goal should be to reduce the complexity.
Good read. I’ve done some research and writing in a similar vein: https://l-o-o-s-e-d.net/public-internet https://l-o-o-s-e-d.net/assets/files/The%20Internet%20of%20Anxiety.pdf I’m of the opinion that there are solutions that lie within the physical layer of the Internet as well as the higher, soft layers.