9 ms·

Forking the Web

145 points by wrxd 5mo ago

thealistra 5mo ago
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.
jfengel 5mo ago
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.
- smugglerFlynn 5mo ago
  I think original web standards were solving a completely different problem: sharing information. Modern Internet is 45% appearances and 50% search traffic optimizations. For better or worse we lost all usable registries of websites, we lost appearance-less and traffic considerations-less websites. Information-focused Web is pretty much dead. Maybe these ideas did not scale and did not monetize that well, but we will never really know what information-focused version of Internet would have looked like because evolution took it elsewhere. Unless we try building another one with different principles and limitations at the core.
  - TFNA 5mo ago
    I agree. Even where blogging and sharing information is still around, it is strongly linked with brand-building, monetization, and engagement-maxxing. Look at all the old Wordpress bloggers who switch to Substack in order to have some eyeballs on their posts, and then inevitably begin conforming to its ethos willingly or unwillingly. For me, the information-sharing part of the internet now is the shadow libraries. I can get access to all (well, still not quite all) journals and university-press publications from the last century? Awesome. Vastly more informative than some blogger who nowadays is probably trying to monetize my attention.
    - smugglerFlynn 5mo ago
      It is the same with forums, trackers and private libraries. They are instantly more useful for information seeking purposes. And none of this really fits into attention-monetizing economy of Internet. I’ve recently counted movies available on my HBO account and it is in low hundreds. There is absolutely no way to find a specific movie across existing services - information discovery is broken, and their subscription models force me to pay in weird ways (subscribe, watch, unsubscribe.. rental is scarce) for a relatively simple outcome. Another weird example are books that are widely available on the web in pdf and other formats with absolutely no way to legally purchase them in electronic form. There is a vast untapped shadow network of people doing [often volunteer] work of publishers: scanning, uploading and categorizing content in a searchable way. At the same time most publishers who actually own rights to this content are prioritizing entertainment and attention focused platforms, where 20% of invested work already gives them 80% of business results. One can argue that this is (a) the only economically viable model we could come up with and (b) most people that are looking for entertainment don’t really have this problem.
  - jfengel 5mo ago
    The current web supports flat information delivery, and it's there if you want it. Wikipedia can be presented in pure text. If you write a story or an essay you can post it in many places, including your own web site. Perhaps what's needed is for an alternative search engine. Assert that you will only index a site that meets some strict set of limits. If that's what people want they will use that engine. If it's popular sites will have have to find ways to get listed, e.g. "simple.amazon.com" which supports that standard.
    - MrVandemar 5mo ago
      Marginalia is almost already this. It flags sites that have advertising, javascript, etc. meaning that you can easily avoid those.
    - smugglerFlynn 5mo ago
      You are proposing to fix something that is not broken by adding things to it. My point is, the Internet has already evolved in this specific way for a reason. Few old school sites like Wikipedia aside, modern Internet is serving a very different purpose: being an entertainment platform, being a backbone for building applications and monetizing them. Yes, technically there are still underlying networks with instant delivery of content to any place on Earth, but maintaining something like Wikipedia on top of modern Internet is like trying to maintain a quiet library inside of a Casino. Monetization means don’t fit. You need a quiet space to read and study, not dingling sounds and bright lights, not free vodka and 50 security guys. We need a new paradigm of information sharing and new ecosystem if we want to do things differently.
      - deleted 5mo ago
        [deleted]
- ravenstine 5mo ago
  The only sort of problem this might solve is the insanely low barrier of entry that the Web has in 2026. The Web was arguably a better (albeit imperfect) place when it was dominated by geeks and kids who could learn to use it faster than their elders. It was a club in a sense. Today it's a club where everyone on the planet is invited, meaning it's no longer a club. I know that sounds great to a lot of people, but I don't agree that systems become better with more participation and fewer criteria for that participation. Even so, those who want to share and access information can already do that via the Web. Nobody has to use scripting. Nobody has to use The Google as their search. Nobody has to rely on an LLM. If there is demand for simple webpages that are free of scripting, they can be built and shared today. Because of this, the proposal comes off as very out of touch and deep within the HN bubble. Strict grammar for declaring documents is merely a fetish. If there's no scripting, then there's no reason for a document to break for some silly reason.
roschdal 5mo ago
I support forking the web, into the simple information web services that the web started with. This is a magnificent idea.
OutOfHere 5mo ago
At this point we need a fork of not just the web but the entire internet, one built for privacy.
htmlenjoyye 5mo ago
> 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
- paxcoder 5mo ago
  [dead]
