Haiku impressed me so much that even when I'm unlikely to use it as an user (mostly because I have already usable setup that I like), I've found it very good and polished. So I've decided that all my software will get 1st class support for Haiku :)
I remember as a teenager wondering why lynx felt so slow, so I looked into the source code and discovered it was literally calling sleep() while displaying status messages, so I commented that out and made my internet experience Blazingly Fast
That sure brings some memories. They were calling sleep() so you would have time to read the messages in the status bar at the bottom of the screen. Back in 1995 or so I submitted patches changing the browser's inner loop to be select() based, with a queue of messages to show for a few seconds each without slowing down browsing. It took one night of hacking, and the maintainers rejected the approach as "too complicated".
oh I just looked into it again for fun and noticed that indeed it defaults to sleeping at least 2 seconds every time you open a URL but this can be changed in lynx.cfg by altering these defaults:
That and developers often conflate knowing how to construct UIs with how to design UIs. When lynx was first built, the difference in speed probably wasn’t that noticeable and people didn’t have the same expectations for responsiveness, so it didn’t matter, though times quickly changed.
I don’t know about that project specifically, but based on my experience trying to do design work in developer-controlled projects, maintainers and core users often convince themselves that some terrible user-hostile counter-intuitive UI— focused on graphically representing the API to the back end rather than using abstractions to solve the problems users actually want to solve— is the proper UI approach and if it doesn’t fit your use case, the problem is either you or your use case.
What about dynamic websites? For example, a platform-independent chat app.
Javascript has a place, although that place would be better filled by another language. PHP... yes, PHP can be completely replaced by other server side frameworks.
An exact example of the kind of thing I'd like to get rid of.
The UK PC vendor Elonex had the first ever webmail system I saw, called HTMail. It was impressive but it was a private in-house tool to give remote workers email access without needing their own machine with an email client. Wrong sales model.
It the was followed by the indie HoTMaiL, based on NetBSD servers I think, which had the right model: a free public standalone service, paid for with ads. Of course MS bought it and ruined it.
Webmail doesn't need Javascript and worked with pre-JS browsers and servers.
> For example, a platform-independent chat app.
Good. Let's eliminate them, too. They are bloated slow things that allow companies to hijack their own commercial clients' data.
Stick to standard protocols, extend them if necessary -- XMPP 2, Matrix, whatever -- and document and publish the protocols. Make it possible for 3rd party client apps to connect. Pidgin was great and it takes about 1% of the RAM of a bare handful of these crappy Electron efforts like Slack.
What you are citing as reasons to keep it are the reasons I want to see it dead.
These things don't have to be bloated. For example, I wrote a web chat once, called minchat (minimal chat) [0]. The frontend is written in plain HTML, CSS and JS, totalling ~5kb. The backend is written in Rust.
There is room for programs that do not need to be installed. Examples are Flash, Java applets, and Javascript. Personally, I think some sort of UI thing based on WASM might be the way to go, but that's just my opinion. Can you think of any other way to run programs from the internet without installing them? Yes, SSH, telnet, remote access, remote X11, but with all of them, the programs are running on a different computer, whereas with web apps, they're running on your own computer, without costing them money, other than hosting costs.
I never thought I'd be speaking for web apps, but I guess I'm not, not really. What I'm saying, is there is a niche, and that is currently filled by web apps.
It was about Lisp, so it’s an ancient thing now, but it still has truth.
As far as the Unix/Linux/xBSD world goes, it can be generalised like this:
Level 1: Any sufficiently complicated [container or VM management system] contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Plan 9.
Level 2: Any sufficiently complicated [bytecode VM or runtime environment] contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Inferno.
Wasm to me still smells very much like a second-hand, poorly-conceived, half-assed version of Dis.
> There is room for programs that do not need to be installed.
Sure there is room. But is this a desirable thing? Is it worth the price in inefficiency and insecurity?
If it is, and I am not 100% convinced of that, then design it right into the OS from the outset. Any effort to bolt it on later will be fatally flawed.
I have a lilygo T-Deck, I use it for writing in bed with a custom text editor [0]. It has a surprisingly great typing experience, and I can get up to a decent speed. Typing can be good on handheld devices.
