I've sort of been thinking about this as well. Personally, I'd like to re-capture the era of personal blogs and niche knowledge discovery of the earlier web I experienced - crossed with something easy to host/publish and not requiring a browser.
I don't really have any coherent picture but I would like to see these ideas I think:
- Anti-commercial/anti-tracking: maybe requiring some sort of open-source license for all published content that makes it harder to commercially exploit the information, ideally this would be by and for the community, especially in light of recent aggressive LLM-training crawling. I would also like to exclude advertisement and tracking.
- Browser-less: The idea would be to do away with the complexity of the modern web (as people say, browsers are basically operating systems), back to more of its hyper-text roots. Simple documents, mostly textual information. I could imagine a mix of basic markdown and some pre-wired complex/interactive views like "forum" or "blog" and so on (differences in how data is loaded, presented, ...) - the idea would be to implement the "app" part in the browser-replacement and not in the web-page itself if that makes sense. This would lead to more uniformity but that might be a good thing. I'm not even sure if/how images would fit in or videos.
- Peer-to-peer?: Hosting should be as simple as hitting a "publish" button on an article. I like the idea of decentralization, so maybe there could be some sort of peer-to-peer federation where users could "host" content that they've read, liked or general content that's part of a certain (sub-) community. This might require some ranking like HN or a similar mechanism to (unfortunately) censor certain content if the community would not believe it to match their values - so not ultimate freedom. P2P would be more about decentralization, and maybe anti-tracking than pure censorship-resistance.
A session might look like opening the "non-browser" app - it would be fast and require very little memory. Then you'd select or type a community/site and you view of all the content with filters and sorts, depending on the community/site's "template" (again, this is not JS/HTML - basically a native form rendered directly if you will). When you feel like it, you click the "create" button, a text-area + preview pops up and you write your post or article in markdown. When happy, you "publish" and it gets slowly disseminated through all the P2P nodes of your community. This could encompass communities like HN or reddit even if the voting mechanics are worked out, personal blogs, ... but would probably exclude e-commerce stores or video sites because the engine would be potentially too simplistic - and that's fine by me.
Modern smartphones could implement more Data Saver features, but websites could opt-in by using less data. For example, https://marcusb.org/hacks/tinyblog.html
I've been thinking more lately about how to get "Basic Web" - just like normal HTML and maybe a little bit of CSS (No Service Workers, Background Sync, DRM, etc.) and make it work over a LORA/Meshtastic rig somehow.
It's becoming a dream and a curious or nearly unattainable goal, without being adjacent a very heavy software stack. But I think having a separate screen on a phone, like a flip phone with a screen on each side, would help separate the two software and OSes that could run them. One light, and one heavy.
Maybe you're overthinking it. Perhaps instead of creating a whole new stack, you just want to host a "personal blog" yourself. You could even consider creating a listing of similar sites you have found. If all people that want this kind of web host their own personal site I suspect it come to reality. There are of course already several collections of sites like this, 1mb.club 10kb.club nocss.club tilde.town wiby.com sdf.org and more.
You could also consider Gopher or Gemini to find like minded individuals.
I think we could learn from an old (gone?!) Google+ post from Ian Hickson on what could possibly replace HTML but a lot of the criteria applies to Web/Internet as a whole (https://www.sitepoint.com/will-html-ever-be-replaced/).
Ian Hickson (“Hixie” — WHATWG specification editor, CSS2.1 co-editor and Google’s W3C representative) recently published an interesting post on Google+. He’s occasionally contacted by people suggesting a better alternative to HTML but, in all cases, none have come close. Ian states that any technology would need to satisfy at least five objectives to displace existing web technologies:
Be devoid of licensing requirements.
Be vendor-neutral and accept input from everyone.
Be device and media-neutral; it should work on PCs, TVs, mobiles, tablets, screen readers and any future hardware.
Be content-neutral and not restrict itself to types of document or application.
Be radically better than the existing web in every way; faster, more usable, more features, easier to develop, easier to monetize, etc.
HTML can fail objectives two and three. Technologies such as XHTML2 and XForms only satisfied one and three. Java and Flash struggle in all areas — and I’d also add Google’s Dart to that list.
Maybe this all means there’s a place on the net for gopher, Gemini protocol, or tilde.town or ssh BBSes?
Worth noting that Flash did succeed: It was widely used across the web and installed by enough web users that sites could usually assume it was available (though it was considerate to provide fallback content) - that even though it needed a separate installation step!
It took a conscious effort by browser vendors and Adobe to kill it and replace it with other technologies. Maybe for good reasons, but it was definitely not a "free market" development.
I also find the list a bit weird and even hypocritical in places, as, like you say, HTML itself doesn't pass all criteria.
I'd also question other points for the general usefulness as an alternative: Why does an alternative tech necessarily have to accept input from everyone? Not even open source projects do that.
Also, why does it have to be content-neutral and have to support any kind of application? Pre-web technologies generally were "host neutral" - they let you connect to any host that supported the protocol - but the protocol usually had very well-defined application semantics. It seems instead of trying to "boil the ocean", a better way would be to focus on specific domains that could benefit from alternative technologies the most.
Be device and media-neutral: Just to note, Apple only allows single-purpose apps and points to Safari for everything else. They literally forbid anyone from trying to promote any "alternative web" unless they have a say in it.
(Not quite sure about the Play Store right now, but they likely do something similar)
So taken strictly, thay point would be a nonstarter unless you already have connection to the higher-ups of current Big Tech companies.
Flash succeeding is subjective. There were many who were hostile to Flash (and Java) for a long time. I actively disabled the Flash plugin except when necessary.
HTML not passing the criteria doesn't negate it from being the current leading technology. All it indicates is that there could be a technology that does more (most) of these things better. And, it sets a certain benchmark for the next technology to aspire to.
I think accepting input from anyone is a resiliency feature. Imagine if only Governments drove the Web? Or Multi-national Megacorps? Billionaires? Choice and freedom helps to democratize and enable usage by participants who are diadvantaged.
Content-neutrality is experiential. That is to say, gopher is well known to be more organizationally efficient at transimitting data than http. However, it was primarily aimed at text transmission and was very poor at supporting applications (like banking, commerce sites or email). These were huge boons to the current Web.
> Flash succeeding is subjective. There were many who were hostile to Flash (and Java) for a long time. I actively disabled the Flash plugin except when necessary.
I would define "succeeding" as "having overcome the chicken/egg problem, having a wide enough support as to be practically usable as infrastructure and enough content/use that it is relevant", regardless of how well liked a technology is.
E.g. I think JavaScript very clearly succeeded on the web, even though many people still turn it off and there are a lot of good reasons to. By that logic I think Flash had succeeded as well.
Seems like the whole "no tracking, no targeted advertisements" is a great feature of Gopher & Gemini. BBSes do tracking but it seems rarely used for advertisement its more distributed anyway so if you don't like a BBS you can move to the next one connected to the same messaging networks.
Then there is also the communities, increased accessibility (it's just text) and the more structured nature of the "sites" which may be a feature.
So I would argue that there is definitely some benefits (for the user) to those alternative protocols.
Part of #5, "easy to monetize" leads inevitably to "easy to enshittify". I think this is a point that's not generally well enough understood. If a platform emphasizes monetization, its early adopters will all be grifters and it will provide no benefit to anyone else (cf blockchain).
Gemini and Gopher fail #4 because they aren't application platforms. But I think we probably need to step back and rethink the "deliver sandboxed application that you run automatically" use case. If we really want to still do that, we might want to design something for that purpose from the start. But we might also come to the conclusion that it's fundamentally not a good idea.
I'd presume we're almost all using the Web primarily on some employer's dime (except where we are self-employed but it still applies). Prior to the Web 1.0, I remember interacting with people/managers that discouraged reading email or news or forums or other casual/non-work uses of the Web. I remember articles about employers allowing their programmers to read their email "up to" 2 hours per day. Now we're expected to have rapid response/access to email, slack, SMS, etc.
I believe this is because the commercialization/monetization of Web usage is beneficial to commercial entities. If that isn't possible, then the few who build the Web aren't able to build it in the first place. It's akin OSS and concepts of commercialization in the GPL. You can't create equity if there is no method to transfer value.
I actually prefer if whatever comes next does not include #5. I'd rather Project Gemini stay the way it is versus every website trying to browse my local storage, troll my localhost sockets, and use any scripting, to be honest. For me, personally, as my own choice, HTML+CSS and no scripting, especially third party scripting, is my kind of WWW replacement.
And this might be unpopular here, but monetizing the 'Net (advertising) is what got us in this Dystopian Digital environment in the first place.
I agree. It's also the evil that created the need and improvements like SSL/TLS, ssh, gzip, bzip2, lz4, Linux, etc. and so many other worthwhile innovations.
"We all (hopefully) know the world would be a better place with less JS but you can't put the genie back in the bottle."
I don't know that.
I suspect you hate javascript because so many ads and tracking software is written with it? Replace JS with something better and the ads will just be written in that.
Otherwise JS .. works and is simple. And compiling any language to wasm very doable nowdays. What would be the alternative?
(Personally I would like to see TS native in the browser)
Reasons vary per person but personally it's more about bloat. JS as it's used today is very different compared to its initial use case. We build entire applications in JS now, which is cool, but we do this by treating JS as a build target. The code we write is not executed as-is by the browser, it is transpiled and bundled up first. It's way too late to change now but I'd prefer something that embraced application development so that you don't need to pull in React/Vue/whatever and do all of this. Something more opinionated like what we use for native apps, but with the flexibility of HTML+CSS.
"works and is simple"? You can argue JS works by definition because it is what people use, but it is far from simple -- JS and C++ are basically the only two programming languages where books plead with you not to use all their features but use a more maintainable subset.
I mainly hate JS because when I go on the web I want to view documents with maybe simple forms for interaction and not complex applications. It's not the implementation that's the problem but giving websites compute capability without explicit permission.
FWIW, while I represented Google in the HTML working group (for a few years; it was a complicated relationship), my work on HTML at Google was primarily done via the WHATWG.
I was not involved with AMP's development at any point that I recall.
Point #5 seems near impossible and even furthermore undesirable. Unless we are envisioning an application with all the characteristics of a web browser, but using different layout languages.
Interesting link! I haven't heard of him, but I didn't have a new protocol in mind per se, since there are many old ones that are still good. But I would have removed the :// from http:// since even Tim Berners-Lee admitted that wasn't needed. I think HTML5 was an improvement from Flash, but there's a lot in the old web, like Xerox Star that had a smooth resolution in the files. Something like LaTeX..
I first heard of him via "Towards a Modern Web Stack (Ian 'Hixie' Hickson)" on HN [0]. Quite interesting. Note that the submission link is broken, the google doc link is added below [1].
And that concept was bonkers, proof conclusive that he had lost the plot—if his involvement with and endorsement of canvas-only Flutter wasn’t proof enough—and should be ignored completely until he comes to his senses.
The obvious benchmark would be: can you implement an HTML/CSS/JS browser inside this environment and have it behave identically to the browser’s own HTML/CSS/JS? And the answer is: not a chance. WASM + WebGPU + ARIA + WebHID is simply not enough. Browsers provide a lot of functionality in ways that web content cannot see or interact with. Some of it could be mapped, other parts of it never can be, for security/privacy reasons. And the more you want to map, the bigger your spec gets, until you’ve added every diverse feature from every OS to the web’s API surface—and then you stop browsers from adding new functionality, too.
Some examples of things that can’t be implemented in web content (most fundamentally, one or two merely currently): Native text rendering in this WebGPU world. Links with all their functionality. Native font preferences. Text selection and its interactions with native platform functionality (including things like context menus). Native scrolling behaviour. The browser as a compositor (important for things like scrolling and video performance). Browser extensions (the user agency part of that first scathing comment).
The things you list that couldn't be implemented in such an environment are a mix of two things, first, things that browsers are specifically designed to _prevent_ a web page from doing, e.g. to avoid leaking privacy, and second, things that absolutely should be possible in that environment, because if they're not, then the environment isn't yet complete.
But in practice I don't think either is especially critical. You can already do pretty much what I suggested just by running the Wasm code against WebGL in a stub HTML page; it hasn't stopped people from creating such things (e.g. Google Docs, Figma, Flutter, etc). The core thing I proposed was allowing the inversion of the architecture so that the Wasm code could be a top-level resource the same way text/html and application/pdf are today. Sure, it could be improved in time by allowing some of the things you list, but that doesn't mean it wouldn't be useful today. The perfect is the enemy of the good, and all that.
Your concept is an extension of what I call the pure-canvas approach. Less bad than current pure-canvas, but a lot of the problems of pure-canvas will persist.
Google Docs is not pure-canvas. If it were, it would be horrible. As it is, it’s… meh, fine I guess, merely somewhat worse than before it started using canvas at all (incorrect keyboard behaviours, worse performance, terrible latency and jitter, though still not as bad as whatever Microsoft call their version of Word that runs in a web browser).
Figma only uses canvas for its canvas, which pretty obviously should indeed be canvas; all UI is DOM, and it would be much worse if it were not.
In a web browser, Flutter is horrible. I loathe, detest and abominate it with vitriol befitting sulphuric acid.
And those paying close attention will of course immediately recognise the highly distinguishing 21 digit string "107429617152575897589", a/k/a Ian Hickson's G+ userID / UUID.
Google+ placed all posts under the '/posts' URL segment, and has a wildcard syntax for searching for all captures under a given URL:
Going through those individually, I eventually turned up the original link.
It's also possible to see the first 2-ish 'graphs of the post by looking at captures of Ian's G+ profile page. Unfortunately, there is no direct link to the full post from this view, though if you view source you can find the post-ID, notably in the JSON data at the top of the post following "AF_initDataCallback". I'd turned it up by going sequentially through the captured posts above however, and only discovered that the postID is actually on the Profile page afterwards. The two (partial) 'graphs begin with:
Occasionally, people e-mail me to say something along the lines of "I've come up with something to replace HTML!"...
Oh, and the Internet Archive is one of the few parts of the Internet which do not precisely suck. If you can send them love, or better, money, please do.
I’d say Markdown meets every one of those criteria except “more features” (which is a feature IMO) and “easier to monetise” (which is another feature. :D )
You mention it fails number 5, but I think Markdown also fails number 4. It’s pretty restrictive with the types of documents it can create. It’s HTML and traditional web technologies that gives it the illusion of flexibility.
To be displayed in a pleasing way to most humans, it’s also rendered as HTML, usually with some kind of styling. In a world without HTML, what is Markdown going to use?
LaTeX? That's actually the primary use case I've seen for markdown -- to write papers/presentations/code notebooks in markdown that are then turned into LaTeX for typesetting.
Sorry, I meant one of the early X-Window predecessors from the Alto era- I don't remember which one(s), but it had a pixel perfect rendering aspect that appeared at least much lower level and the GUI used far less memory. The most recent one that resembled that is X11R1, which I have tested on a VM linux image from ~2005, called Xwoaf.
Edit: I might have confused LaTex with https://en.wikipedia.org/wiki/NeXTSTEP. I think it was more efficient in handling data, but then again, platforms age whenever a new application needs more memory, so they got abandoned because it was more efficient to bundle it into something like Wayland...
Yes, that's it- Interpress/PostScript. I remember Forth used it. There's something about the typesetting that I love and can't figure out. But I notice it, even on old monitors. Wonderful stuff. I really like the DTSN displays too: https://retro.swarm.cz/20170902/1143/
Can you explain how you see that they fail 2 and 4?
To me it seems with Gemini, Gopher and BBSes (tilde.town is html so let's skip that) they can serve any type of content they want and you can probably already connect to it and retrieve something readable.
No need to rebuild from ground up, sites just need a low data bandwidth fall back, perhaps with a new html tag indicating user is needing low bandwidth - much like sites used to provide a mobile ready area that was the same page load but simplified somewhat.
For the bleakest of disasters, bandwidth would be a premium but a lot can still be done without bandwidth hogging scrip overheads, so site developers just need to include a low bandwidth fall back for the basics - I dare say it might even be lest costly for the LLM scrapers if it were widly adopted. I'd suggest for an idea of basics touring some sites where each page has a small footprint [1] [2] [3] [4] ... I recall days on dialup 3 KB/s - a meg was a wait-a-while.
However I don't hold much hope, generally, things only happen out of necessity.
It's all of the above, integrated with a maximum latency for each tier level. Not a new protocol, but adopting the best of the best, like QUIC over UDP: https://en.wikipedia.org/wiki/QUIC#Client_support
Apple is a vertically integrated company, so the idea is that a mobile carrier/ISP could help ensure the middle trunk from server to client arrive in a timely fashion. Often that involves good QoS and limiting streaming to 720p. But there are a lot of other things that can be done to limit slow page loading. For example, I tried loading Reuters on a slow data connection, and it took much longer than BBC. https://idlewords.com/talks/website_obesity.htm
I still don't get it. I came here to make much the same comment as you are replying to.
Unless you mean that your parallel internet is just the regular internet but with the protocols you personally like? So its more of a web thing where you promote sites that aren't bloated?
> so the idea is that a mobile carrier/ISP could help ensure the middle trunk from server to client arrive in a timely fashion.
I don't know that demanding someone like Hurricane Electric to use QoS is going to have a desirable outcome. Is this more a government thing? Forcing T1s to use QoS? My gut tells me that ignoring QoS markers saves them an appreciable amount of CPU, and also lets them act more neutrally.
How do I as a carrier service your "Thinnernet". How "Parallel" is the infrastructure? Do I have to buy capacity or can we peer? Do I have to maintain a separate routing table? Do you use BGP or something else? Are you planning to buy L2 international capacity to "Replace" T1's? What do you do if a carrier starts sending everything as EF? Is there a PoC node or network operating anywhere?
I just don't see anything in here except for broad references to undersea cables and UX.
the references are metaphorical. App developers like Facebook have Lite versions of their Messenger. No actualy physical sectoring or allocation needs to take place. What it's emphazing is that App developers have a liteweight mode. Google got rid of their HTML page version when checking GMail on the web in 2024. Their app still works relatively fast, but on a 128KBps connection, loading a single page on the Javascript only desktop browser version is really, really slow. Like 5-10 minutes slow. I wrote more in another response here:
https://news.ycombinator.com/item?id=48453653
The Symbian phones from Nokia and Sony were ultra-efficient. Not everyone remembers that era, but they were real time operating systems that ensured tasks got completed in a certain time, including user-prompted inputs. It's not a technical limitation of a company or service, but a lot of their revenue might depend on a minimum number of ads or cookies and web analytic trackers being visible on a page. Often in the numbers of 30 or 100+. With all those elements removed from a site, the service might not bring in much revenue. So it's not really an issue of technical capability, but a business model.
Personal blogs don't typically have this issue, as they can be hosted on a small home server, or a remote server, and aren't concerned as much with ads. I can't suggest how the internet should be run, and the article does acknowledge the benefits of a decentralized web. But predictability of content delivery ETA from internet speeds is not an impossible thing to optimize towards, even if uptime isn't above 99%. What is somewhat novel in this proposal is standardizing a subset of typical website activities, like checking news, weather and mail, and getting a more predictable completion time for certain tasks, but factoring in known latencies from wireless providers (as pings will not be as low as a wired connection), and lowering the average latency for the round trip.
On a much larger scale of interactions- but again the web is so wide and varied, that most of those things cannot be standardized, nor should. But kind of like measuring the commute time of an expressway in a city, or subway trips to a grocery. Things that people need and won't optimize more with an Uber. Hence measuring static over HTML is an easy test, and more sophisticated web services can and do have those kinds of benchmarks. But integrating the device, ISP, and server in a way where certain activities can get slightly preferential treatment like ordering and picking up a prescription at a pharmacy, setting appointments with a doctor, would not get deprioritized bandwidth compared to someone streaming something in 4k, and maybe temporarily limiting that other user's bandwidth to 1440p for maybe a few minutes.
So I do think a tiny bit of QoS or speed throttling is needed only in exceptional cases, but for the most part, the typical user wouldn't notice or necessarily need that level of speed adjustment. Most of the optimization would take place at the software, website, and OS level.
I agree most of the issue is on the "web" and not the physical infrastructure, although there is an internet outside the "world wide web" too:
https://yesterweb.org/zine/issue-05/08/
"The internet and the web are not one and the same. The web is simply one protocol of the internet. You see the "https://" at the beginning of the url bar? That's the Hypertext Transfer Protocol, or as it's more commonly known, The World Wide Web."
I sometimes mention the two because multiple protocols are part of the Transport layer. But then again, relying on one too much may be part of the problem, hence the emphasis on examining all the layers and protocols, like UDP.
But you don't really examine the other layers, just talk about them. You aren't proposing alternatives.
Honestly if you cut through everything that's brought up and left dangling, whats left is Website and App efficiency, and a very sizable percentage of apps are just wrapped websites.
I just did a ctrl+f on the page and couldn't find a reference to UDP.
Edit: One thing I didn't include in the article was file sharing protocols, because of security vulunerabilities. I recall IPFS had some known issues, but others have tried to use similar protocols:
Do they work faster than the regular web? Well, torrents can download faster. But I do not know how much the web depends on it or needs it. I know Microsoft and Steam servers allow downloading games and updates from other PCs, including ones outside a local network. Why they offer it (for Windows system files), is beyond me. Maybe some areas (public networks) share an unsecure wifi network more often and do not own a separate router for trusted internet access. I guess the files are encrypted enough that there is a checksum that can determine if the files are not tampered?
>I must admit I am still having a hard time following you.
You're not the first. A "sister" project I started in 2020 is hardware focused, and later on, I determined that a lightweight suite for internet would complement the offline stack: https://ei2030.github.io/FemtoTX/#about
One could say it's a "solution in search of a problem", but game development also is an incubator:
There are other Jobs inspired R&D groups out there- a notable one is Ink & Switch: https://www.youtube.com/watch?v=9s8OA08ggbM They use an aircraft carrier vs. bicycle comparison, as Steve Jobs preferred the bike metaphor as an extension of user capabilities.
>Why should a household or office download windows update files more than once? Seems like a great idea.
I agree with you on that. I also use it to share files and updates on my own network, often when transferring Steam games from one PC to another. I meant for non private networks (like internet cafes) is where I thought there might be a security issue.
https://www.tomsguide.com/computing/windows-is-using-your-in... I do not really know whether it's secure enough, but I'm going to leave that to the experts.
HTTP isn't the WWW. Back when browsers supported FTP and Gopher, you could deliver the exact same HTML, for the exact same experience, over either protocol.
Core idea from this: we do need something that discourages web page bloat. The last try at this was Google AMP, which didn't go over well with either site operators or users. Any better ideas?
AMP was controversial because it initially prioritized Top Stories cached on Google servers as opposed to other operators, but its nominally open source spec eventually allowed other sites to improve their ad optimize revenue:
https://en.wikipedia.org/wiki/Accelerated_Mobile_Pages#Monet...
I think its current issue with AMP is that it makes the web seem flattened, with pages appearing more the same than having more independent formats. I think that if the average page can be smaller than the average AMP standard e.g less than 1.5MB, then a CDN wouldn't need to prioritize AMP.
A friend of mine referenced the 64KB demoscene competitions, which were creative use of video graphics.https://64k-scene.github.io/
250KB Club seems like a nice place to start with websites: https://250kb.club/
To be honest, one thing I've been interested in is a totally markdown-only web. You leave everything the same, you just use a Markweb browser as the only thing and it only accesses text/markdown. Then I build Yet Another Protocol Bridge for my blog and no one visits it ever again. That sounds like fun.
The trouble is, people keep extending Markdown to add HTML features. There's even Javascript embedded in Markdown.[1]
You'd just create churn, not a fix.
Haha that’s what I was joking about. I already have a Gemini bridge at gemini://g.wiki.roshangeorge.dev and I’ve had maybe two days in its history with any visitors. Funny.
I have the impression that the author does not want to build a parallel internet (which involves whole new protocols replacing, say, IPv4, IPv6, TCP, UDP, ICMPv4, ICMPv6, DNS, perhaps TLS, ...), but rather another application-level protocol replacing HTTP and the web.
Remember that the world wide web is just one of insanely many application-level protocols that can be run over the internet infrastructure.
Correct. The idea is to narrow the application access view from the desktop or home screen of a mobile device to a limited set of optimized apps and protocols that can traverse the web. It's kind of like a dedicated bike lane alongside a boulevard in a major city. One can bike as fast if not faster than cars, but they'd need to adhere to the rules of the bike path.
I have been working on an alternative to http, and the thinking comes from the same place, thank you for sharing. I still have a way to go, but it's definitely possible, and it is definitely a good idea, I'm very excited about http alternatives in general, we should have many.
Not sure I understand exactly, but I have no desire to host trackers, the idea is that either the client or the host will be hosting their own trackers, or going through some third party trusted tracker hosting service.
Its always trying to cut bloat. Cant someone have a vision for a better internet that better caters to modern use cases and utilizes modern tech stacks to deliver the best possible experience? I dont see any value in going back to 100kb web pages
A significant amount of the bloat on the modern internet is to facilitate marketing and advertisements, not for the benefit of the user.
I often wonder if we see this downward spiral on sites, because their attempts to monetize increase their costs, which require them to increase monetization efforts, which increase…
If we stripped it back, how much would some of these sites really need to run?
Multimedia is inherently large, but there are a lot of diminishing returns as resolution and size increases.
People bought the newspaper for the cartoons rather than the ads, but the ads supported to printing costs. Eventually the competition became so fierce one of the news giants lowered their cost to 1 penny.
Maybe lightweight internet use is a skill that needs to be trained. But with a solid connection for working, I see this less prioritized.
yes and no. I agree there is some amazing things that can be done with larger websites, but one has to wade through a lot of unoptimal sites to find the good ones.
Correct me if im wrong, but arent you trying to introduce a space where its impossible for larger websites to exist thus everything is restricted to the bare minimum website features like its 1999. I do not see the point in that, to me the problem isnt a blog with fancy JS vs a blog with static text. Its about corporations exerting outsized amounts of control over how people interact with the web. I want the new web to solve that problem and also be able to serve 4k video.
You can already do that. If your home page is a fediverse feed or client, the users provide the content without an algorithm. Many people who have a browser with a Google search bar might think corporations control a lot, but one can set a different browser, DNS, and search engine. The thing Steve Jobs did was simplify the out of the box experience, so when they bought a Mac, there'd only be a dock with Safari at the bottom. One could develop an open source machine with a very unitary goal of accessing a lightweight web using a protocol or extension similar to No script but the average non-technical user might not know how to do that.
Of the many Linux distros I've tested, maybe a handful are actually easy to use and not heavy. One example is Bodhi Linux. But I have something more like Tiny Core Linux in mind, except polished (it features a dock, surprisingly). If the hardware could be developed for this too as open hardware, there would be the added advantage of it having more ways to improve it. I'm a bit oxymoronic in having a vertically integrated product idea and an open source bias, but a lot of great ideas need a coherent outline, which sometimes start out as closed source.
If the project starts out with enthusiasm but it gets forked, then it becomes impossible to develop one feature that many people didn't realize would be overall a better user experience, or streamlined option, at the very least.
Personally, I think Reticulum is the parallel Internet. It could even replace the Internet Protocol, and whatever the IP protocol connects is in my view the Internet.
there's also the network effect to deal with. The Internet is a WAN of WANs. you might have a great parallel Meshtastic network, but if few people are using it, its range might be limited.
what about going in the other direction? apps instead of sites. wasm for everything, shared immutable libraries, strict capability based security. client side rendering where you can choose between html+css, new binary formats or doing everything from code. easy server overrides so you can redirect all requests from bigtech.com to service.mydomain.net without the app ever knowing. encourage federation and sharing instead of isolation (but thats more of a culture problem new tech cant really solve). put the user back in control.
I feel like I missed where exactly the parallel part splits. Do they want to make new wires? New fibre protocols? A new TCP/IP stack? Just make another Gopher/Gemini?
The coordination and discipline required to build it is quite simply not there (or here, or anywhere). We will sooner have multi-gigabit space internet or 7G.
That would be high bandwidth and high latency, which might be the opposite of what's being proposed in the article. (It's difficult to be certain what's being proposed in the article. I'm fairly sure the article is about internet, beyond that point all is guesswork.)
I wrote a number of articles that try to address the many stacks of the application, transport, and OS layers. The best platform I can think of are the mid 2000's Symbian S60 phones, which were Real Time Operating Systems and used J2ME:
https://inavoyage.blogspot.com/2026/06/how-about-new-java-ba...
There are new Java'based platforms that could build upon that, but chips today have so much processing power that they might think it's easier to develop a higher level language with more dependencies. But that leads to more maintenance if some package gets lost or broken.
Once Android and iOS became the leading smartphone makers, code efficiency wasn't super important, because they hardware makers could add 10-20X the RAM. The competition between Symbian and iOS was a brief decade, but it actually made efficient code development interesting and beneficial for battery life. Since RAM got cheaper, even though it's expensive at the high end (HBM3e), it's a lot easier to develop with 4GB of phone memory than 4MB on the Nokia 7650 (2002). Those are quite extremes, but most symbian phones had a lot of features with as little as 32MB of RAM. https://en.wikipedia.org/wiki/Nokia_7650
> There is a funny email that had been released after before Jobs's passing where a user complained of a spotty signal, and his advice was basically to not hold the phone in that direction (or with his hand over the top part where the antenna was positioned).
Is this a reference to “antennagate”[0], when Jobs dismissed an affected user telling them to “just avoid holding it that way”[1]?
> because 3G technology at the time wasn't robust, and one shouldn't have expected him to have all the solutions that were out of his control
If so, this is an incredibly bad take. Lots of other phones had implemented good 3G connectivity at the time, including Apple's own prior iPhone. Apple made a mistake here, and the takeaway should be that corporate hubris is real and companies aren't your friends, not some cockamamie prattle about how we should accept bad products because technology is hard, boo hoo.
> had Jobs lived to 70 or 80
Jobs' own death is another fine demonstration of his arrogance. Very ironic to refer to it in this paragraph.
Yes, I now realize it was the antennagate story. I included a link to a Slate article that featured an even more unsympathetic writer, which was in 2010, a year before Jobs died.
In retrospect, I think Jobs knew his time was limited, and telling a customer not to hold it that way wasn't an unforgiveable sin- in fact, there was some truth to it, even if they didn't have a better modem at the time (my article mentions Qualcomm).
I mean, a slow, deterministic, latency focused network standards sounds a lot like ISDN and ATM(Asynchronous Transfer Mode) standards... there were such lost competitors to Ethernet, HTTP, HTML, etc.
Why not use those extra fiber optic cables as part of the actual internet? You can immediately start making money off of it due to people getting legitimate value from it. If other lines were to be cut or have issues your lines would act as a backup. And yes if things got overloaded it would act slower. It seems unoptimal to make a completely separate network.
I tune out at this "what Steve Jobs would have done" talk. A thing needs to stand on its own without borrowing Steve Jobs (or Jeff Dean as I saw someone do the other day).
Pretty much, we don't know what Steve would have done and even if we did, there is no guarantee that it was a good idea. When he had hits, it was brilliant but there were many stinkers as well.
I suspect if Steve was doing a new internet it would be a walled garden like the App store, so a worse internet that favors him. As Woz said, Jobs just wanted to have a business and be rich, didn't really matter what the business was. Any illusion of a greater good was always a calculated bet in getting more users.
Job's did some great things for the industry, I also call him the architect of the locked down digital jails we are inhabiting. But we shouldn't put him up as some perfect beacon of the industry.
For something so complex like a PC or desktop experience, having a bunch of oppositional goals (like ad pop ups) do not serve the user well enough. Often times a committee releases a product, but there is no real consensus or accessibility in mind.
That sounds like a false dichotomy. You want opinionated software? Great, so do I. Design the software, own your decisions yourself, and explain your thinking without shortcuts.
Also, steve jobs made utterly stupid decisions in a lot of areas. If you're trying to revolutionize something, try not to use someone who was clearly flawed in many aspects. Otherwise it sounds like you're just building a facade.
Yes, and Seward also made a Folly. I suppose he missed out on some things, but his success rate at predicting features that are now standard was higher than most in that era.
Yeah, reading his biography was interesting. He had the problem of tech not quite being where he wanted it to be over and over. But eventually things really hit.
I've sort of been thinking about this as well. Personally, I'd like to re-capture the era of personal blogs and niche knowledge discovery of the earlier web I experienced - crossed with something easy to host/publish and not requiring a browser.
I don't really have any coherent picture but I would like to see these ideas I think:
- Anti-commercial/anti-tracking: maybe requiring some sort of open-source license for all published content that makes it harder to commercially exploit the information, ideally this would be by and for the community, especially in light of recent aggressive LLM-training crawling. I would also like to exclude advertisement and tracking.
- Browser-less: The idea would be to do away with the complexity of the modern web (as people say, browsers are basically operating systems), back to more of its hyper-text roots. Simple documents, mostly textual information. I could imagine a mix of basic markdown and some pre-wired complex/interactive views like "forum" or "blog" and so on (differences in how data is loaded, presented, ...) - the idea would be to implement the "app" part in the browser-replacement and not in the web-page itself if that makes sense. This would lead to more uniformity but that might be a good thing. I'm not even sure if/how images would fit in or videos.
- Peer-to-peer?: Hosting should be as simple as hitting a "publish" button on an article. I like the idea of decentralization, so maybe there could be some sort of peer-to-peer federation where users could "host" content that they've read, liked or general content that's part of a certain (sub-) community. This might require some ranking like HN or a similar mechanism to (unfortunately) censor certain content if the community would not believe it to match their values - so not ultimate freedom. P2P would be more about decentralization, and maybe anti-tracking than pure censorship-resistance.
A session might look like opening the "non-browser" app - it would be fast and require very little memory. Then you'd select or type a community/site and you view of all the content with filters and sorts, depending on the community/site's "template" (again, this is not JS/HTML - basically a native form rendered directly if you will). When you feel like it, you click the "create" button, a text-area + preview pops up and you write your post or article in markdown. When happy, you "publish" and it gets slowly disseminated through all the P2P nodes of your community. This could encompass communities like HN or reddit even if the voting mechanics are worked out, personal blogs, ... but would probably exclude e-commerce stores or video sites because the engine would be potentially too simplistic - and that's fine by me.
You have the right ideas, and there are protocols that do this, some more isolationist than others: https://yesterweb.org/zine/issue-05/08/ "The Web Outside the Net" and https://wiki.archiveteam.org/index.php/SmolNet
Modern smartphones could implement more Data Saver features, but websites could opt-in by using less data. For example, https://marcusb.org/hacks/tinyblog.html
Some of that sounds like Hyphanet (a.k.a. Freenet): https://en.wikipedia.org/wiki/Hyphanet
I've been thinking more lately about how to get "Basic Web" - just like normal HTML and maybe a little bit of CSS (No Service Workers, Background Sync, DRM, etc.) and make it work over a LORA/Meshtastic rig somehow.
It's becoming a dream and a curious or nearly unattainable goal, without being adjacent a very heavy software stack. But I think having a separate screen on a phone, like a flip phone with a screen on each side, would help separate the two software and OSes that could run them. One light, and one heavy.
Maybe you're overthinking it. Perhaps instead of creating a whole new stack, you just want to host a "personal blog" yourself. You could even consider creating a listing of similar sites you have found. If all people that want this kind of web host their own personal site I suspect it come to reality. There are of course already several collections of sites like this, 1mb.club 10kb.club nocss.club tilde.town wiby.com sdf.org and more.
You could also consider Gopher or Gemini to find like minded individuals.
I think we could learn from an old (gone?!) Google+ post from Ian Hickson on what could possibly replace HTML but a lot of the criteria applies to Web/Internet as a whole (https://www.sitepoint.com/will-html-ever-be-replaced/).
Maybe this all means there’s a place on the net for gopher, Gemini protocol, or tilde.town or ssh BBSes?> Java and Flash struggle in all areas
Worth noting that Flash did succeed: It was widely used across the web and installed by enough web users that sites could usually assume it was available (though it was considerate to provide fallback content) - that even though it needed a separate installation step!
It took a conscious effort by browser vendors and Adobe to kill it and replace it with other technologies. Maybe for good reasons, but it was definitely not a "free market" development.
I also find the list a bit weird and even hypocritical in places, as, like you say, HTML itself doesn't pass all criteria.
I'd also question other points for the general usefulness as an alternative: Why does an alternative tech necessarily have to accept input from everyone? Not even open source projects do that.
Also, why does it have to be content-neutral and have to support any kind of application? Pre-web technologies generally were "host neutral" - they let you connect to any host that supported the protocol - but the protocol usually had very well-defined application semantics. It seems instead of trying to "boil the ocean", a better way would be to focus on specific domains that could benefit from alternative technologies the most.
Be device and media-neutral: Just to note, Apple only allows single-purpose apps and points to Safari for everything else. They literally forbid anyone from trying to promote any "alternative web" unless they have a say in it.
(Not quite sure about the Play Store right now, but they likely do something similar)
So taken strictly, thay point would be a nonstarter unless you already have connection to the higher-ups of current Big Tech companies.
Flash succeeding is subjective. There were many who were hostile to Flash (and Java) for a long time. I actively disabled the Flash plugin except when necessary.
HTML not passing the criteria doesn't negate it from being the current leading technology. All it indicates is that there could be a technology that does more (most) of these things better. And, it sets a certain benchmark for the next technology to aspire to.
I think accepting input from anyone is a resiliency feature. Imagine if only Governments drove the Web? Or Multi-national Megacorps? Billionaires? Choice and freedom helps to democratize and enable usage by participants who are diadvantaged.
Content-neutrality is experiential. That is to say, gopher is well known to be more organizationally efficient at transimitting data than http. However, it was primarily aimed at text transmission and was very poor at supporting applications (like banking, commerce sites or email). These were huge boons to the current Web.
> Flash succeeding is subjective. There were many who were hostile to Flash (and Java) for a long time. I actively disabled the Flash plugin except when necessary.
I would define "succeeding" as "having overcome the chicken/egg problem, having a wide enough support as to be practically usable as infrastructure and enough content/use that it is relevant", regardless of how well liked a technology is.
E.g. I think JavaScript very clearly succeeded on the web, even though many people still turn it off and there are a lot of good reasons to. By that logic I think Flash had succeeded as well.
> Maybe this all means there’s a place on the net for gopher, Gemini protocol, or tilde.town or ssh BBSes?
All of those fail #5 for sure. And that's one of the most important points to bring in users IMO.
We all (hopefully) know the world would be a better place with less JS but you can't put the genie back in the bottle.
Seems like the whole "no tracking, no targeted advertisements" is a great feature of Gopher & Gemini. BBSes do tracking but it seems rarely used for advertisement its more distributed anyway so if you don't like a BBS you can move to the next one connected to the same messaging networks.
Then there is also the communities, increased accessibility (it's just text) and the more structured nature of the "sites" which may be a feature.
So I would argue that there is definitely some benefits (for the user) to those alternative protocols.
Part of #5, "easy to monetize" leads inevitably to "easy to enshittify". I think this is a point that's not generally well enough understood. If a platform emphasizes monetization, its early adopters will all be grifters and it will provide no benefit to anyone else (cf blockchain).
Gemini and Gopher fail #4 because they aren't application platforms. But I think we probably need to step back and rethink the "deliver sandboxed application that you run automatically" use case. If we really want to still do that, we might want to design something for that purpose from the start. But we might also come to the conclusion that it's fundamentally not a good idea.
I'd presume we're almost all using the Web primarily on some employer's dime (except where we are self-employed but it still applies). Prior to the Web 1.0, I remember interacting with people/managers that discouraged reading email or news or forums or other casual/non-work uses of the Web. I remember articles about employers allowing their programmers to read their email "up to" 2 hours per day. Now we're expected to have rapid response/access to email, slack, SMS, etc.
I believe this is because the commercialization/monetization of Web usage is beneficial to commercial entities. If that isn't possible, then the few who build the Web aren't able to build it in the first place. It's akin OSS and concepts of commercialization in the GPL. You can't create equity if there is no method to transfer value.
#5 is entirely subjective and IMO impossible to fully satisfy as the different sub-clauses conflict.
> “…you can't put the genie back in the bottle.”
Not for nothing, if you’re “building a new internet” you can do whatever you wish.
You fail criterion four: you're limiting what kinds of documents and applications can be developed.
I actually prefer if whatever comes next does not include #5. I'd rather Project Gemini stay the way it is versus every website trying to browse my local storage, troll my localhost sockets, and use any scripting, to be honest. For me, personally, as my own choice, HTML+CSS and no scripting, especially third party scripting, is my kind of WWW replacement.
And this might be unpopular here, but monetizing the 'Net (advertising) is what got us in this Dystopian Digital environment in the first place.
I agree. It's also the evil that created the need and improvements like SSL/TLS, ssh, gzip, bzip2, lz4, Linux, etc. and so many other worthwhile innovations.
"We all (hopefully) know the world would be a better place with less JS but you can't put the genie back in the bottle."
I don't know that.
I suspect you hate javascript because so many ads and tracking software is written with it? Replace JS with something better and the ads will just be written in that.
Otherwise JS .. works and is simple. And compiling any language to wasm very doable nowdays. What would be the alternative?
(Personally I would like to see TS native in the browser)
Reasons vary per person but personally it's more about bloat. JS as it's used today is very different compared to its initial use case. We build entire applications in JS now, which is cool, but we do this by treating JS as a build target. The code we write is not executed as-is by the browser, it is transpiled and bundled up first. It's way too late to change now but I'd prefer something that embraced application development so that you don't need to pull in React/Vue/whatever and do all of this. Something more opinionated like what we use for native apps, but with the flexibility of HTML+CSS.
"works and is simple"? You can argue JS works by definition because it is what people use, but it is far from simple -- JS and C++ are basically the only two programming languages where books plead with you not to use all their features but use a more maintainable subset.
It is simple as in people use succesfully javascript who have no idea what programming is.
I mainly hate JS because when I go on the web I want to view documents with maybe simple forms for interaction and not complex applications. It's not the implementation that's the problem but giving websites compute capability without explicit permission.
The original blog post was migrated back to my blog when Google+ shut down: https://ln.hixie.ch/?start=1344621190&count=1
Thanks so much. It also managed to be captured by IA as I've just noted:
<https://news.ycombinator.com/item?id=48471296>
The archived copy includes comments, which are dropped from your blog version.
> Ian Hickson (“Hixie” — WHATWG specification editor, CSS2.1 co-editor and Google’s W3C representative)
How long after this post did AMP come out? Three years?
FWIW, while I represented Google in the HTML working group (for a few years; it was a complicated relationship), my work on HTML at Google was primarily done via the WHATWG.
I was not involved with AMP's development at any point that I recall.
Thanks for the response! I had a feeling that AMP came from some other part of Google not too concerned about open standards.
Point #5 seems near impossible and even furthermore undesirable. Unless we are envisioning an application with all the characteristics of a web browser, but using different layout languages.
Two is impossible unless you want to be overrun by spam. Three and four are incompatible. Five is not a real criterion, it's a pipe dream.
Maybe he overlooked a requirement because it’s so obvious:
Be human readable
Interesting link! I haven't heard of him, but I didn't have a new protocol in mind per se, since there are many old ones that are still good. But I would have removed the :// from http:// since even Tim Berners-Lee admitted that wasn't needed. I think HTML5 was an improvement from Flash, but there's a lot in the old web, like Xerox Star that had a smooth resolution in the files. Something like LaTeX..
I first heard of him via "Towards a Modern Web Stack (Ian 'Hixie' Hickson)" on HN [0]. Quite interesting. Note that the submission link is broken, the google doc link is added below [1].
[0] https://news.ycombinator.com/item?id=34612696
[1] https://docs.google.com/document/d/1peUSMsvFGvqD5yKh3GprskLC...
And that concept was bonkers, proof conclusive that he had lost the plot—if his involvement with and endorsement of canvas-only Flutter wasn’t proof enough—and should be ignored completely until he comes to his senses.
The obvious benchmark would be: can you implement an HTML/CSS/JS browser inside this environment and have it behave identically to the browser’s own HTML/CSS/JS? And the answer is: not a chance. WASM + WebGPU + ARIA + WebHID is simply not enough. Browsers provide a lot of functionality in ways that web content cannot see or interact with. Some of it could be mapped, other parts of it never can be, for security/privacy reasons. And the more you want to map, the bigger your spec gets, until you’ve added every diverse feature from every OS to the web’s API surface—and then you stop browsers from adding new functionality, too.
Some examples of things that can’t be implemented in web content (most fundamentally, one or two merely currently): Native text rendering in this WebGPU world. Links with all their functionality. Native font preferences. Text selection and its interactions with native platform functionality (including things like context menus). Native scrolling behaviour. The browser as a compositor (important for things like scrolling and video performance). Browser extensions (the user agency part of that first scathing comment).
The things you list that couldn't be implemented in such an environment are a mix of two things, first, things that browsers are specifically designed to _prevent_ a web page from doing, e.g. to avoid leaking privacy, and second, things that absolutely should be possible in that environment, because if they're not, then the environment isn't yet complete.
But in practice I don't think either is especially critical. You can already do pretty much what I suggested just by running the Wasm code against WebGL in a stub HTML page; it hasn't stopped people from creating such things (e.g. Google Docs, Figma, Flutter, etc). The core thing I proposed was allowing the inversion of the architecture so that the Wasm code could be a top-level resource the same way text/html and application/pdf are today. Sure, it could be improved in time by allowing some of the things you list, but that doesn't mean it wouldn't be useful today. The perfect is the enemy of the good, and all that.
Your concept is an extension of what I call the pure-canvas approach. Less bad than current pure-canvas, but a lot of the problems of pure-canvas will persist.
Google Docs is not pure-canvas. If it were, it would be horrible. As it is, it’s… meh, fine I guess, merely somewhat worse than before it started using canvas at all (incorrect keyboard behaviours, worse performance, terrible latency and jitter, though still not as bad as whatever Microsoft call their version of Word that runs in a web browser).
Figma only uses canvas for its canvas, which pretty obviously should indeed be canvas; all UI is DOM, and it would be much worse if it were not.
In a web browser, Flutter is horrible. I loathe, detest and abominate it with vitriol befitting sulphuric acid.
(I’ve written about all of these before. https://news.ycombinator.com/item?id=42253177 is a fair starting point.)
Ian Hickson's original post lives on the Internet Archive's Wayback Machine here:
<https://web.archive.org/web/20130913091125/https://plus.goog...>
Raw URL:
For those wondering how I found this ...There was an attempt to preserve G+ content, and however heroic it was far less successful than I'd have liked.
The two key parts are the UserID and the PostID. That's "107429617152575897589" and "SiLdNL9MsFw" respectively.
I found Ian's G+ UserID from an archive of his homepage, here:
<https://web.archive.org/web/20120214010013/http://ian.hixie....>
That links to:
Which redirects to And those paying close attention will of course immediately recognise the highly distinguishing 21 digit string "107429617152575897589", a/k/a Ian Hickson's G+ userID / UUID.Google+ placed all posts under the '/posts' URL segment, and has a wildcard syntax for searching for all captures under a given URL:
Which you can access directly here: <https://web.archive.org/web/*/https://plus.google.com/107429...>.Going through those individually, I eventually turned up the original link.
It's also possible to see the first 2-ish 'graphs of the post by looking at captures of Ian's G+ profile page. Unfortunately, there is no direct link to the full post from this view, though if you view source you can find the post-ID, notably in the JSON data at the top of the post following "AF_initDataCallback". I'd turned it up by going sequentially through the captured posts above however, and only discovered that the postID is actually on the Profile page afterwards. The two (partial) 'graphs begin with:
Occasionally, people e-mail me to say something along the lines of "I've come up with something to replace HTML!"...
<https://web.archive.org/web/20121112102441/https://plus.goog...>
Oh, and the Internet Archive is one of the few parts of the Internet which do not precisely suck. If you can send them love, or better, money, please do.
Thanks for finding this!
I’d say Markdown meets every one of those criteria except “more features” (which is a feature IMO) and “easier to monetise” (which is another feature. :D )
You mention it fails number 5, but I think Markdown also fails number 4. It’s pretty restrictive with the types of documents it can create. It’s HTML and traditional web technologies that gives it the illusion of flexibility.
To be displayed in a pleasing way to most humans, it’s also rendered as HTML, usually with some kind of styling. In a world without HTML, what is Markdown going to use?
LaTeX? That's actually the primary use case I've seen for markdown -- to write papers/presentations/code notebooks in markdown that are then turned into LaTeX for typesetting.
Sorry, I meant one of the early X-Window predecessors from the Alto era- I don't remember which one(s), but it had a pixel perfect rendering aspect that appeared at least much lower level and the GUI used far less memory. The most recent one that resembled that is X11R1, which I have tested on a VM linux image from ~2005, called Xwoaf.
https://en.wikipedia.org/wiki/X_Window_System#History I recall some pdfs of the Xeroc PARC showed more info on it.
Edit: I might have confused LaTex with https://en.wikipedia.org/wiki/NeXTSTEP. I think it was more efficient in handling data, but then again, platforms age whenever a new application needs more memory, so they got abandoned because it was more efficient to bundle it into something like Wayland...
Possibly Interpress, a precursor to PostScript.
Otherwise the Alto used Bravo and Gypsy for WYSIWYG typesetting:
<https://en.wikipedia.org/wiki/Xerox_Alto>
Yes, that's it- Interpress/PostScript. I remember Forth used it. There's something about the typesetting that I love and can't figure out. But I notice it, even on old monitors. Wonderful stuff. I really like the DTSN displays too: https://retro.swarm.cz/20170902/1143/
> Maybe this all means there’s a place on the net for gopher, Gemini protocol, or tilde.town or ssh BBSes?
By your question (and Betteridge's law of headlines): no, as they fail at least (2), (4) and (5).
> as they fail at least (2), (4) and (5).
Can you explain how you see that they fail 2 and 4?
To me it seems with Gemini, Gopher and BBSes (tilde.town is html so let's skip that) they can serve any type of content they want and you can probably already connect to it and retrieve something readable.
No need to rebuild from ground up, sites just need a low data bandwidth fall back, perhaps with a new html tag indicating user is needing low bandwidth - much like sites used to provide a mobile ready area that was the same page load but simplified somewhat.
For the bleakest of disasters, bandwidth would be a premium but a lot can still be done without bandwidth hogging scrip overheads, so site developers just need to include a low bandwidth fall back for the basics - I dare say it might even be lest costly for the LLM scrapers if it were widly adopted. I'd suggest for an idea of basics touring some sites where each page has a small footprint [1] [2] [3] [4] ... I recall days on dialup 3 KB/s - a meg was a wait-a-while.
However I don't hold much hope, generally, things only happen out of necessity.
[1] https://github.com/bradleytaunt/1kb.club
[2] https://250kb.club/
[3] https://512kb.club/
[4] https://1mb.club/
I also contributed to one of those clubs.
There's also 10KB club: https://github.com/spxy/10kbclub https://github.com/marcus0x62/tinyblog
there is a whole lot out there. I personally like the following two also:
https://nocss.club/
https://no-html.club/index.txt (seems to be offline atm but archive.org has a captured version)
I'm struggling to understand what the concrete proposal here is.
> So what is Thinnernet? Imagine a fiber optic bundle of undersea cables- maybe a hundred or so 10Gbps cables comprising....
and the question goes unanswered. is it a protocol? physical layer? guideline? no idea.
It's all of the above, integrated with a maximum latency for each tier level. Not a new protocol, but adopting the best of the best, like QUIC over UDP: https://en.wikipedia.org/wiki/QUIC#Client_support Apple is a vertically integrated company, so the idea is that a mobile carrier/ISP could help ensure the middle trunk from server to client arrive in a timely fashion. Often that involves good QoS and limiting streaming to 720p. But there are a lot of other things that can be done to limit slow page loading. For example, I tried loading Reuters on a slow data connection, and it took much longer than BBC. https://idlewords.com/talks/website_obesity.htm
I still don't get it. I came here to make much the same comment as you are replying to.
Unless you mean that your parallel internet is just the regular internet but with the protocols you personally like? So its more of a web thing where you promote sites that aren't bloated?
> so the idea is that a mobile carrier/ISP could help ensure the middle trunk from server to client arrive in a timely fashion.
I don't know that demanding someone like Hurricane Electric to use QoS is going to have a desirable outcome. Is this more a government thing? Forcing T1s to use QoS? My gut tells me that ignoring QoS markers saves them an appreciable amount of CPU, and also lets them act more neutrally.
How do I as a carrier service your "Thinnernet". How "Parallel" is the infrastructure? Do I have to buy capacity or can we peer? Do I have to maintain a separate routing table? Do you use BGP or something else? Are you planning to buy L2 international capacity to "Replace" T1's? What do you do if a carrier starts sending everything as EF? Is there a PoC node or network operating anywhere?
I just don't see anything in here except for broad references to undersea cables and UX.
the references are metaphorical. App developers like Facebook have Lite versions of their Messenger. No actualy physical sectoring or allocation needs to take place. What it's emphazing is that App developers have a liteweight mode. Google got rid of their HTML page version when checking GMail on the web in 2024. Their app still works relatively fast, but on a 128KBps connection, loading a single page on the Javascript only desktop browser version is really, really slow. Like 5-10 minutes slow. I wrote more in another response here: https://news.ycombinator.com/item?id=48453653
The Symbian phones from Nokia and Sony were ultra-efficient. Not everyone remembers that era, but they were real time operating systems that ensured tasks got completed in a certain time, including user-prompted inputs. It's not a technical limitation of a company or service, but a lot of their revenue might depend on a minimum number of ads or cookies and web analytic trackers being visible on a page. Often in the numbers of 30 or 100+. With all those elements removed from a site, the service might not bring in much revenue. So it's not really an issue of technical capability, but a business model.
Personal blogs don't typically have this issue, as they can be hosted on a small home server, or a remote server, and aren't concerned as much with ads. I can't suggest how the internet should be run, and the article does acknowledge the benefits of a decentralized web. But predictability of content delivery ETA from internet speeds is not an impossible thing to optimize towards, even if uptime isn't above 99%. What is somewhat novel in this proposal is standardizing a subset of typical website activities, like checking news, weather and mail, and getting a more predictable completion time for certain tasks, but factoring in known latencies from wireless providers (as pings will not be as low as a wired connection), and lowering the average latency for the round trip.
On a much larger scale of interactions- but again the web is so wide and varied, that most of those things cannot be standardized, nor should. But kind of like measuring the commute time of an expressway in a city, or subway trips to a grocery. Things that people need and won't optimize more with an Uber. Hence measuring static over HTML is an easy test, and more sophisticated web services can and do have those kinds of benchmarks. But integrating the device, ISP, and server in a way where certain activities can get slightly preferential treatment like ordering and picking up a prescription at a pharmacy, setting appointments with a doctor, would not get deprioritized bandwidth compared to someone streaming something in 4k, and maybe temporarily limiting that other user's bandwidth to 1440p for maybe a few minutes.
So I do think a tiny bit of QoS or speed throttling is needed only in exceptional cases, but for the most part, the typical user wouldn't notice or necessarily need that level of speed adjustment. Most of the optimization would take place at the software, website, and OS level.
I would make that more clear. Maybe use "web" instead of internet. And drop all the references to physical infra.
I agree most of the issue is on the "web" and not the physical infrastructure, although there is an internet outside the "world wide web" too: https://yesterweb.org/zine/issue-05/08/
"The internet and the web are not one and the same. The web is simply one protocol of the internet. You see the "https://" at the beginning of the url bar? That's the Hypertext Transfer Protocol, or as it's more commonly known, The World Wide Web."
I sometimes mention the two because multiple protocols are part of the Transport layer. But then again, relying on one too much may be part of the problem, hence the emphasis on examining all the layers and protocols, like UDP.
But you don't really examine the other layers, just talk about them. You aren't proposing alternatives.
Honestly if you cut through everything that's brought up and left dangling, whats left is Website and App efficiency, and a very sizable percentage of apps are just wrapped websites.
I just did a ctrl+f on the page and couldn't find a reference to UDP.
That's because I wrote about QUIC & UDP in my previous post yesterday.
https://inavoyage.blogspot.com/2026/06/5-things-to-lighten-d...
https://blog.cloudflare.com/the-road-to-quic/
https://en.wikipedia.org/wiki/QUIC#Client_support
https://nordvpn.com/blog/what-is-quic-protocol/
https://www.fastvue.co/fastvue/blog/googles-quic-protocols-s...
My writing is tangential as it is, so I try to keep the layers separate in different analyses.
Java ME, Azul & OS (Symbian): https://inavoyage.blogspot.com/2026/06/how-about-new-java-ba...
Edit: One thing I didn't include in the article was file sharing protocols, because of security vulunerabilities. I recall IPFS had some known issues, but others have tried to use similar protocols:
https://en.wikipedia.org/wiki/Comparison_of_file_synchroniza... There are at least two that use QUIC, such as Kubo/IPFS and Syncthing: https://en.wikipedia.org/wiki/InterPlanetary_File_System https://en.wikipedia.org/wiki/Syncthing
Do they work faster than the regular web? Well, torrents can download faster. But I do not know how much the web depends on it or needs it. I know Microsoft and Steam servers allow downloading games and updates from other PCs, including ones outside a local network. Why they offer it (for Windows system files), is beyond me. Maybe some areas (public networks) share an unsecure wifi network more often and do not own a separate router for trusted internet access. I guess the files are encrypted enough that there is a checksum that can determine if the files are not tampered?
>That's because I wrote about QUIC & UDP in my previous post yesterday.
Ok
>My writing is tangential as it is, so I try to keep the layers separate in different analyses.
I must admit I am still having a hard time following you.
>Why they offer it (for Windows system files), is beyond me.
Why should a household or office download windows update files more than once? Seems like a great idea.
>Do they work faster than the regular web? Well, torrents can download faster.
IPFS in my limited experience is slow but reliable. Torrents are slow in peer discovery but fast after that.
>I guess the files are encrypted enough that there is a checksum that can determine if the files are not tampered?
Digital signature also.
>I must admit I am still having a hard time following you.
You're not the first. A "sister" project I started in 2020 is hardware focused, and later on, I determined that a lightweight suite for internet would complement the offline stack: https://ei2030.github.io/FemtoTX/#about
One could say it's a "solution in search of a problem", but game development also is an incubator:
https://www.thediff.co/archive/a-solution-in-search-of-a-pro...
There are other Jobs inspired R&D groups out there- a notable one is Ink & Switch: https://www.youtube.com/watch?v=9s8OA08ggbM They use an aircraft carrier vs. bicycle comparison, as Steve Jobs preferred the bike metaphor as an extension of user capabilities.
Someone here mentioned WAP https://en.wikipedia.org/wiki/Wireless_Application_Protocol which I completely forgot about, and AJAX:
https://en.wikipedia.org/wiki/Ajax_(programming) These techniques/protocols helped make the Symbian internet experience fast, before other smartphones had many solutions.
>Why should a household or office download windows update files more than once? Seems like a great idea.
I agree with you on that. I also use it to share files and updates on my own network, often when transferring Steam games from one PC to another. I meant for non private networks (like internet cafes) is where I thought there might be a security issue. https://www.tomsguide.com/computing/windows-is-using-your-in... I do not really know whether it's secure enough, but I'm going to leave that to the experts.
I also think they could be useful on internet nodes that are at the end of a network, like an an ad-hoc wifi chain, such as Guifi: https://solar.lowtechmagazine.com/2015/10/how-to-build-a-low...
>IPFS in my limited experience is slow but reliable. Torrents are slow in peer discovery but fast after that.
You have more experience than I do on IPFS, so I will take your word for it.
>Digital signature also.
Did not know that, but I've heard of them.
HTTP isn't the WWW. Back when browsers supported FTP and Gopher, you could deliver the exact same HTML, for the exact same experience, over either protocol.
Core idea from this: we do need something that discourages web page bloat. The last try at this was Google AMP, which didn't go over well with either site operators or users. Any better ideas?
AMP was controversial because it initially prioritized Top Stories cached on Google servers as opposed to other operators, but its nominally open source spec eventually allowed other sites to improve their ad optimize revenue: https://en.wikipedia.org/wiki/Accelerated_Mobile_Pages#Monet...
I think its current issue with AMP is that it makes the web seem flattened, with pages appearing more the same than having more independent formats. I think that if the average page can be smaller than the average AMP standard e.g less than 1.5MB, then a CDN wouldn't need to prioritize AMP.
A friend of mine referenced the 64KB demoscene competitions, which were creative use of video graphics.https://64k-scene.github.io/
250KB Club seems like a nice place to start with websites: https://250kb.club/
To be honest, one thing I've been interested in is a totally markdown-only web. You leave everything the same, you just use a Markweb browser as the only thing and it only accesses text/markdown. Then I build Yet Another Protocol Bridge for my blog and no one visits it ever again. That sounds like fun.
The trouble is, people keep extending Markdown to add HTML features. There's even Javascript embedded in Markdown.[1] You'd just create churn, not a fix.
[1] https://www.markdownlang.com/advanced/javascript.html
There is no "adding HTML features" to Markdown. Markdown is a superset of HTML. You can simply put HTML tags (including script tags) in your Markdown.
If you interpret Markdown that way, all you've done is encapsulate HTML and JavaScript. Nothing gets simpler.
Exactly the problem.
Check out the gemini:// protocal. There are browsers, search engines, and the whole thing is basically markdown.
its a cool idea, but lacks content. Discoverability is kinda bad as well. All fixable problems. I think it could take off given some good content.
Haha that’s what I was joking about. I already have a Gemini bridge at gemini://g.wiki.roshangeorge.dev and I’ve had maybe two days in its history with any visitors. Funny.
Make that three.
<3
You're looking for Moss.
https://mastodon.social/@xmunch/115822364073874855
What protocols does your blog bridge to?
Moss looks great.
I use LaGrange and Kristall, which support multiple protocols.
Maybe take some inspiration from wap?:
https://en.wikipedia.org/wiki/Wireless_Application_Protocol
Although with supercomputers in wrist watches, I'm not sure we need a new standard - html and css works fine across devices - if used with some care?
Yes, I've used WAP on my Nokia phones. I would really like to bring something from the Symbian era, and covered J2ME in a series of posts from the days before: https://inavoyage.blogspot.com/2026/06/how-about-new-java-ba...
Also, https://en.wikipedia.org/wiki/Ajax_(programming)
Adblockers. On a lot of sites a significant portion of the bloat is from third party ads and tracking.
gemini gave it the old college try
[dead]
ANGH as long as marketing people are allowed to control the narrative.
I have the impression that the author does not want to build a parallel internet (which involves whole new protocols replacing, say, IPv4, IPv6, TCP, UDP, ICMPv4, ICMPv6, DNS, perhaps TLS, ...), but rather another application-level protocol replacing HTTP and the web.
Remember that the world wide web is just one of insanely many application-level protocols that can be run over the internet infrastructure.
Correct. The idea is to narrow the application access view from the desktop or home screen of a mobile device to a limited set of optimized apps and protocols that can traverse the web. It's kind of like a dedicated bike lane alongside a boulevard in a major city. One can bike as fast if not faster than cars, but they'd need to adhere to the rules of the bike path.
https://github.com/runvnc/tersenet
I have been working on an alternative to http, and the thinking comes from the same place, thank you for sharing. I still have a way to go, but it's definitely possible, and it is definitely a good idea, I'm very excited about http alternatives in general, we should have many.
https://github.com/mjdave/katipo
thanks for being MITM
Not sure I understand exactly, but I have no desire to host trackers, the idea is that either the client or the host will be hosting their own trackers, or going through some third party trusted tracker hosting service.
So a tracker is what you called a router. Weird name.
Awesome. Starred.
Its always trying to cut bloat. Cant someone have a vision for a better internet that better caters to modern use cases and utilizes modern tech stacks to deliver the best possible experience? I dont see any value in going back to 100kb web pages
A significant amount of the bloat on the modern internet is to facilitate marketing and advertisements, not for the benefit of the user.
I often wonder if we see this downward spiral on sites, because their attempts to monetize increase their costs, which require them to increase monetization efforts, which increase…
If we stripped it back, how much would some of these sites really need to run?
Multimedia is inherently large, but there are a lot of diminishing returns as resolution and size increases.
I agree with this, and think even chip designers are starting to rent transistor parcels to advertisers like NASCAR jacket patches.
But seriously, without anyone addressing the elephant in the room, there is no way to make the web simple as ad less.
The newspapers of the late 19th century did this with color page cartoons. https://en.wikipedia.org/wiki/The_Yellow_Kid
People bought the newspaper for the cartoons rather than the ads, but the ads supported to printing costs. Eventually the competition became so fierce one of the news giants lowered their cost to 1 penny.
Maybe lightweight internet use is a skill that needs to be trained. But with a solid connection for working, I see this less prioritized.
yes and no. I agree there is some amazing things that can be done with larger websites, but one has to wade through a lot of unoptimal sites to find the good ones.
Correct me if im wrong, but arent you trying to introduce a space where its impossible for larger websites to exist thus everything is restricted to the bare minimum website features like its 1999. I do not see the point in that, to me the problem isnt a blog with fancy JS vs a blog with static text. Its about corporations exerting outsized amounts of control over how people interact with the web. I want the new web to solve that problem and also be able to serve 4k video.
You can already do that. If your home page is a fediverse feed or client, the users provide the content without an algorithm. Many people who have a browser with a Google search bar might think corporations control a lot, but one can set a different browser, DNS, and search engine. The thing Steve Jobs did was simplify the out of the box experience, so when they bought a Mac, there'd only be a dock with Safari at the bottom. One could develop an open source machine with a very unitary goal of accessing a lightweight web using a protocol or extension similar to No script but the average non-technical user might not know how to do that.
Of the many Linux distros I've tested, maybe a handful are actually easy to use and not heavy. One example is Bodhi Linux. But I have something more like Tiny Core Linux in mind, except polished (it features a dock, surprisingly). If the hardware could be developed for this too as open hardware, there would be the added advantage of it having more ways to improve it. I'm a bit oxymoronic in having a vertically integrated product idea and an open source bias, but a lot of great ideas need a coherent outline, which sometimes start out as closed source.
If the project starts out with enthusiasm but it gets forked, then it becomes impossible to develop one feature that many people didn't realize would be overall a better user experience, or streamlined option, at the very least.
So Internet2, but with less research?
https://internet2.edu/network/
Personally, I think Reticulum is the parallel Internet. It could even replace the Internet Protocol, and whatever the IP protocol connects is in my view the Internet.
there's also the network effect to deal with. The Internet is a WAN of WANs. you might have a great parallel Meshtastic network, but if few people are using it, its range might be limited.
what about going in the other direction? apps instead of sites. wasm for everything, shared immutable libraries, strict capability based security. client side rendering where you can choose between html+css, new binary formats or doing everything from code. easy server overrides so you can redirect all requests from bigtech.com to service.mydomain.net without the app ever knowing. encourage federation and sharing instead of isolation (but thats more of a culture problem new tech cant really solve). put the user back in control.
This seems like the natural direction for me.
I feel like I missed where exactly the parallel part splits. Do they want to make new wires? New fibre protocols? A new TCP/IP stack? Just make another Gopher/Gemini?
It's more like a virtual network alongside the actual one, with a dedicated bike path separated by a curb and a sidewalk.
At least it's not the IPv8 guy again.
Can you pay for The Thinnernet with Thnickels? https://thick-coins.net
The coordination and discipline required to build it is quite simply not there (or here, or anywhere). We will sooner have multi-gigabit space internet or 7G.
https://reticulum.network/
Agree with many of your points (especially on how Steve jobs would have obsessed on this topic), but how do you think it reaches the masses?
Through a series of tubes.
by train. The internet train. :)
That would be high bandwidth and high latency, which might be the opposite of what's being proposed in the article. (It's difficult to be certain what's being proposed in the article. I'm fairly sure the article is about internet, beyond that point all is guesswork.)
I wrote a number of articles that try to address the many stacks of the application, transport, and OS layers. The best platform I can think of are the mid 2000's Symbian S60 phones, which were Real Time Operating Systems and used J2ME: https://inavoyage.blogspot.com/2026/06/how-about-new-java-ba...
There are new Java'based platforms that could build upon that, but chips today have so much processing power that they might think it's easier to develop a higher level language with more dependencies. But that leads to more maintenance if some package gets lost or broken.
As for the internet speeds themselves, It is similar to net neutrality but a voluntary guideline by the website developers: https://inavoyage.blogspot.com/2026/06/the-sierpinski-triang...
I also explore QUIC, but it's already implemented and not everything needs it, except higher bandwidth: https://inavoyage.blogspot.com/2026/06/5-things-to-lighten-d...
Once Android and iOS became the leading smartphone makers, code efficiency wasn't super important, because they hardware makers could add 10-20X the RAM. The competition between Symbian and iOS was a brief decade, but it actually made efficient code development interesting and beneficial for battery life. Since RAM got cheaper, even though it's expensive at the high end (HBM3e), it's a lot easier to develop with 4GB of phone memory than 4MB on the Nokia 7650 (2002). Those are quite extremes, but most symbian phones had a lot of features with as little as 32MB of RAM. https://en.wikipedia.org/wiki/Nokia_7650
I'm waiting at the station. Tell me when you arrive.
> There is a funny email that had been released after before Jobs's passing where a user complained of a spotty signal, and his advice was basically to not hold the phone in that direction (or with his hand over the top part where the antenna was positioned).
Is this a reference to “antennagate”[0], when Jobs dismissed an affected user telling them to “just avoid holding it that way”[1]?
> because 3G technology at the time wasn't robust, and one shouldn't have expected him to have all the solutions that were out of his control
If so, this is an incredibly bad take. Lots of other phones had implemented good 3G connectivity at the time, including Apple's own prior iPhone. Apple made a mistake here, and the takeaway should be that corporate hubris is real and companies aren't your friends, not some cockamamie prattle about how we should accept bad products because technology is hard, boo hoo.
> had Jobs lived to 70 or 80
Jobs' own death is another fine demonstration of his arrogance. Very ironic to refer to it in this paragraph.
0: https://en.wikipedia.org/wiki/IPhone_4#Antenna
1: https://www.macrumors.com/2010/06/24/steve-jobs-describes-ip...
Yes, I now realize it was the antennagate story. I included a link to a Slate article that featured an even more unsympathetic writer, which was in 2010, a year before Jobs died.
In retrospect, I think Jobs knew his time was limited, and telling a customer not to hold it that way wasn't an unforgiveable sin- in fact, there was some truth to it, even if they didn't have a better modem at the time (my article mentions Qualcomm).
And I agree, that yes, hubris is real. I like how Bill Gates told Jobs at the D7 Conference in 2007 that his charisma and spell wouldn't work on him because he was a minor wizard. https://www.businessinsider.com/bill-gates-says-steve-jobs-w...
Btw, an in-house modem is something Apple us finally returning to, now that they are ready: https://www.forbes.com/sites/davidphelan/2026/05/16/iphone-1...
God hn has so many projects that never go anywhere
...may I suggest "Intelligent Software-Defined Network" as an acronym for the sake of giving it one
I haven't heard of that, but thanks. I have heard of Software Defined Hardware- I guess Networks are a type of hardware (SDH).
I mean, a slow, deterministic, latency focused network standards sounds a lot like ISDN and ATM(Asynchronous Transfer Mode) standards... there were such lost competitors to Ethernet, HTTP, HTML, etc.
Why not use those extra fiber optic cables as part of the actual internet? You can immediately start making money off of it due to people getting legitimate value from it. If other lines were to be cut or have issues your lines would act as a backup. And yes if things got overloaded it would act slower. It seems unoptimal to make a completely separate network.
I don’t understand the vision in the blog post, but I’m very excited to try out the Arcan-net as described in http://www.divergent-desktop.org/blog/2026/01/26/a12web/
https://imgs.xkcd.com/comics/standards.pngs
That page does not load for me, did you mean https://imgs.xkcd.com/comics/standards.png or https://xkcd.com/927/
yup, https://imgs.xkcd.com/comics/standards.png... Guess I need to update my Alfred Snippet macro for !!standards.
my challenge for the past 6 years has been trying to prove XKCD's conventional comic panel on that wrong :)
Have you considered making your own comic that every can reference for this... wait.. nevermind.
I have made comics before. Maybe I should again.
I tune out at this "what Steve Jobs would have done" talk. A thing needs to stand on its own without borrowing Steve Jobs (or Jeff Dean as I saw someone do the other day).
Pretty much, we don't know what Steve would have done and even if we did, there is no guarantee that it was a good idea. When he had hits, it was brilliant but there were many stinkers as well.
I suspect if Steve was doing a new internet it would be a walled garden like the App store, so a worse internet that favors him. As Woz said, Jobs just wanted to have a business and be rich, didn't really matter what the business was. Any illusion of a greater good was always a calculated bet in getting more users.
Job's did some great things for the industry, I also call him the architect of the locked down digital jails we are inhabiting. But we shouldn't put him up as some perfect beacon of the industry.
I get that, but a lot of design decisions today are https://en.wikipedia.org/wiki/Design_by_committee
For something so complex like a PC or desktop experience, having a bunch of oppositional goals (like ad pop ups) do not serve the user well enough. Often times a committee releases a product, but there is no real consensus or accessibility in mind.
That sounds like a false dichotomy. You want opinionated software? Great, so do I. Design the software, own your decisions yourself, and explain your thinking without shortcuts.
Also, steve jobs made utterly stupid decisions in a lot of areas. If you're trying to revolutionize something, try not to use someone who was clearly flawed in many aspects. Otherwise it sounds like you're just building a facade.
Yes, and Seward also made a Folly. I suppose he missed out on some things, but his success rate at predicting features that are now standard was higher than most in that era.
Yeah, reading his biography was interesting. He had the problem of tech not quite being where he wanted it to be over and over. But eventually things really hit.
I mean can't get a more incestous tech cliche! There is a world out there too folks.
The VC Approved™ Software Validation Lifecycle:
You're listening to WWSJD, the Los Altos FM station where Apple pilgrims tune in to the station that Steve Jobs did!
[flagged]