- vanviegen 5mo ago
  I think XHTML failed because it didn't give web devs any new capabilities, so most didn't feel the need to learn it and do the extra work of getting their tags correct. Then html5 came along, providing all kinds of shiny goodies and saying not to bother with the tags. In the end, a more rigid standard would have been nice.. (Though this is mostly about the skin deep part of the standards.)
  - andsoitis 5mo ago
    > I think XHTML failed because it didn't give web devs any new capabilities, and what new capabilities does this new proposal provide?
    - vanviegen 5mo ago
      None, as far as I can tell.
  - tclancy 5mo ago
    That is not how I remember it (for a data point of one shop in New England during the time): we embraced it because of the binary validation under multiple theories. There was a strong suggestion valid html did better from an SEO perspective, so we could sell that, a suggestion browsers would be less buggy with properly formed xhtml and a number of theories about what the future held for bots and scrapers to be able to easily ingest and parse your content (seen as a good thing then). It failed because the smallest error by a client after the fact was like a server crash. Plus it would have created a mild barrier to entry when learning html at all.
internet2000 5mo ago
Developers would rather fork the Web than admit Chrome is the new IE6 and stop targeting it.
- fooqux 5mo ago
  I think at least part of the reason for this is acknowledging that the web isn't much of a web any longer. You've got three or four vendors that serve the vast majority of all internet traffic. And it's not happenstance that those same vendors now control something which was originally meant to be democratic. Most of this document reads to me like that's the problem they're trying to solve, not just chrome's huge marketshare, so simply not targeting it doesn't serve their purpose.
  - htmlenjoyye 5mo ago
    how is the web not democratic? in real democracies the populists (facebook, tiktok, chrome) always win. because that's what the masses want
    - Ieghaehia9 5mo ago
      > in real democracies the populists (facebook, tiktok, chrome) always win. because that's what the masses want Is Friedrich Merz a populist? Was Angela Merkel a populist? This theory seems to have considerable limits.
      - jancsika 5mo ago
        All I can say is if OP's name were "xhtmlenjoyye" they'd respond like so: The context is real democracies, not messy extant nation-state governments. Please delete your comment so no one can read it.
    - 2ndorderthought 5mo ago
      Whoever has the most compute controls the narrative. It's AIs biggest contribution to the internet.
TazeTSchnitzel 5mo ago
> 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.
- TFNA 5mo ago
  XHTML failed in an era when writers (even normies) were writing some HTML of their own and they could't be trusted to close their tags properly. XHTML also assumed writers would be personally invested in semantic markup like distinguishing e.g. the italics of book titles from the italics of emphasis. Today, when writers are using visual editors (or Markdown), few are writing their own HTML any more. A web standard requiring compliance would work differently today.
  - PaulHoule 5mo ago
    Markdown sux and so do visual editors. I think visual editors were just invented to make it so cut-and-paste never quite works right. There's been some conceptual problem with the whole idea ever since MS Word and the industry has never dealt with it.
    - cindyllm 5mo ago
      [dead]
    - 5mo ago
rickydroll 5mo ago
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/ https://xkcd.com/927/
- anthk 5mo ago
  Dillo's author (and users) don't give a crap on JS.
Brendinooo 5mo ago
>Adding scripting capabilities was a mistake, so we can avoid it now Gemini protocol?
PaulHoule 5mo ago
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"?
- torgoguys 5mo ago
  >I'd certainly say PWA is something that could only come out of the mind that brought us Kubernetes How so? PWAs are awesome! Democratizing for users. Democratizing for developers. They work well for the right class of apps. They would go much further if there weren't forces actively resisting them. Think of all the electron type-apps out there. Now imagine if the average Joe could just install them from the web with 2 clicks. (Regular ole bookmarks get you a decent percent of the way but clearly something extra than that was needed.)
  - doublerabbit 5mo ago
    PWAs are it. They would go well with a PDAs but the existing frameworks are terrible. Next, React powering the future internet, don't make me laugh.
hypendev 5mo ago
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 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.
- llbbdd 5mo ago
  All documents eventually become applications if they're useful enough. For anything that doesn't match that description, we have PDF.
captn3m0 5mo ago
History explains why HTML is now a living standard: https://whatwg.org/faq 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.
- tadfisher 5mo ago
  We should start from a single, sane specification. That is not a descriptor for the Markdown ecosystem.
  - krapp 5mo ago
    So just specify a single, sane specification of Markdown as the spec.
- rodarima 5mo ago
  > I think what the author wants is something like Gemini instead of HTML, but that has its own set of problems. Yes and no. I want it to be simpler than HTML (which implies less features) but easy to parse. The problem with Markdown and other "text-like" formats is that they are designed to be written by humans (which is good) but complicates the parsing. I guess is more similar to the device independent format used by groff/troff before layouting. >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. Dillo only supports a subset of HTML. Other formats like markdown are converted to HTML with plugins or read as plain text.
