I'm building a parallel internet, and it's called The Thinnernet

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

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.

You fail criterion four: you're limiting what kinds of documents and applications can be developed.

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.

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.

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

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.

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.

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.

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.

Moss looks great.

I use LaGrange and Kristall, which support multiple protocols.

Also, https://en.wikipedia.org/wiki/Ajax_(programming)

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 a tracker is what you called a router. Weird name.

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

You're listening to WWSJD, the Los Altos FM station where Apple pilgrims tune in to the station that Steve Jobs did!