▲ | zelphirkalt 10 hours ago | |
I find it quite presumptious to assume, that backend developers do not care about this or that, or that they "drag ass about it". To me it rather sounds like what you describe are code monkeys that give zero pushback on back engineering decisions, and will jump at anything that marketing throws in front of them. We have way too many of that kind already, making the web a dystopian version of what it should be. And let me tell you, I am mostly doing backend things, as all the hype in the frontend world is offputting, but when I do frontend things, I don't do half-assed things. I make websites more responsive than 95% of "responsive" websites that we find these days as passing for that, most of which are developed by frontend developers, unsurprisingly. This is because I don't subscribe to the hype and solve responsiveness issues using web standards and CSS. Just the other day I enhanced a couple of pages in a platform I am building, so that they can be used entirely without JS, while they are polling the backend API. Nothing too complicated, simply taking precautions on the backend side for enabling those pages to be reloaded and rendering updated state, and avoiding reloading them triggering new unwanted duplicate actions in the backend. How rare it is, that I see frontends going to that length of putting in some minimal effort, to make their websites more accessible and privacy friendly. Where are all those great web developers? As I see it, a good developer with good knowledge about the basics of web development, most importantly HTML and CSS, only secondarily JS, can build better sites than most of what we see on the web today. The current mainstream is clearly not working all that well. Why one would go for SSR? Because it doesn't require ones users to run untrusted JS. Because it doesn't require every single client to rerender the same things over and over again. Because it is lighter on the client. Because often it needs less data transferred, because there is no frontend framework whose code needs to be sent. Because it does not require repairing browser functionality after breaking it. There are many reasons to choose SSR. Also I will note, that you can do SSR and separate the logic for rendering your pages from your other code, so that the SSR accesses only API routes. Then others can build alternative frontends for that API. |