deanebarker 5mo ago
This is what you want: https://en.wikipedia.org/wiki/Gemini_(protocol) https://en.wikipedia.org/wiki/Gemini_(protocol)
- MrVandemar 5mo ago
  Gemini is cool for many reasons, but it fails in being able to encode complex documents, or use semantically or visually useful structures common to many documents. There is: - No metadata. - No emphasis. - No citations. - No way to mark up nouns like a person, or a company. - No way to present documents with a complex heading hierarchy past level 3 (for those who argue that more is not necessary, please consider that headings are basically cognitive sub-directories. Do you want to work on a file system that only lets you go two levels below "/"?). I'd personally favour (but not advocate for) something like a super-lightweight Docbook grammar which is standardised, and already has great tooling available for it.
  - krapp 5mo ago
    It succeeds in being so simple that it's useless to 99% of people, which limits its growth and eventual co-opting by capitalism and mainstream culture, and Eternal September. Not everything has to be for everyone. Gemini is only for a very specific kind of deeply aescetic technological misanthrope that wants basic plaintext with links (basically Gopher++) and finds little else to be useful.
Yokohiii 5mo ago
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.
- doublerabbit 5mo ago
  JavaScript isn't inheritedly bad. It's won that reputation because of bloat. No one codes standard vanilla any more so it's always a framework and the existing are failures. It's shocking how 2mb of JavaScript could be done in 2kb and that JavaScript was never designed to conceive.
  - Yokohiii 5mo ago
    It's interesting that you say that JS isn't inherently bad, but everyone uses TS. Is there something bad about vanilla? Either way, my problem isn't generally JS as is, but that it is the only language, the only platform that drives everything. Maybe web assembly can change that, it's not really a fast progress. But that is kind of the problem, replacing JS or introducing alternatives is extremely hard.
    - krapp 5mo ago
      There's nothing bad about vanilla. People use TS because that's what startups and businesses prefer, and CS students expect compilers and toolchains and strict typing. Modern JS culture is entirely influenced by Silicon Valley and its hiring principles.
wuhhh 5mo ago
Isn’t the web forked enough already
sylvinus 5mo ago
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.
drzaiusx11 5mo ago
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)
aboardRat4 5mo ago
Isn't there already smolweb?
RiverCrochet 5mo ago
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.
- Rohansi 5mo ago
  > Web browsers turned into application engines because it was a path to get useable software on PCs without having to deal with Microsoft. [...] Now, they enable applications to exist without going through app store gateways. What? You could deploy software without dealing with Microsoft back then and you still can today. Unless you meant avoiding building for Windows natively.
- anthk 5mo ago
  >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. Nonsense, lots of software were just local, I've even see MSN clones written in TCL/Tk, and Lazarus still used in some places, and tons of VB6/C# software. Back in the day except for Intranet turds (which in the end causes disasters like Iloveyou.VBS "thanks" to IE/Outlook deeply tied to Windows 9x software ) everyone serious about programming security and correctness flew away from the web model for the good. It was everything about Java (and applets) and later C#. The web had an overgrowth and languages which shouldn't be part of the desktop.
zkmon 5mo ago
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).
deleted 5mo ago
[deleted]
Izmaki 5mo ago
"Dillo Browser" was not what the first thing I read and wondered if me clicking the link was even a good idea... xD
- iamnothere 5mo ago
  Why? Dillo has been around forever, as long as w3m I think. Edit: actually it looks like w3m was ‘95 and Dillo was ‘99.
  - andsoitis 5mo ago
    dillo is close to dildo
    - iamnothere 5mo ago
      From HN TOS: > If you are under 13 years of age, you are not authorized to register to use the Site. (By the way, are you aware that the largest bakery company in the US is named “Bimbo”? Tee hee! You should tell them to change their name!)
      - Izmaki 5mo ago
        My moustache filter says I'm above 13, thankyouverymuch.
smitty1e 5mo ago
"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.
ravenstine 5mo ago
> 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?
tekne 5mo ago
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.
- 256_ 5mo ago
  > 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! In the browser? The map viewer could just be a separate programme entirely, like a PDF viewer, etc. I remember watching rdg (the current main Dillo developer) demonstrating this with a separate map programme. Most of your post seems to assume this "everything must be in the browser" approach, which is actively not what Dillo is about. (I would know, I use Dillo regularly.) It adheres to the Unix philosophy. EDIT: Looking at it closely, did I just respond to an LLM post?
  - tekne 5mo ago
    Nope -- those are artisanal, hand-written tokens. I suppose a slopatron could have said that just as well though. I agree with the UNIX philosophy bit, mind you -- modern browsers don't do that and that is bad. But you should be able to download new components from the Internet without trusting them -- a separate install step is not only tedious, it also might cause you to add new trusted software to your computer. Going back to the map example -- you want your environment to be able to auto-download the map painter and paint you the map without needing either to manually do that or to trust the map painter.
