Meanwhile my browser can load, render, and scroll a 4000 line colored diff in less than half a second (e.g. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...)
When you look at Jira using Chrome DevTools there are these big batch.js and batch.css files (up to 5MB in total) that are different for every type of Jira view (dashboard, agile board, issue detail, issue search, …) so the first few page loads might be a bit slow but then they all should be cached as they don't change until you update your Jira and everything should be smooth. Except that wasn't what I saw, they seemed to be reloaded every hour or something.
Naturally I blamed Jira, and wasted hours Googling for batch.js not being cached, but eventually came to the conclusion that it can't be Jira's fault, and it isn't. Turns out it's the Google Chrome's cache backend that's used on Linux (and only there). There are three issues with it:
1. it's limited to cca 320MB even if you've got 1TB free space
2. entries are evicted by age times size, ignoring number of hits
3. media files such as 2MB youtube fragments use the same cache
The result is that watching youtube for a while evicts all cached batch.js. To make this bearable, I enabled gzip in the reverse HTTP proxy in front of Jira, which brought batch.js down to 500KB so that it's smaller than the youtube fragments and isn't evicted sooner than those. Still, few hours of watching youtube and not visiting Jira evicts it. Increasing the cache size using "google-chrome --disk-cache-size=2000000000" helps as well.
Oh and here's the link to Chromium issue tracker: https://bugs.chromium.org/p/chromium/issues/detail?id=617620 :-)
But my key anecdote is about loading the notifications sidebar after the page has loaded, there shouldn't be any customizations in there. But I dunno, maybe Jira gives managers a bit too much rope with which to hang their development teams.
This reinforces for me that JIRA should always be self hosted.
In previous job we used jira cloud and it was terrible.
No it does not: it clearly makes the point that due to device, hardware, OS, and framework latencies your application has very little time budget in which to respond and still feel fast to users. This will necessitate considerable effort in terms of architecture. I don't see how that's under-emphasising it.
To have a useful discussion on architecture within the article they'd have to talk about the specifics of different software and applications, which obviously vary considerably according to the requirements for said software and applications.
The danger with that sort of thing is that some people will say, "well, if we use architecture X then our application will feel fast," disregarding many of the detailed requirements of their domain that mean X won't always (or possibly even ever) perform well.
To some extent that's unavoidable but I think this article was absolutely on point in that it makes clear the constraints within which software developers must operate, and sensibly leaves architecture as the responsibility of those software developers.
There's no obligation to always make software useful for other people. There's a lot of space between doing something manually and selling a product.
The problem, which you basically acknowledge, is that software that isn't useful generally doesn't get used. If you write nice custom scripts to make your own workflows more efficient, that's great... for you. But to make any interface "useful" (whether it's a UI, an API, etc.), it doesn't just need to be "useful", it also has to be accessible. That should help explain why even crappy UIs are so ubiquitous. They are moderately useful, but extremely accessible.
Thank you for being that sort of person.
I know some people who would take great pleasure in knowing that they would get paid for spending just that time, no matter if they achieved very little doing it.
Caching works for 99.9% of cases, 'but sometimes', I click on an issue and it was just updated just before my page rendered.
We don't use much stuff and it's a bit older version 7.8, but I cannot complain so far.
Load times are atrocious. It's the slowest website I have ever seen. Maybe facebook is slower, but I don't use that as often.
I would take measurements, but JIRA prohibits benchmarking for some reason... ¯\_(ツ)_/¯ they're probably just trying to save everyone else the embarrassment of seeing how incredibly fast JIRA is compared to their own sluggish offerings, right?
I am confident that JIRA's application latency has nothing to do with Java (backend) or JavaScript's (frontend) garbage collector.
Many companies just feel no impetus to write fast software, or to use commensurately powerful hardware.