> I'm also curious why rendering something in the browser would have poor performance or wouldn't be optimally accessible?
To render something in the browser, you have to first send the browser javascript, which then needs to run. Server side rendering can usually be able to generate HTML faster than the javascript renderer can generate DOM. And the HTML itself is often smaller than the javascript needed to render the html. (And you can generate HTML from your server, not from your user's slow android phone via javascript).
Server side rendering almost always gets you a faster time-to-first-paint. Which is good for blogs and news websites. But if you need client side rendering anyway (eg you're writing Figma), then its not as big a deal.
Sending everything to the browser to crunch is a lot of downloading, and then available at the speed/mercy of the client computer, relative to the resources they have, and what they have acvailable (relative to other tabs).
Server side caching is pretty good these days and a valid option in more cases.
A lot of devs just started client side and the other side naturally seems bad or unknown. The time where this was an issue server side was when linux didn't network or perform so well with lots of traffic (and the cloud became popular). That's been largely solved.
To render something in the browser, you have to first send the browser javascript, which then needs to run. Server side rendering can usually be able to generate HTML faster than the javascript renderer can generate DOM. And the HTML itself is often smaller than the javascript needed to render the html. (And you can generate HTML from your server, not from your user's slow android phone via javascript).
Server side rendering almost always gets you a faster time-to-first-paint. Which is good for blogs and news websites. But if you need client side rendering anyway (eg you're writing Figma), then its not as big a deal.