butz 5mo ago
Just use HTML and CSS, ignore javascript.
- doublerabbit 5mo ago
  There are technical limitations. What I want to do is now requiring JavaScript. I dislike JS, but I have maxed the ability's of the HTTP POST method.
2ndorderthought 5mo ago
Dillo. This is a hot take of hot takes. But, I think it's correct. Let me know how I can help?
0xbadcafebee 5mo ago
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.
skybrian 5mo ago
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?
deleted 5mo ago
[deleted]
blazeeboy 5mo ago
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/ https://mau.social/
pibaker 5mo ago
> 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.
- zarzavat 5mo ago
  I completely agree. The situation before the "Web Platform" was the "Windows Platform" where you had to give money to Microsoft to use a computer because few developers wanted to make cross-platform software, and almost nobody wanted to make good cross-platform software. As Mac user it was miserable.
- 256_ 5mo ago
  You've misunderstood. The blog post is not talking about running random binaries. It's talking about opening links and files using different programmes, like PDF viewers, video players, etc. There's a video of a talk that the developer gave, which I can't find the link to at the moment, where he demonstrates running a map programme (already installed on the machine, not just fetched from a random website) to open a link with lat/lon coordinates with an interactive map. In general, Dillo follows the Unix philosophy. You use separate programmes to handle things that Dillo can't itself, like watching videos.
  - htmlenjoyye 5mo ago
    no, parent understood correctly. i use 50 different interactive web apps, i do not want to install 50 different apps most of them do not have a "protocol" - ehat is the desktop equivalent of ExcaliDraw
256_ 5mo ago
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.
- rodarima 5mo ago
  Yeah, I avoided sharing it here because I could see that it would immediately backlash. I also didn't even consider adding a more elaborate "introduction" section because these are my quick notes on what it had in mind at that moment. Being on the development of Dillo for a few years makes you see things from a different perspective. I also think that it should be fun to make your own tools from scratch and be able to understand the specs in a couple of weekends. Pretty much what happened with Gemini and the explosion of clients and servers: https://geminiprotocol.net/software/ https://geminiprotocol.net/software/
altairprime 5mo ago
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.
system7rocks 5mo ago
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?
Tomokisan 5mo ago
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.
wasmperson 5mo ago
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.
mathgladiator 5mo ago
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.
AlienRobot 5mo ago
I'm going to be honest. Wanting to create a whole new web from a website that feels less styled than those from the 90's doesn't give a lot of confidence. What if the new web doesn't have a way to add navbars to webpages because this blog didn't have one so the author didn't see the point? Or numerous similar issues? If you want to exchange .txt files you can do that already with FTP.
Panzerschrek 5mo ago
> Reusing HTML if possible It's a bad idea. HTML isn't a great format for transmission and parsing. Some binary (non-human-readable) format should be used instead. > No scripting That's a good idea. Web should consist of static documents (or ducuments generated on server side), not client-side applications with arbitrary code execution.
- krapp 5mo ago
  One of the unqualified good aspects of the web is that its text based format made it simple for anyone to view source to learn how the structure of webpages worked, so they could apply that knowledge themselves to their own websites. It also made it possible to build websites using only a text editor. Text-based formats are also easier to edit or script in a browser. Binary formats may be easier to parse but ethically they go against everything the web (or a web alternative) should be about. And even though HN is heavily anti-JS, especially in threads like these, I'll be the contrarian and say that being able to run code on the web (or an alternative web) is absolutely critical to maintaining software freedom because it allows anyone to easily create, distribute, edit and run software. The problem with the web itself isn't that you can run code in the browser, it's that (until recently) the only code you could run was Javascript, and HTML and CSS are terrible substitutes for native UI. Now you can bootstrap and run just about any software in the browser. Software and game preservation become more vital when you can actually run old software without needing old hardware. A web alternative needs to be designed to maximize freedom for the end user, not convenience for the programmer.
Fizz43 5mo ago
>No scripting Dead on arrival.
1vuio0pswjnm7 5mo ago
"No scripting Adding scripting capabilities was a mistake, so we can avoid it now." This would spell disaster for so-called "tech" companies. Data collection, surveillance and advertising services would become infeasible Also most "browser exploits" would not work And what about "web developers" Doubtful that the "tech company" and "cybersecurity" owners and employees and "web developers" would call Javascript a "mistake" Their "careers" depend on it
- deleted 5mo ago
  [deleted]
