I think distinguishing between client-side and server-side speed matters. Python and Ruby are fast enough, and as you say you can scale them horizontally for a long time before it gets cheaper to optimize or rewrite in another language.

But if a UI is slow, that does matter. Delayed keypresses, unacknowledged but registered interactions, or the worst, delayed layout changes, are completely flow breaking.

Yes. And the resulting churn and dissatisfaction is mostly invisible, unless you go looking for it. Most users don't even file bug reports when things are actually broken. Most users can't tell why they don't like something when it just runs slowly. Even technical users will almost never file bug reports against slow and janky performance.

I hate Jira - but I think the main reason is just that it feels slow to use. A slow UI gives a visceral felt sense of lethargy / sickness, which I associate with the product. Is that a bug? I don't know. But I bet it runs fast enough internally at atlassian. And I suspect the PMs at atlassian tell themselves the same story - that its not worth the development time to make it fast. And that might match with the feedback they get, because all the users who care about that have probably already bounced to other products.

Jira is bad for a completely different reason. Jira is bad because Atlassian has grown from a company that sold software to its users, to a company that sells software to people who work in corporate procurement. Atlassian only has to impress two people to make a sale now. The person box ticking the features, and the person who wants to see the reports that it produces, and neither of those people are the ones who actually use the software.

I worked at a company where they used a time tracking application (most of their revenue was T+M) which was so bad that one of the developers reverse engineered the front end API and built a new front end for it.

What you said about impressing the person viewing the reports really rings true in that case.

I think my rationale applies to client side code too, just in a slightly different way. It is so easy to write performant browser UIs these days, and a lot of that is down to these same sorts of hardware improvements (as well as V8 improvements). Even bloated web app front ends will perform very well most of the time. You can take that to the extreme of course, but you really have to go out of your way to do it.

I’ve built frontends before without giving any consideration at all to performance, and they’ve always performed perfectly well. Websites like cnn.com exist, so it is demonstrably possibly to do it badly, but you have to stray so far from the light accomplish something like that.

> people don’t want to use their improvements to improve speed

I don't agree. It's only software developers that think that way with their latest gadgets, fast internet at high tech buildings; not the users.

Users tend not to think about these sort of trade offs at all. Users will also complain about not having the features they want just as readily as they will complain about something being slow.

But that’s really besides the point. As long as an application is fast enough that a user doesn’t notice a problem with it, then you’re done optimizing for performance (in most cases at least). So if new hardware comes out that’s twice as fast, you could very sensibly keep the performance at the same acceptable level, and use the new performance budget in other ways. Such as by introducing various inefficiencies via abstractions that make feature development faster.

The issue is that not all users can buy that new hardware that’s twice as fast.

This is just a further misunderstanding of the market. People optimize for who their customers are. Knowing what devices your code runs on is trivially easy, and so is measuring its performance against them. People aren’t going to instantaneously make their code 20x slower just because the new Apple chip is so good. But they’re also not going to optimize for that old Samsung phone that represent 0.0003% of their user base.

You're really projecting if you think normal people give a crap about expensive abstractions or even speed of development.

Most of those "abstractions" and "development" are working against the user anyway: most webpages have not added features in more than 20 years but still require more power because developers can't get their shit together.

Speed is the reason people bought SSDs. It's the whole core of Apple's M1 Marketing. It's probably the biggest reason why people buy new computers. Lack of speed is the reason I had to throw away my Smart TV after 8 years of useless upgrades.

People pay more for faster internet because they want more movies in bigger quality or to download big things faster. Not because they give a crap about your shitty app.

> Unless you have a performance issue that’s really pathological, speed really doesn’t matter for most applications

And that's only true because developers are constantly forcing hardware developers and customers to throw money at the problem.

Yes. I would assume that the only metrics that count for CPU engineers are performance, power consumption and cost. Features are not a relevant metric. What was the last CPU feature that was not added to improve performance? Virtualization support?

Security mitigations for side channel attacks?