I mostly agree with you on this but JIRA tends to push the envelope in terms of unresponsiveness of its UX. As an IC I only really use it to create/update/search tickets but I find myself waiting a half to couple of seconds for certain flows, especially for finding old tickets.

Not quite the same as responsiveness but editing text fields in JIRA have a tendency of not saving in progress work if you accidentally escape out. Also hyperlinking between the visual and text mode is pretty annoying since you can easily forget which mode you’re in.

Honestly as I type these out there are more and more frustrations I can think of with JIRA. Will we ever move away? Not anytime soon. It integrates with everything and that’s hard to replace.

It’s still frustrating though.

> any minivan on the market is going to do an acceptable and safe speed

Growing up my folks had an old Winnebago van that took 2+ minutes to hit 60mph which made highway merges a white-knuckle affair, especially uphill. Performance was a criteria they considered when buying their next minivan. Whereas modern minivans all have an acceptable acceleration -- it's still important, it's just no longer one you need to think about.

However, not all modern interfaces provide an acceptable response time, so it's absolutely a valid criteria.

As an example, we switched to a SaaS version of Jira recently and things became about an order of magnitude slower. Performing a search now takes >2000ms, opening a filter dropdown takes ~1500ms, filtering the dropdown contents takes another ~1500ms. The performance makes using it a qualitatively different experience. Whereas people used to make edits live during meetings I've noticed more people just jotting changes down in notebooks or Excel spreadsheets to (hopefully remember to) make the updates after the meeting. Those who do still update it live during meetings often voice frustration or sometimes unintentionally perform an operation twice because there was no feedback that it worked the first time.

Going from ~2000ms to ~200ms per UI operation is an enormous improvement. But past that point there are diminishing returns: from ~200ms to ~20ms is less necessary unless it's a game or drawing tool, and going from 20ms to 2ms is typically overoptimization.

I think there is a mismatch between most commenters on HN and who is making purchasing decisions for something like Linear: it would the PGM/TPM org or leadership pushing it and they are touching the tool a lot more often. Even if a small speed up ultimately doesn't make a difference in productivity, the perceived snapiness makes it feel "better/more modern" than what they currently have.

That said, I really enjoy Linear (it reminds me a lot of buganizer at Google). The speed isn't something I notice much at all, it's more the workflow/features/feel.

Yeah but Jira is a good example of where the culture building the software shows they don’t give a shit about performance or usability. They tend to go together. I agree the talk about Linear being good because it is fast is weird but I think a lot of people who say that are actually saying the workflows are sensible and the ux is good. The feeling of speed is partially because you don’t have to click 17 times to do something simple.

I urge you to try and set your display to 25 Hz. I don't quite feel it yet at 30 Hz, although the latter is more widely available as an option.

It all depends on what we do consider "good enough". 200ms total page render time would be "blazing fast" for me already. I've just clicked around Github (supposed to be globally fast, can we agree?) and the SPA page changes are 1-1.5s to complete.

To continue my example above, your computer peripherals are probably good enough. Have you considered what it would be like with a garbage-tier mouse? Similarly, maybe you wouldn't notice the difference to a better mouse. I do, because a standard office mouse is not the pace I'm moving at. (No, I'm not some the Flash, I am just fast and precise with my mouse.)

If anything, this gives us a glimpse of what's possible. The latency benchmark[1] of text editors has given us something to think about. In the past decade (already?!) that article was probably the sole reason for drawing public attention to this topic[2] . For example, JetBrains have since put considerable work into improving their IDEs (IntelliJ IDEA etc). They had called it "zero latency" mode.

[1]: https://pavelfatin.com/typing-with-pleasure/ [2]: small study from 2023 https://dl.acm.org/doi/fullHtml/10.1145/3626705.3627784

There is a certain point where UX responsiveness has a huge impact on how the product gets used.

I hate Jira with a burning passion simply because it is slow where I live (in China, with a VPN). Even minor interactions, like clicking on a task’s description to edit it, takes about 2 seconds. Opening a task from a list takes around 5 seconds.

The result is that I and my coworkers avoid using Jira unless we really have to. Ad-hoc work that wasn’t planned as part of the sprint just doesn’t get tracked because doing so is unreasonably painful.