x-complexity 5mo ago
Whenever someone talks about forking/rebuilding the web, I'll always link to my favorite Dylan Beattie talk about such a hypothetical alternative: https://www.youtube.com/watch?v=8JOD1AQGqEg https://www.youtube.com/watch?v=8JOD1AQGqEg

145 points by wrxd 5mo ago

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.

jfengel 5mo ago

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.

smugglerFlynn 5mo ago
I think original web standards were solving a completely different problem: sharing information. Modern Internet is 45% appearances and 50% search traffic optimizations. For better or worse we lost all usable registries of websites, we lost appearance-less and traffic considerations-less websites. Information-focused Web is pretty much dead. Maybe these ideas did not scale and did not monetize that well, but we will never really know what information-focused version of Internet would have looked like because evolution took it elsewhere. Unless we try building another one with different principles and limitations at the core.
- TFNA 5mo ago
  I agree. Even where blogging and sharing information is still around, it is strongly linked with brand-building, monetization, and engagement-maxxing. Look at all the old Wordpress bloggers who switch to Substack in order to have some eyeballs on their posts, and then inevitably begin conforming to its ethos willingly or unwillingly. For me, the information-sharing part of the internet now is the shadow libraries. I can get access to all (well, still not quite all) journals and university-press publications from the last century? Awesome. Vastly more informative than some blogger who nowadays is probably trying to monetize my attention.
  - smugglerFlynn 5mo ago
    It is the same with forums, trackers and private libraries. They are instantly more useful for information seeking purposes. And none of this really fits into attention-monetizing economy of Internet. I’ve recently counted movies available on my HBO account and it is in low hundreds. There is absolutely no way to find a specific movie across existing services - information discovery is broken, and their subscription models force me to pay in weird ways (subscribe, watch, unsubscribe.. rental is scarce) for a relatively simple outcome. Another weird example are books that are widely available on the web in pdf and other formats with absolutely no way to legally purchase them in electronic form. There is a vast untapped shadow network of people doing [often volunteer] work of publishers: scanning, uploading and categorizing content in a searchable way. At the same time most publishers who actually own rights to this content are prioritizing entertainment and attention focused platforms, where 20% of invested work already gives them 80% of business results. One can argue that this is (a) the only economically viable model we could come up with and (b) most people that are looking for entertainment don’t really have this problem.
- jfengel 5mo ago
  The current web supports flat information delivery, and it's there if you want it. Wikipedia can be presented in pure text. If you write a story or an essay you can post it in many places, including your own web site. Perhaps what's needed is for an alternative search engine. Assert that you will only index a site that meets some strict set of limits. If that's what people want they will use that engine. If it's popular sites will have have to find ways to get listed, e.g. "simple.amazon.com" which supports that standard.
  - MrVandemar 5mo ago
    Marginalia is almost already this. It flags sites that have advertising, javascript, etc. meaning that you can easily avoid those.
  - smugglerFlynn 5mo ago
    You are proposing to fix something that is not broken by adding things to it. My point is, the Internet has already evolved in this specific way for a reason. Few old school sites like Wikipedia aside, modern Internet is serving a very different purpose: being an entertainment platform, being a backbone for building applications and monetizing them. Yes, technically there are still underlying networks with instant delivery of content to any place on Earth, but maintaining something like Wikipedia on top of modern Internet is like trying to maintain a quiet library inside of a Casino. Monetization means don’t fit. You need a quiet space to read and study, not dingling sounds and bright lights, not free vodka and 50 security guys. We need a new paradigm of information sharing and new ecosystem if we want to do things differently.
    - deleted 5mo ago
      [deleted]
ravenstine 5mo ago
The only sort of problem this might solve is the insanely low barrier of entry that the Web has in 2026. The Web was arguably a better (albeit imperfect) place when it was dominated by geeks and kids who could learn to use it faster than their elders. It was a club in a sense. Today it's a club where everyone on the planet is invited, meaning it's no longer a club. I know that sounds great to a lot of people, but I don't agree that systems become better with more participation and fewer criteria for that participation. Even so, those who want to share and access information can already do that via the Web. Nobody has to use scripting. Nobody has to use The Google as their search. Nobody has to rely on an LLM. If there is demand for simple webpages that are free of scripting, they can be built and shared today. Because of this, the proposal comes off as very out of touch and deep within the HN bubble. Strict grammar for declaring documents is merely a fetish. If there's no scripting, then there's no reason for a document to break for some silly reason.

roschdal 5mo ago

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

OutOfHere 5mo ago

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

