Hacker News Reader

It is a valuable and relevant lesson - when something wide and structural manifests (personal computing, the internet, smartphones, AI), lots of people will be able to see the coming future with high fidelity, but will tend to underestimate the speed of change. Because we gloss over all the many, many small challenges to get from point A to B.

Yes, now it feels like something like smartphones came of age overnight and was always inevitable. But it really took more than a decade to reach the level of integration and polish that we now take for granted. UI on phone apps was terrible, speeds were terrible, screens resolutions were terrible, processing was minimal, battery didn't last, roaming charges/3g coverage, etc. For years, you couldn't pinch to zoom on an iPhone, stuff like that.

All these structural problems were rubbed away over time and eventually forgotten. But so many of these small tweaks needed to take place before we could "fill in the blanks" and reach the level of ubiquity for something like an Uber driver using their phone for directions.

UI on phone apps still is terrible. Have you ever used a desktop with high-end gaming peripherals (fast monitor/keyboard/mouse), running a light desktop environment such as LXQt on Xorg, with animations disabled? The feeling of responsiveness leaves all mobile devices in the dust. Any modern CPU+SSD is fast enough, but good peripherals are still rare and make a huge difference. Most phones are still running 60Hz displays. A touchscreen is inherently clumsy compared to mouse+keyboard. Mobile UI feel is worse than desktop computers from the 90s.

"have you ever done this indescribably niche thing, which I believe renders your argument null and void, but is in fact not relatable in the slightest?"

Good UI latency used to be standard:

https://danluu.com/input-lag/

(most recent HN discussion: https://news.ycombinator.com/item?id=33683278 )

The fact that it requires niche hardware and software (not "indescribably" niche) to achieve in modern times is a failure of the computer industry, not a problem with my argument. Low standards do not make mobile devices good.

And touch screen are impossible to fix even with niche configurations. I have no way to shrink my fingers to pixel size, and no way to make them transparent.

> (And because people forget, it is not too far off to say that would be like trying to deliver the internet of 2020 on machines with specs comparable to a Nintendo Wii. I'm trying to pick a game console as a sort of touchpoint, and there probably isn't a perfect comparison, but based on the machines I had in 2000 the specs are roughly inline with a Wii, at least by the numbers. Though the Wii would have murdered my 2000-era laptop on graphics.)

It depresses me to think how much of the 2020 Internet (or 2025 Internet) that is actually of value really ought to be able to run on hardware that old.

Or so I imagine, anyway. I wonder if anyone's tried to benchmark simple CSS transitions and SVG rendering on ancient CPUs.

Also in the amount of data.

Ever remember waiting something like hour to watch a 60-second movie preview over dialup?

I get a reminder every time I load a modern website in an area with very poor reception. Appears to not load at all —- not due to lack of connectivity but rather due the speeds and latencies being too slow for the amount of crap being fetched.

GPRS and EDGE were many times faster than dialup — must have been a dream — but now utterly unusable.

That is indeed one of the differences I had in mind.

The sad part of it is, pretty much everything on that modern website that makes it too fat to load is completely unnecessary. You can create a beautiful, full featured page that's only a few kbytes.

> And because people forget, it is not too far off to say that would be like trying to deliver the internet of 2020 on machines with specs comparable to a Nintendo Wii.

I mean, we could totally have done that. There's nothing stopping you from delivering an experience like modern Amazon or Facebook or whatever in server-rendered HTML4. CSS3 and React get you fancy graphics and animations, and fast, no-repaint page transitions, but that's pretty much all they get you; we had everything else 25 years ago in MSIE6.

You could have built a dynamically-computed product listing grid + shopping cart, or a dynamically-computed network-propagated news feed with multimedia post types + attached comment threads (save for video, which would have been impractical back then), on top of Perl CGI-bin scripts — or if you liked, a custom Apache module in C.

And, in fact, some people did! There existed web services even in 1998 that did [various fragments of] these things! Most of them built in ASP or ColdFusion, mind you, and so limited to a very specific stack; but still, it was happening!

It was just that the results were all incredibly jank, with no UX polish... but not because UX polish would have been impossible with the tools available at the time. (As I said, HTML4 was quite capable!)

Rather, it was because all the professional HCI people were still mostly focused on native apps (with the few rare corporate UX vanguards "doing web stuff", working on siloed enterprise products like the MSDN docs); while the new and growing body of art-school "web design" types were all instead being trained mainly on the application of vertically-integrated design tools (ActiveX, Flash, maybe web layout via Photoshop 9-way slice export).

I agree with most of this post, except the part where you could actually do it. I’ll be the first to admit that I was not in server rooms back then but I’ve heard from those who were. The biggest advantage Amazon had, for many years, over their competitors, is that they would take your order and tell you it was completed and wait to charge your card until it shipped because it was cheaper to write your order down than to spend expensive session compute waiting for the payment to go through. That kind of optimization was necessary because all the networks were slower or flaky then, including payment processing, and often relied on batch processing overnight that has become less visible today.

Meanwhile on the client side, web technologies had a lot of implicit defaults assuming pages on sites rather than apps and experiences. For example, we didn’t originally have a way for JS to preserve back/forward buttons functionality when navigating in a SPA without using hash tags in the URL. Without CSS features for it, support for RTL and LTR on the same website was basically nonexistent. I won’t even get started on charset, poorer support for dates that persists to this day, limited offline modes in a time when being offline was more common, and how browsers varied tremendously across platforms and versions back then with their own unique set of JS APIs and unique ideas of how to render webpages.

It took the original acid test and a bunch more tests that followed before we had anything close to cross browser standards for newer web features. I still remember the snowman hack to get IE to submit forms with UTF-8 encoding, and that wasn’t as bad as quirks mode or IE 5.

Actually maybe I disagree with most of this post. Don’t get me wrong, I can see how it could have been done, but it’s reductive to the extreme to say the only reason web services were jank is because UX polish didn’t exist. If anything, the web is the reason UX is so good today - apps and desktop platforms continuously copied the web for the past 28 years, from Windows ME with single-click everywhere to Spotify and other electron apps invading the OS. I’m not going to devalue the HIG or equivalent, but desktop apps tended to evolve slowly, with each new OS release, while web apps evolved quickly, with each new website needing to write its own cross platform conventions and thus needing its own design language.