> An extra hundred milliseconds of lag in the UI gets attributed to the slowness of the connection.

This is looking at the problem wrong.

I notice your shittily optimised application not just because it’s slow, but because it’s draining the battery.

This is a problem, and developers need to wake up to it. Crappy performance uses more energy because the machine is doing unnecessary work to an end that could be achieved more efficiently, often much more efficiently.

So, please, invest time in performance.

Alternate take: in a world where our entire society is trying to reduce energy usage, to minimize emissions, and so on, it strikes me as insanity that we do not demand every ounce of performance out of the hardware that we have, and equivalently, aim to minimize unnecessary demands on the hardware at the same time.

Burning up a laptop CPU and torching racks of servers and routers in some data center just because the web is full of shitty ui frameworks should be intolerable to consumers and providers. Efficiency really needs to be a goal of all system designers.

What UI framework do you like to use?

On the other hand, in a world of slightly non-responsive software, something that does respond instantly has a subconscious psychological impact on us and builds affinity.

Indeed.

I cover this in "Your Database Skills Are Not 'Good to Have'": https://renegadeotter.com/2023/11/12/your-database-skills-ar...

Specifically when I cite THIS: https://designingforperformance.com/performance-is-ux/

> Imagine if SELECT field1, field2 FROM my_table was faster than SELECT field2, field1 FROM my_table.

possibly it might not be smart enough to reorder an index on (field1, field2), or it had some weird internal constraint on tuple ordering, or it was simply different enough to go down a different query plan sometimes, or maybe there’s something around the actual physical ordering on disk?

but yeah postgres and SQLite are modern marvels that we take for granted… myISAM was not a good time, or at least people tended to violate the correctness/visibility rules it promised (iirc) or something like that. The fact that you can just open up a stable, well-tested sql instance that runs against disk, or drop Postgres into most transactional use-cases, and generally not have to worry about unduly fighting the DB itself, is underappreciated.