htmlenjoyye 5mo ago

> 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

paxcoder 5mo ago
[dead]
vanviegen 5mo ago
I think XHTML failed because it didn't give web devs any new capabilities, so most didn't feel the need to learn it and do the extra work of getting their tags correct. Then html5 came along, providing all kinds of shiny goodies and saying not to bother with the tags. In the end, a more rigid standard would have been nice.. (Though this is mostly about the skin deep part of the standards.)
- andsoitis 5mo ago
  > I think XHTML failed because it didn't give web devs any new capabilities, and what new capabilities does this new proposal provide?
  - vanviegen 5mo ago
    None, as far as I can tell.
- tclancy 5mo ago
  That is not how I remember it (for a data point of one shop in New England during the time): we embraced it because of the binary validation under multiple theories. There was a strong suggestion valid html did better from an SEO perspective, so we could sell that, a suggestion browsers would be less buggy with properly formed xhtml and a number of theories about what the future held for bots and scrapers to be able to easily ingest and parse your content (seen as a good thing then). It failed because the smallest error by a client after the fact was like a server crash. Plus it would have created a mild barrier to entry when learning html at all.

internet2000 5mo ago

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

fooqux 5mo ago
I think at least part of the reason for this is acknowledging that the web isn't much of a web any longer. You've got three or four vendors that serve the vast majority of all internet traffic. And it's not happenstance that those same vendors now control something which was originally meant to be democratic. Most of this document reads to me like that's the problem they're trying to solve, not just chrome's huge marketshare, so simply not targeting it doesn't serve their purpose.
- htmlenjoyye 5mo ago
  how is the web not democratic? in real democracies the populists (facebook, tiktok, chrome) always win. because that's what the masses want
  - Ieghaehia9 5mo ago
    > in real democracies the populists (facebook, tiktok, chrome) always win. because that's what the masses want Is Friedrich Merz a populist? Was Angela Merkel a populist? This theory seems to have considerable limits.
    - jancsika 5mo ago
      All I can say is if OP's name were "xhtmlenjoyye" they'd respond like so: The context is real democracies, not messy extant nation-state governments. Please delete your comment so no one can read it.
  - 2ndorderthought 5mo ago
    Whoever has the most compute controls the narrative. It's AIs biggest contribution to the internet.

TazeTSchnitzel 5mo ago

> 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.

TFNA 5mo ago
XHTML failed in an era when writers (even normies) were writing some HTML of their own and they could't be trusted to close their tags properly. XHTML also assumed writers would be personally invested in semantic markup like distinguishing e.g. the italics of book titles from the italics of emphasis. Today, when writers are using visual editors (or Markdown), few are writing their own HTML any more. A web standard requiring compliance would work differently today.
- PaulHoule 5mo ago
  Markdown sux and so do visual editors. I think visual editors were just invented to make it so cut-and-paste never quite works right. There's been some conceptual problem with the whole idea ever since MS Word and the industry has never dealt with it.
  - cindyllm 5mo ago
    [dead]
  - 5mo ago

rickydroll 5mo ago

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/ https://xkcd.com/927/

anthk 5mo ago
Dillo's author (and users) don't give a crap on JS.

Brendinooo 5mo ago

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

PaulHoule 5mo ago

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"?

torgoguys 5mo ago
>I'd certainly say PWA is something that could only come out of the mind that brought us Kubernetes How so? PWAs are awesome! Democratizing for users. Democratizing for developers. They work well for the right class of apps. They would go much further if there weren't forces actively resisting them. Think of all the electron type-apps out there. Now imagine if the average Joe could just install them from the web with 2 clicks. (Regular ole bookmarks get you a decent percent of the way but clearly something extra than that was needed.)
- doublerabbit 5mo ago
  PWAs are it. They would go well with a PDAs but the existing frameworks are terrible. Next, React powering the future internet, don't make me laugh.

hypendev 5mo ago

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 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.

llbbdd 5mo ago
All documents eventually become applications if they're useful enough. For anything that doesn't match that description, we have PDF.

captn3m0 5mo ago

History explains why HTML is now a living standard: https://whatwg.org/faq 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.

tadfisher 5mo ago
We should start from a single, sane specification. That is not a descriptor for the Markdown ecosystem.
- krapp 5mo ago
  So just specify a single, sane specification of Markdown as the spec.
rodarima 5mo ago
> I think what the author wants is something like Gemini instead of HTML, but that has its own set of problems. Yes and no. I want it to be simpler than HTML (which implies less features) but easy to parse. The problem with Markdown and other "text-like" formats is that they are designed to be written by humans (which is good) but complicates the parsing. I guess is more similar to the device independent format used by groff/troff before layouting. >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. Dillo only supports a subset of HTML. Other formats like markdown are converted to HTML with plugins or read as plain text.

