How would you be painting yourself into a corner with PHP more than with JS? If you use PHP, you can just serve/use JS later. But if you use JS, you will have a hard time serving HTML from PHP later. Aside from both languages kinda being painting oneself into a corner, I don't see how one would do more so with PHP than with JS, out of all the things.

▲

reactordev 2 days ago | parent | next [-]

The issue is, if I’m using JS, why on earth would I ever use PHP? I can just await file('index.html') or return <IndexPage>

The cognitive load is null. You’re just having trouble breaking apart your learned behavior. Returning a component of jsx is just the same as writing an include for PHP.

	▲	zelphirkalt 10 hours ago \| parent [-]
		So if returning a component is the same, how would one (PHP) be more painting oneself into the corner than the other (JS)?

▲

sublinear 2 days ago | parent | prev [-]

I'm coming from the perspective of real world business concerns, not hobby projects.

It's inevitable that you will need to host the pages somewhere else like a CDN to lower latency, integrate with other backends, and the biggest one is allowing the frontend devs to have complete control of the HTML so that stylesheets and javascript don't randomly break for reasons out of their control. They should be able to develop everything locally with mocks instead of your server and use whatever build tools and frameworks they want. There are also SEO and accessibility concerns with the page structure. The backend devs should not be making decisions about any of that. Sometimes the client may want quick turnaround on simple but very specific changes to the pages. None of that process should depend on backend teams who don't care and will drag ass about it because they will have to refactor their junky code that hasn't been touched in years.

Getting rid of dependencies and having good boundaries in the code that align with the way dev teams are organized is always a good thing. I'm not sure why anyone would go for SSR unless they haven't done web dev in a while or are working on a legacy project. Even if this starts out as a hobby project, you need to keep things clean for future maintainers.

	▲	zelphirkalt 10 hours ago \| parent \| next [-]
		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.
	▲	reactordev 2 days ago \| parent \| prev [-]
		I agree with all of that except for SSR part. SSR is back, like it’s 1996. However this isn’t your old school monolith serving jsp pages with tag classpath hell, this is client side pages served from the server for faster rendering. We now have another layer. Browser -> Client-Side Server Pages -> Business Logic APIs -> Backend Systems.