I think Web apps have been around so long now people have forgotten how unresponsive things are vs old 2 tier stuff.
I tested the Jira cloud service with a new, blank account. Zero data, zero customisations, zero security rules. Empty.
Almost all basic operations took tens of seconds to run, even when run repeatedly to warm up any internal caches. Opening a new issue ticket form was especially bad, taking nearly a minute.
Other Atlassian excuses included: corporate web proxy servers (I have none), slow Internet (gigabit fibre), slow PCs (gaming laptop on "high performance" settings), browser security plugins (none), etc...
At that point, something mustve been wrong with your instance. I'd never call jira fast, but the new ticked dialog on a unconfigured instance opens within <10s (which is absolutely horrendous performance to be clear. Anything more then 200-500ms is.)
it's open within 1-2 sec (which is still bad performance, objectively speaking. It's an empty instance after all and already >1s )
It's still sluggish compared to a desktop app from the 1990s, but it's much faster than just a couple of years ago.
To be fair, small time units are difficult to internalize. Just look at what happens when someone finds out that it takes tens of nanoseconds to call a C function in Go (gc). They regularly conclude that it's completely unusable, and not just in a tight loop with an unfathomable number of calls, but even for a single call in their program that runs once per day. You can flat out tell another developer exactly how many microseconds the RPC is going to add and they still aren't apt to get it.
It is not rare to find developers who understand that RPC has a higher cost than a local function, though, and with enough understanding of that to know that there could be a problem if overused. Where they often fall down, however, is when the tools and frameworks try to hide the complexity by making RPC look like a local function. It then becomes easy to miss that there is additional overheard to consider. Make the complexity explicit and you won't find many developers oblivious to it.
I'm not too familiar with Go but my default assumption is that it's just used as a convenient excuse to avoid learning how to do FFI.
Nah. Jira was horrible and slow long before the microservice trend.
In fact, I'd argue that one of the biggest annoyances I had in last job was that I actually missed JIRA, or rather it's glorious issue list view with its keyboard shortcuts.
So really eventually we'll all be optimizing around network interfaces as the bottleneck.
It's very rare to meet a developer who has even the vaguest notion of what an RPC call costs in terms of microseconds.
Fewer still that know about issues such as head-of-line blocking, the effects of load balancer modes such as hash versus round-robin, or the CPU overheads of protocol ser/des.
If you have an architecture that involves about 5 hops combined with sidecars, envoys, reverse proxies, and multiple zones you're almost certainly spending 99% to 99.9% of the wall clock time just waiting. The useful compute time can rapidly start to approach zero.
This is how you end up with apps like Jira taking a solid minute to show an empty form.