Forking the Web (opens in new tab)

> The specification must contain a non-ambiguous formal grammar that can be parsed easily. A page can then be tested against the standard and reject or accept as compliant. Pages that don't conform with the specification won't be rendered. It is explicitly forbidden for clients to accept any page that doesn't conform with the specification.

This is what XHTML was, and it was a complete disaster. There's a reason almost nobody serves XHTML with the application/xhtml+xml MIME type, and that reason is that getting a “parser error” (this is what browsers still do! try it!) is always worse than getting a page that 99% works.[0] I strongly believe that rejecting the robustness principle is a fatal mistake for a web-replacement project. The fact that horribly broken old sites can stay online and stay readable is a huge part of the web's value. Without that, it's not really “the web”, spiritually or otherwise.

[0] It's particularly “cool” how they simply do not work in the Internet Archive's Wayback machine. The page can be retrieved, but nobody can read it.

Web browsers turned into application engines because it was a path to get useable software on PCs without having to deal with Microsoft. IE6 stayed broken forever for a reason.

Now, they enable applications to exist without going through app store gateways.

A new document-only protocol aligned the Web's original intention would be very useful simply for security reasons. I liked Gemini because, by design, a Gemini document is not executable in any way; there's no popups, plugins, or even cookies; all this is out of the box without having to manage settings, and Gemini documents are very readable without an app at all.

But replacing the modern browser rather than being another option will actually lock in people further than they already are-open protocols require apps which are all behind a gateway now on the primary computing device of users: phones.

It probably won't matter in a few years as the Web will likely be equally locked down soon, though.

Most "web fork" ideas try to either ditch the web as a sandboxed application distribution platform or to ditch the web as a hypertext-based front-end for networked systems. IMO a good from-first-principles solution wouldn't abandon one or the other but instead split them into discrete components. I suspect this would simplify things a lot vs. the HTML/CSS/JS status quo.

We kinda sorta almost had that for a short period with Flash (and Java, I guess): a webpage either didn't use flash and was secure and efficient like opening a document, or it did use flash and was featureful and interactive like an application. Users and system administrators could block Flash or enable it conditionally while expecting most of the web to continue to work, which in hindsight was actually pretty nice from a security perspective.

Something that I have tried and failed at is building a new simpler protocol just for limited games (harden back to RIP BBS). I keep finding myself going down a layout rabbit hole and getting side tracked. I may return to this if I can commit to just shipping... something.

Hacker News is obviously a very corporate-centred website, so most of the posts in this thread are about profitability and economic value. If that's the lens through which you see things, forking the web seems like a waste of time. It's obviously not profitable.

I don't care about any of that, I just want to have fun on the internet. By that metric, most of the criticisms in this thread are irrelevant. It doesn't need to make money, it doesn't need to be used by more than a few nerds, and it doesn't need a zillion bells and whistles. Whether rdg (the author of the blog post) shares this goal, I don't know.

Developers would rather fork the Web than admit Chrome is the new IE6 and stop targeting it.

History explains why HTML is now a living standard: https://whatwg.org/faq (Ctrl+F Living and keep reading).

> A published version of the standard NEVER, EVER, EVER, EVER changes.

WhatWG does have per-commit snapshots of the standard. They're just not semantically versioned because it is a living standard.

I think what the author wants is something like Gemini instead of HTML, but that has its own set of problems. My plea for Dillo would be to instead just support a text/markdown mime-type natively and we can try for adoption in more browsers.

> The objective is not to create a feature-by-feature clone of the Web, but to create an specification that allows humans to exchange knowledge, notes, and other forms of information without the imposed requirement of having to run a full blown VM to read it.

Markdown in browsers fits your objective! Only gotcha is commonmark extensions, and they can work with sub-type declarations in the mimetype.

I like Dillo, and I like this project.

I have tinkered with Gemini on occasion, and while there are stubborn adherents, it’s not super intuitive to use. Not sure why it can’t be beautiful and simple. Maybe it can’t?

