> This may get downvoted to oblivion due to the HN bias against js.

Now, come on. Very few people in here would say that js had no place in the web. A lot of people are against js when alternatives exist. Trello is an application, so js makes sense there. A blog article that doesn't even display when js does not load, that's where people have a problem.

It seems a large chunk of people would rather trello was built entirely out of html forms so you press a <button> to make the card move to the left and then the page refreshes with the card moved.

This is an uncharitable interpretation: many people would like it if things which were billed as being faster were in fact consistently faster and degraded well. That doesn't mean that Trello should trigger navigation every time you move a card but it does mean that anyone taking over a core browser function is taking on a higher level of responsibility to do performance, accessibility, and compatibility testing.

A similar issue comes up with Google AMP: it's billed as a web performance move but it's regularly slower and the failure mode is that you don't see anything at all. That doesn't mean that the problem is completely intractable but the act of taking over a core function put the onus on them to do a less shoddy job.

This x 1,000,000. It really depends on what the website is trying to do. If the site is basically just text and images, then yeah. You have to fetch all that every time you go to a new page either way, so why try to re-invent the wheel? The more your website is an application, the more it usually makes sense to have a SPA, because you want everything on the website to react instantly to interaction. In that case, you're building a classic client-server application, and you want the interface code running on the client, not the server. Otherwise you introduce latency due to the communication between the two.

So maybe this is kind of obvious, but the whole purpose of client-side scripting is to make the site more interactive, right? If your site is completely static, you shouldn't be using client-side scripting. If you're site is very dynamic and interactive, you should be relying a lot on client-side scripting. Imagine writing a video game for the web where every key stroke was sent to a web server and every video frame was retrieved from the server. That would be way too slow due to the amount of interactivity involved and the latency introduced by the communication with the server between every frame.

It's two years later, and I'm still waiting for those improvements in Jira. Until then Jira is a great case study of how not to do things in JavaScript, it's slow, it's inconsistent and I doubt the accessibility is very good.

(It's also a great case study of how it doesn't matter how good or bad your app is, the success of your business doesn't depend on that)

We're definitely very slow on load at Atlassian, but our accessibility is actually really good. One benefit of a good component library (in our case React) is it allows mapping of accessibility labels fairly easily. Jira should be fully navigable with just a keyboard and headphones.

> Just stay in js land as a single page application and communicate with server purely in REST.

This is a sensible conclusion. Unfortunately, "js land" tends to grow as application grows. And nobody actually unloads their Javascript when it is no longer necessary (can you even do that?)

Server-side rendering means, that you shouldn't leak memory — otherwise your app will literally stop working.