deanebarker 5mo ago

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

MrVandemar 5mo ago
Gemini is cool for many reasons, but it fails in being able to encode complex documents, or use semantically or visually useful structures common to many documents. There is: - No metadata. - No emphasis. - No citations. - No way to mark up nouns like a person, or a company. - No way to present documents with a complex heading hierarchy past level 3 (for those who argue that more is not necessary, please consider that headings are basically cognitive sub-directories. Do you want to work on a file system that only lets you go two levels below "/"?). I'd personally favour (but not advocate for) something like a super-lightweight Docbook grammar which is standardised, and already has great tooling available for it.
- krapp 5mo ago
  It succeeds in being so simple that it's useless to 99% of people, which limits its growth and eventual co-opting by capitalism and mainstream culture, and Eternal September. Not everything has to be for everyone. Gemini is only for a very specific kind of deeply aescetic technological misanthrope that wants basic plaintext with links (basically Gopher++) and finds little else to be useful.

Yokohiii 5mo ago

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.

doublerabbit 5mo ago
JavaScript isn't inheritedly bad. It's won that reputation because of bloat. No one codes standard vanilla any more so it's always a framework and the existing are failures. It's shocking how 2mb of JavaScript could be done in 2kb and that JavaScript was never designed to conceive.
- Yokohiii 5mo ago
  It's interesting that you say that JS isn't inherently bad, but everyone uses TS. Is there something bad about vanilla? Either way, my problem isn't generally JS as is, but that it is the only language, the only platform that drives everything. Maybe web assembly can change that, it's not really a fast progress. But that is kind of the problem, replacing JS or introducing alternatives is extremely hard.
  - krapp 5mo ago
    There's nothing bad about vanilla. People use TS because that's what startups and businesses prefer, and CS students expect compilers and toolchains and strict typing. Modern JS culture is entirely influenced by Silicon Valley and its hiring principles.

wuhhh 5mo ago

Isn’t the web forked enough already

sylvinus 5mo ago

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.

drzaiusx11 5mo ago

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)

aboardRat4 5mo ago

Isn't there already smolweb?

RiverCrochet 5mo ago

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.

Rohansi 5mo ago
> Web browsers turned into application engines because it was a path to get useable software on PCs without having to deal with Microsoft. [...] Now, they enable applications to exist without going through app store gateways. What? You could deploy software without dealing with Microsoft back then and you still can today. Unless you meant avoiding building for Windows natively.
anthk 5mo ago
>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. Nonsense, lots of software were just local, I've even see MSN clones written in TCL/Tk, and Lazarus still used in some places, and tons of VB6/C# software. Back in the day except for Intranet turds (which in the end causes disasters like Iloveyou.VBS "thanks" to IE/Outlook deeply tied to Windows 9x software ) everyone serious about programming security and correctness flew away from the web model for the good. It was everything about Java (and applets) and later C#. The web had an overgrowth and languages which shouldn't be part of the desktop.

zkmon 5mo ago

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).

deleted 5mo ago

[deleted]

Izmaki 5mo ago

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

iamnothere 5mo ago
Why? Dillo has been around forever, as long as w3m I think. Edit: actually it looks like w3m was ‘95 and Dillo was ‘99.
- andsoitis 5mo ago
  dillo is close to dildo
  - iamnothere 5mo ago
    From HN TOS: > If you are under 13 years of age, you are not authorized to register to use the Site. (By the way, are you aware that the largest bakery company in the US is named “Bimbo”? Tee hee! You should tell them to change their name!)
    - Izmaki 5mo ago
      My moustache filter says I'm above 13, thankyouverymuch.

smitty1e 5mo ago

"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.

ravenstine 5mo ago

> 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?

tekne 5mo ago

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.

256_ 5mo ago
> 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! In the browser? The map viewer could just be a separate programme entirely, like a PDF viewer, etc. I remember watching rdg (the current main Dillo developer) demonstrating this with a separate map programme. Most of your post seems to assume this "everything must be in the browser" approach, which is actively not what Dillo is about. (I would know, I use Dillo regularly.) It adheres to the Unix philosophy. EDIT: Looking at it closely, did I just respond to an LLM post?
- tekne 5mo ago
  Nope -- those are artisanal, hand-written tokens. I suppose a slopatron could have said that just as well though. I agree with the UNIX philosophy bit, mind you -- modern browsers don't do that and that is bad. But you should be able to download new components from the Internet without trusting them -- a separate install step is not only tedious, it also might cause you to add new trusted software to your computer. Going back to the map example -- you want your environment to be able to auto-download the map painter and paint you the map without needing either to manually do that or to trust the map painter.