I think a standard like this proposed would make it far easier for browsers for older tech to be developed, used, and maintained. That would be a massive win.

And in addition to security and privacy concerns, the less that a browser actually needs to do, the better for us all.

But it feels like a pipe dream?

> A page can then be tested against the standard and reject or accept as compliant. Pages that don't conform with the specification won't be rendered. It is explicitly forbidden for clients to accept any page that doesn't conform with the specification.

it's as if nothing was learned from the XHTML debacle

I feel like that's not solving any of the problems I think of the Web as having.

You can certainly make something with it, but I can't imagine most people finding a use for it.

This is what you want: https://en.wikipedia.org/wiki/Gemini_(protocol)

So... I think scripting is actually really important -- otherwise not only are you stuck with the lowest common denominator of all browsers, but the browsers need to implement a billion bug-prone views -- that map view link mentioned? Now you need a map viewer!

What you want is to have scripting with capabilities -- preferably on top of WebAssembly (JS is a sin).

The best part is this improves the experience of noscript users -- rather than nice graphical widgets being broken, instead, they can just run scripts without any "network" capability -- which should forbid the scripts not only from accessing the network, but make it so anything they modify becomes "tainted" and is not allowed to show up on a network call (so e.g. if they encode some data in a form, trying to later submit that form somewhere else on the app will give a warning).

Now -- most people don't care and don't want this. And that's a good thing -- capabilities put the power in the hands of the user agent where they belong.

More interestingly-- capabilities can be shimmed! Rather than "you are not allowed to access my GPS", it should be a first-class feature to feed the WASM a GPS stream of your choice.

I’ve been surfing the web for a month with a ‘push to enable JavaScript’ button and it’s going pretty well. Very few sites are worth my time to enable JS for them, and they tend to lose the privilege immediately after I’m done extracting whatever my value is from them. Don’t have to charge my phone as often, so if nothing else that’s a win.

I don’t see how this helps someone who wants to create a website. You don’t have to use JavaScript on your website if you don’t want to and you can use a different format for your text files that translates to HTML. (Markdown is a popular alternative, but you can invent something different.) What’s the upside in requiring your audience to use a different browser than they normally use?

Why not try to define a strict subset of the current specs, that would target ease of implementation & graceful degradation? I'd rather have many different clients compatible with a "web-lite" spec that is enough to navigate on 95% of websites, which would have an incentive to officially support that subset if it becomes popular enough.

> Adding scripting capabilities was a mistake, so we can avoid it now.

> Instead, you can provide a Geo link to open the location in any client that supports the protocol.

Sorry but as someone old enough to remember when the web was mostly non interactive I vastly prefer the current situation despite its many shortcomings. I want to keep a minimal number of softwares on my computer. I don't want to give a hundred "clients" access to my computer when I can just run JavaScript sandboxed in my browser. If someone sends me a link and tells me it's a cool game he found online I will open it in my browser and have a look but I will not just run random binaries on my computer. Oh, and I like being able to access any website just from my browser on my Linux, instead of hoping that there is a Linux client that isn't 5 years out of date or fiddling with wine to figure out why the windows binary wouldn't run.

I understand why people dislike the web sandbox or having to run a full blown VM for everything, but please understand that this is also what makes the web great. You can run everything and fear nothing.

This sentence highlights the reason why these efforts fail despite any original good intentions:

"as soon as a monopolistic entity can build a mechanism to extract revenue from it, there will be an incentive to capture the standard and change it to for their own benefit"

Personally I'd love a simple semantic versioned subset of the web. The required traction and buy-in from existing key players (browser vendors, web hosting platforms etc) makes it largely a non-starter though. I'd love to be wrong though.

Instead of "forking", it may be more prudent to extend or revive something more like Gopher, so you don't constantly get baraged by incompatible sites (like you would in a forked web)

I mostly agree with the article - I believe the differentiation should be between documents and applications.

