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.
@thomasbeagle @EricLawton the end user experience was pretty good, but waiting for the turn around of batch compilations of the cobol and the delivery of the printed listing of the cobol program with it's missing full stop errors were a bit of a chore sometimes. :)
Fixing the errors using a terminal rather than replacing punch cards was a huge step forward!
@Glodav @EricLawton Thankfully we were a bit more modern than that! (Although my dad was a Cobol programmer in those days).
But our developers loved it when I deployed Windows PCs for workstations so that they could finally have multiple terminal sessions without relying on screen.
@thomasbeagle @EricLawton I feel privileged to have been exposed to the early days of it all, and the gradual changes have have been exciting to see. Sometimes I feel like a frog in a pan of water on the stove, and I should have jumped out a while ago.
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 9, 2026, 4:57 AM@thomasbeagle Ahh, definitely system performance. I'm 100% ok with asparagus on pretty much anything.
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 I’ve done two at both ends of my career and blame them for my hairline ;)
@thomasbeagle @Seedoubleya I’m so old I can tell you when a company migrates to a new ERP just by looking at a handful of KPIs. If it’s a real dent, they’re moving to SAP 😆🤣
@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.
@becomethewaifu @thomasbeagle A pet hate: transport ticket machines that take *minutes* to issue a ticket, and only after you have navigated a mythically awful menu system.
Old London transport ones were awesome: select and pay (or vice versa!) and print and receive change, all in under 5 seconds.
That such performance is not standard in all acceptance specs says a lot.
@Synchro @becomethewaifu I like our local parking meters. You have to press the Start button on the touchscreen and then it takes 10 seconds to go to the next screen which simply asks what language you want. What is it even doing in that 10 seconds?
@thomasbeagle @Synchro @becomethewaifu probably an energy saving measure,since use is very intermittent. It's booting itself up.
@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.
Oct 8, 2026, 10:44 AM@thomasbeagle progress!
@thomasbeagle agreed. lately I've gotten back into BBSes and using ssh-based TUIs and the speed and visual S/N ratio has been a joyous balm and escape from the madness and shitshow that is the modern web and socmedia
if you worked in the Canada Revenue Agency in the early 00's or earlier, you would have had to put up with waiting and not being able to do any other work. all Canadian government agencies are still using the same COBOL mainframe system today, but with PCs running a TN3720 program on a Windows desktop to access it instead of a dedicated data terminal.
@thomasbeagle Long way back when I visited the university: https://www.nngroup.com/articles/response-times-3-important-limits/ . My iPad1 is still faster and more responsive than my newest one today. Why? Steve Jobs in his days was very keen for the 100ms rule and demand that they obey that when doing ux. We lost that in the feature fire later.
@thomasbeagle Most of modern tech signals 'your time is important', but in practice delivers the opposite.
Oct 9, 2026, 6:56 AM@thomasbeagle @cm Totally agree. Heck, we worked with a handful of people on one MicroVAX and VT220 terminals!
But it isn't just the web applications, it is the local applications, too. I am looking primarily at the programs starting with the letters “M" and “S”, but those are not the only ones. And that is on a computer with a CPU that literally has multiple billions of transistors and enough RAM and disk that it alone could have been a data center in the MicroVAX times.
Oct 9, 2026, 7:45 AM@thomasbeagle
in the early 2000s Jacob Nielsen wrote in his AlertBox https://web.archive.org/web/20031008100650/http://www.useit.com/alertbox/ about turnaround times, that programs should respond in 1/10 sec and web may be slower (like: a second).
Blessed times of #slow #internet that were!
Also https://idlewords.com/talks/website_obesity.htm comes to mind.
@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.
When I was at VUW the 10MHz (it was somehow overclocked from 5MHz without paying the required premium) Burroughs B6700 machine with 2Mbytes of RAM supported 120-odd terminals.
The shortage of RS-232C ports on the mainframe was solved by building "Concentrators" based on MC6800 hardware by Peter Williams, feeding them X.25 through a serial port, and connecting many terminals to them.
@thomasbeagle @markmetz My first IT job we had SCO Xenix on a 286SX-25 with 4 terminals. Soon upgraded to a 486DX-66 with 8 terminals. Also running a COBOL based application
@thomasbeagle It’s encouraging reading all these comments from people who were around when things were different. That means there’s still hope.
The day there’s nobody left to say how much faster things used to be with fewer resources is the day I worry about. Until then, don’t put up with bad code.
Tip for AI coders: include this when vibing a web application: “Use modern browser APIs. Do not use any frameworks or external dependencies. Code like John Carmack.”
That alone will help a lot.
@thomasbeagle
On the backend things are immeasurably more complex with app load balancers feeding dynamic clusters of ephemeral servers and databases, growing automatically as if tireless angels were racking servers on the tip of a pin.
@GarretSidzaka Plus it's just abstraction layers all the way down.
@thomasbeagle
Technically, but those layers are also where delicately we weave our gossamer states, with our code.
I guess the system was fine tuned to the tiniest bit.
Nowadays computer power is high, network speeds as well. If I see how much RAM an Email or Chat Programme from a well known Company eats. ... or how many megabytes a simple webpage sends to load ... No need to tune your code?!
Just recall that I needed to setup my private PC in the end 90s anyway and out of curiosity installed Windows 3.1 - which was so blitzed fast, that I was seriously amazed.