butz 5mo ago

Just use HTML and CSS, ignore javascript.

doublerabbit 5mo ago
There are technical limitations. What I want to do is now requiring JavaScript. I dislike JS, but I have maxed the ability's of the HTTP POST method.

2ndorderthought 5mo ago

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

0xbadcafebee 5mo ago

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.

skybrian 5mo ago

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?

deleted 5mo ago

[deleted]

blazeeboy 5mo ago

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/ https://mau.social/

pibaker 5mo ago

> 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.

zarzavat 5mo ago
I completely agree. The situation before the "Web Platform" was the "Windows Platform" where you had to give money to Microsoft to use a computer because few developers wanted to make cross-platform software, and almost nobody wanted to make good cross-platform software. As Mac user it was miserable.
256_ 5mo ago
You've misunderstood. The blog post is not talking about running random binaries. It's talking about opening links and files using different programmes, like PDF viewers, video players, etc. There's a video of a talk that the developer gave, which I can't find the link to at the moment, where he demonstrates running a map programme (already installed on the machine, not just fetched from a random website) to open a link with lat/lon coordinates with an interactive map. In general, Dillo follows the Unix philosophy. You use separate programmes to handle things that Dillo can't itself, like watching videos.
- htmlenjoyye 5mo ago
  no, parent understood correctly. i use 50 different interactive web apps, i do not want to install 50 different apps most of them do not have a "protocol" - ehat is the desktop equivalent of ExcaliDraw

256_ 5mo ago

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.

rodarima 5mo ago
Yeah, I avoided sharing it here because I could see that it would immediately backlash. I also didn't even consider adding a more elaborate "introduction" section because these are my quick notes on what it had in mind at that moment. Being on the development of Dillo for a few years makes you see things from a different perspective. I also think that it should be fun to make your own tools from scratch and be able to understand the specs in a couple of weekends. Pretty much what happened with Gemini and the explosion of clients and servers: https://geminiprotocol.net/software/ https://geminiprotocol.net/software/

altairprime 5mo ago

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.

system7rocks 5mo ago

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?

Tomokisan 5mo ago

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.

wasmperson 5mo ago

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.

mathgladiator 5mo ago

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.

AlienRobot 5mo ago

I'm going to be honest. Wanting to create a whole new web from a website that feels less styled than those from the 90's doesn't give a lot of confidence. What if the new web doesn't have a way to add navbars to webpages because this blog didn't have one so the author didn't see the point? Or numerous similar issues? If you want to exchange .txt files you can do that already with FTP.

Panzerschrek 5mo ago

> Reusing HTML if possible It's a bad idea. HTML isn't a great format for transmission and parsing. Some binary (non-human-readable) format should be used instead. > No scripting That's a good idea. Web should consist of static documents (or ducuments generated on server side), not client-side applications with arbitrary code execution.

krapp 5mo ago
One of the unqualified good aspects of the web is that its text based format made it simple for anyone to view source to learn how the structure of webpages worked, so they could apply that knowledge themselves to their own websites. It also made it possible to build websites using only a text editor. Text-based formats are also easier to edit or script in a browser. Binary formats may be easier to parse but ethically they go against everything the web (or a web alternative) should be about. And even though HN is heavily anti-JS, especially in threads like these, I'll be the contrarian and say that being able to run code on the web (or an alternative web) is absolutely critical to maintaining software freedom because it allows anyone to easily create, distribute, edit and run software. The problem with the web itself isn't that you can run code in the browser, it's that (until recently) the only code you could run was Javascript, and HTML and CSS are terrible substitutes for native UI. Now you can bootstrap and run just about any software in the browser. Software and game preservation become more vital when you can actually run old software without needing old hardware. A web alternative needs to be designed to maximize freedom for the end user, not convenience for the programmer.

Fizz43 5mo ago

>No scripting Dead on arrival.

1vuio0pswjnm7 5mo ago

"No scripting Adding scripting capabilities was a mistake, so we can avoid it now." This would spell disaster for so-called "tech" companies. Data collection, surveillance and advertising services would become infeasible Also most "browser exploits" would not work And what about "web developers" Doubtful that the "tech company" and "cybersecurity" owners and employees and "web developers" would call Javascript a "mistake" Their "careers" depend on it

deleted 5mo ago
[deleted]

x-complexity 5mo ago

Whenever someone talks about forking/rebuilding the web, I'll always link to my favorite Dylan Beattie talk about such a hypothetical alternative: https://www.youtube.com/watch?v=8JOD1AQGqEg https://www.youtube.com/watch?v=8JOD1AQGqEg