While HTML serves its purpose, especially for documents, the modern web is a giant mess of that legacy, combined with unfriendly ergonomics and glue/hacks built on top just so we as developers can have better DX for creating complex software on top of it.

Building a browser means having to deal with all that legacy, wether we like it or not, so most of the browser market got captured by the big players who have enough manpower to cover all those edge cases. That also means we have to deal with whatever technical choices or bloat they make, causing an infinite stream of issues, from memory usage, to size, to limitations that don't make sense in 2026 but are still there because someone 20 years ago decided to write them like that. As I deal with mobile webviews a lot in my daily work, I unfortunately had to get familiar with quite many gotcha's and edge cases, and some are just... absurd in this day and age.

I believe we need a separation between an application layer and the document layer, and especially between the UI language and the actual application code - script tags serve their purpose, but again, they are a hacky solution with its own bag of tricks, and those tricks impact all of the software built upon it.

Now, a bit of a shameless plug I've been working on something to fill that gap, at least for myself and hopefully for others who encounter the same issue - it's called Hypen (https://hypen.space) and it's a DSL for building apps that work natively on all platforms, with strict separation of code/UI/state, and support for as many languages and platforms as I can maintain, not "just javascript". While currently it's focused on streaming UI, it's built with Rust and WASM at it's core and will soon allow fully "compileable" apps.

While it may not be the future of software, once you get into building something like that, it becomes obvious that the way we are building now is at least wrong, and at best kafkaesque.

I have been thinking about this problem for a couple of years so far. but I also needed a Censorship free with built-in authentication and authorization. And I ended up creating a protocol called Mau that hasn't been implemented or used yet, so it's been waiting around here. Check it out if you think it can help https://mau.social/

> One of the problems with the Web is that as soon as a monopolistic entity can build a mechanism to extract revenue from it, there will be an incentive to capture the standard and change it to for their own benefit. In the particular case of the Web, this has resulted in a standard that grows out of control in complexity so it increases the barrier of entry for new browsers and reduces the competition.

Maybe I'm just stupid, but I don't really know what the author is talking about here. What parts of the standard? HTTP? HTML? DOM APIs? What?

>Adding scripting capabilities was a mistake, so we can avoid it now

Gemini protocol?

So the concept is a big regression ? what is the point of no scripting ? Having a dozens of specialized programs to simply open a map, a shopping cart, a music player, a video, etc... ?

That sound really like a big bad idea to me.

The purpose should also be defined. It should answer the question why. Also, what's broken with scripting and what alternatives are proposed? What's the end state (with an example usage of the new web).

"Dillo Browser" was not what the first thing I read and wondered if me clicking the link was even a good idea... xD

Can't say I hate the HTML 5 spec. It resolves the ambiguities that made previous HTML specs insufficient to make a working web browser.

The standards that make my life miserable at times are the secondary standards like GDPR and WCAG as well as the de facto "standard" systems we are forced to participate in such as Cloudflare, the advertising economy, etc.

It's easy to say "WebUSB is bloat" and I'd certainly say PWA is something that could only come out of the mind that brought us Kubernetes, but lately I've been building biosignals applications and what should my choice be: write fragile GUI applications for the desktop that look like they came out of a lab and crash from memory leaks or spend 1/5 the time to make web applications that look like they belong in the cockpit of a Gundam and "just work"?

I am generally interested in approaches to cut down complexities of fundamental web technologies. Creating a browser from scratch shouldn't be impossible or a trillion dollar experiment. But...

> No scripting

How is will it be possible to go back? The average ecom presence usually relies heavily on JS. I haven't checked in a long time that any relevant sites work without JS. I think going back to more basic approaches could even improve user experience, as many usage patterns probably would converge and simply look and function as intended. But considering that the whole web world is so fixated to solve everything with JS seems like targeting the highest resistance target you can find. Don't get me wrong, I hate this situation and we must not have a single language that dominates everything.

I also don't believe is that enthusiasts will create a significant shift. They can surely provide the fundamentals, but if there isn't a huge mainstream impact, it will not change anything.

Just use HTML and CSS, ignore javascript.

Isn’t the web forked enough already

Isn't there already smolweb?

At this point we need a fork of not just the web but the entire internet, one built for privacy.

Dillo. This is a hot take of hot takes. But, I think it's correct. Let me know how I can help?

Good idea, we absolutely should replace the Web, but I have some issues with this proposal:

- We don't want multiple versions (1.1.1, 1.2.1), but we also don't want constant churn (the current dev/product fad). What we want is one thing that works well indefinitely, is backwards compatible, changes infrequently, and can be expanded if necessary. In order to achieve that, we have to abandon the idea of monolithic web browsers.

"The Web" is not a hypertext document viewer, as much as some people (myself, and Dillo probably) would like it to be. It is an application platform. So you must consider the needs of an application platform if you want a "new Web". The browser interfaces with the entire OS + a slew of protocols and libraries. It's Android in userland. It will change as constantly as OSes and tech changes, which is constant. So to get away from churn, we need to break up the application platform into layers. Those layers need to have simple, well-defined backwards-compatible interfaces, with extensions. The model for that has been around for decades; network protocols last 60+ years without needing to be replaced, but add features over time, without getting feature creep, and remain backwards compatible. There aren't a ton of versions of common internet network protocols. And importantly, you don't have to use one implementation, the way people get stuck on one browser.

The standard should follow this extremely well established pattern of layers of independent components which aren't built into a monolith. It can still have a version (initially), but we shouldn't need to change the version, we add feature flags and handshakes, the way network protocols do. The end result should be a combination of a "web POSIX" + "layered protocols/specs".

- "Pages that don't conform with the specification won't be rendered" - this simply is never going to happen. The history of software development is littered with examples of having to work around implementations of specifications. Your client can try to render strictly, but it will inevitably break on someone's implementation, and you will be forced to deal with it, or lose your customers/users.

"Having a strict grammar will likely cause humans to migrate to a language that is easy to write and is more forgiving ... The objective is that parsers can be simplified and the cost of creating tools that can manipulate the content is lowered" - This sounds like you're saying, programming is hard, so let's make the user have to work around our inability to solve hard problems. Easy is not always better.

-

"Resistance to standard capture"* - I think this goes back to the layers. Remember you are building an entire Application Platform. Think about Linux and Open Source. How does it resist capture? Independent organizations and authors, loose associations, cobbled together components. There is nobody in control, so you can't capture it. This is actually the same with network protocols (other than HTTP, we all know Google controls the spec). We can take ideas from many places. As just one random example: MCP is a simple yet powerful way for independent entities to add functionality to an application both locally and remotely, yet is independent of both the client and the server. Another example is Plan9, where you can support anything in the world and use it as a file (both locally and remotely), as long as you make and run the driver for it.

- "Text first" - You just lost the room. If you want text only, stick to Gopher. An application platform requires multimedia. You would do well to craft the spec so that it can convert application presentation into a text structure. Sell it as accessibility.

- "No scripting" - Now your proposal is dead. Again, Application Platform!! People want a way to cheaply deliver and run application code in real time. I think this needs a lot of careful attention, because you don't want to continue the status quo of requiring a single monolith to interpret and execute logic for the entire application platform.

Seems like somebody is not accepting that every successful project will grow and become unwieldy like this. This is all legacy backwards compatibility of all iterated ideas that now you have to support.

"No scripting" is essentially setting the watcwatch back ~30 years to Mosaic.

It would be great to differentiate between "static" and "dynamic" pages based upon scripting, IMO.

I support forking the web, into the simple information web services that the web started with. This is a magnificent idea.

Ah yes, another "If I Were King" blog post. For an example of how it will turn out, look at how many JavaScript frameworks have been built to replace an overly complicated, unwieldy previous one.

oh and also https://xkcd.com/927/