Many years ago I used to work on a Cobol-based application that ran over an 80x25 green screen terminal. People running 30 or 40 users on a 486 PC running SCO Unix hooked up to a multi-port serial card.
We'd never have tolerated the amount of waiting between actions or screens that is now considered absolutely normal on web-based cloud-hosted applications.
Weird how things change.
When I first started teaching IT architecture, we had an exercise on designing streaming video to cinemas.
With available infrastructure, it would have to be streamed once the week before because not enough reliable bandwidth to do it live for each performance.
Now we do it live to individuals,.
@EricLawton Oh for sure, and we're sold hard on the amazing things we can do now. My phone can record 4k video at 60fps! I can play beautiful 3D games! LLMs will harness the power of an infinite number of monkeys on my behalf!
Which is why I find it interesting that against all this "amazing! cool!" the actul experience of using computers to get boring things done has often got so much worse.
@thomasbeagle @EricLawton it takes my Mac so long to make a new folder I have to *wait* before I start typing a name for it
@EricLawton @bentorkington @thomasbeagle A loooong time ago, when I was working in a 3270-heavy environment, we would initiate new analysts by making requests for offline datasets.
The catalog had a rough correlation (by dataset srcid) to the physical location in the tape library ("TapeLand" we called it). The game was to make a request for the tape located furthest from the operator console. As you asked for the tape, an alert showed up on the console and the analyst would have to race off into TapeLand to get the tape, bring it back to the tape drives, get it threaded and read into a mounted dataset.
Leaderboard was reported surreptitiously on a separate TSO panel we wrote specially for the purpose.
Furthest tape won. Good times!
@EricLawton @bentorkington @thomasbeagle
Those were the days. We didn't know how good we had it.
Oct 7, 2026, 10:28 PM@thomasbeagle I couldn't agree more. Can't figure out whether to be more disgusted or depressed by it all.
@sidawson This is great, now I need to work out whether you were replying to my system performance post or the aspargus on pizza post. :)
Oct 8, 2026, 4:21 AM@thomasbeagle @sidawson it ain't a pizza without tomato and cheese. So there's no pizza to be disgusted by, just a large toastie! Mmm pizza, maybe time to break my vegan vows for one meal...
Oct 8, 2026, 1:04 AM@thomasbeagle sometimes I'll visit a website I made years ago and get jump-scared by how responsive something on the internet can be if it's not intentionally made badly
@ben That's pretty quick.
Yesterday I was using a web-based search and I thought it was broken because I applied a filter and it happened too fast for me to notice. 😄
@thomasbeagle you remind me of my reluctant involvement in a recent migration from ugly green screen ERP system to mumble something Microsoft. I’m not sure how the company survived the productivity loss. The project nearly killed me and of course those that pushed through the decision on product choice long gone and only the chaos remains.
@Seedoubleya ERP migrations are near death experiences no matter what the platforms or technologies involved!
@thomasbeagle Speaking as someone that occasionally still interacts with one such green-screen application occasionally, and its lightning-fast responses, it's genuinely disturbing how nobody seems to give even the slightest shit about response-time optimization in "modern" apps these days...
(Hell, that lack of care has even infected transit cards... Y'know, the thing that kinda needs to be fast to avoid the gate lines becoming a tangled mass of humans? The older ones here can be tapped in about 200-400ms, usually fast enough to hit it at walking pace without slowing down. The new ones? Take upwards of an entire second to even acknowledge the card. And that's one of the less bad complete UX failures in the system...)
In the 90s and early 00s I'd read articles on the industry where they were doing all they could to speed up boot times, web page loads, and all the rest.
Now I visit a webpage and 8 to 12 seconds will unfold with elements on the screen buffering while security protocols are checked, computing power from my CPU is accessed, roustabouts take an early lunch lounging all over the memory chips, deranged chimps crank furiously to speed up my cooling fan, and men in trench coats take a peak into my hard drive.
Oct 10, 2026, 9:17 AM@Stuck_Here @becomethewaifu @thomasbeagle
I remember a study by Google where they found the bounce rate significantly increased if a page took over something like 200 ms to load. People were worried about adding TLS adding a couple of extra network round trips to the network would get into this window.
Now, a load of popular sites load more slowly than their equivalents did back when I used a 26.4 Kb/s MODEM (fastest speed it would normally connect at the very end of a rural phone line).
There are too many layers of abstraction and almost nobody has any understanding of the hardware or operating system basics so they can't optimise stuff effectively.
Oct 10, 2026, 9:33 AM@zl2tod @becomethewaifu @thomasbeagle
I don’t like to blame abstraction because good abstractions are crucial to building performant systems. No one can have in-depth knowledge of how to optimise every layer in the stack.
The problem is that many of the abstraction layers are built either for a set of requirements that no longer exist or with no reference to the needs of the layers above.
To take a trivial example:
OpenStep (1994, later rebranded as Cocoa by Apple) has an incredibly rich view class for editing text. It gives you a zero-effort way of providing a plain or rich-text editing functionality but also gives you hooks to plug into any aspect of the layout pipeline. You can precisely control kerning, define the shapes that text will wrap into, replace the hyphenation algorithm with one of your own, and so on. It integrates with the native scroll view, so it’s easy to render large amounts of editable text that exceed the size of the screen. 90% of uses just pick the default. 99% are handled by just setting attributes on ranges in the text that users provide. The remaining 1% use the fine-grained control. This means that basically every native Mac app gets to reuse the same code. It spent a couple of decades getting optimisations and rich text editing is smooth and consistent across all Mac apps that don’t use Electron.
Now contrast this with web apps. The web provides a native plain text editing box that gives almost no control over the contents. It provides a rendering tree for things in the DOM that you can control. But if you want to create an editing view for rich text (especially if you want it to have custom semantics), you don’t have a good common abstraction. So everyone implements their own, using bits of JavaScript that go and produce terrifyingly layered things in the DOM. And this is much slower than a native rich text view on macOS.
Oct 8, 2026, 6:25 AM@thomasbeagle I was working at a mortgage lender when they switched over from a proprietary ui running on os/2 warp(!!)(this was in 2003(?)) to an enterprise web application for processing mortgages.
it was a disaster - the number of mortgages that could be processed for each "stage" of the mortgage went from only being limited by how fast you could collect and enter data to maybe … two? per day?
the workflow went from entering data into a series of screens that were designed to flow from one section to another, to kind of modifying a holistic entity by clicking around to different sections. so you would click a section link, wait 10-30 seconds for it to load (or fail!), click a subsection link, wait, click a final link, wait, enter one or two fields, go back to the top, drill down into a different section, check a box, until everything was complete, several hours later. sometimes things would invisibly fail, and something would get corrupted on the backend, and nothing would work until somebody with Privileges would have to log into the old system and fix it. they were still using this system when I left.
@thomasbeagle latency was surely much shorter in old computers
Oct 10, 2026, 9:37 AMThe round trip time from me to the nearest Azure datacenter is around 10ms. This is fast enough that I can run a game on an Xbox that is running there and stream back the result. Every button press or other controller interaction goes via Bluetooth to a local machine, is encrypted, sent TLS encrypted to the datacentre, decrypted, processed on the target Xbox, then a frame is rendered, compressed (as video, with unidirectional interframe compression), encrypted, sent out over the network, decrypted at my end, sent over HDMI, and displayed. And this happens with low enough latency that I don’t notice that the game is not local.
The new computers are not the problem.
@david_chisnall @thomasbeagle that is true, too. Some programs do suffer from latency.
I worked on a multiuser ~PICK-adjacent~ Qantel office system running on an 8085 and it was ok. Early 90's running Informix4GL, also on a 486, Xenix, was good as well. We supported lab records for two locations.
I reworked an AI application this year and beat it for speed by 2 million times.
Kids these days, right?
Every once in a while I fire up one of my old computers thinking it's going to be super slow and weird and I always find them totally usable and not much different for everyday tasks.
@thomasbeagle Most of modern tech signals 'your time is important', but in practice delivers the opposite.
@thomasbeagle i worked on similar systems (not COBOL). we were told that if a screen hung for two seconds, there had better be a bloody good excuse; if it hung for four, you'd have to rewrite so it didn't.