The difference there is that it's very hard to port a non-JS server-side-rendered site to React if it turns out you do need to. Whereas it's relatively easy to port a React application to additionally do server-side rendering.
The other difference is that I'm having a hard time imagining a scenario where someone is getting blindsided by "damn, it should've been a SPA after all!"
I'd be wary of all of the technical decisions that were made if the decision-maker knew so little about the requirements that they couldn't even call that shot correctly.
Of course, on a long enough time scale, all bets are off.
> The other difference is that I'm having a hard time imagining a scenario where someone is getting blindsided by "damn, it should've been a SPA after all!"
I've seen it happen more than once. Start with what looks like a straightforward form flow, seems like it should be fine in rails or whatever. Then it turns out some fields depend on other fields, so you've got to dynamically show/hide parts when other parts are set. And doing a server roundtrip, even AJAXey, is just too slow. So you put a bit of client-side Javascript to handle that. And then as the product evolves the interrelations between the form elements become more and more complex and businessey, and you have more and more logic split or duplicated between backend and frontend.
This is something a lot of people just don't get. And with react's serverside render, you don't get a trashy 2010-era SPA, you have an SPA that is also an MPA. It's literally the best of both worlds with porting your redux to reactnative for Android/iOs just around the corner.
I'd be wary of all of the technical decisions that were made if the decision-maker knew so little about the requirements that they couldn't even call that shot correctly.
Of course, on a long enough time scale, all bets are off.