I generally agree with you, and as a front-ender-first that feels kind of uncomfortable to say. In my personal projects I do often go for a more conservative se

I generally agree with you, and as a front-ender-first that feels kind of uncomfortable to say. In my personal projects I do often go for a more conservative server-side first approach. That said, it really feels like a chasm that quite often I choose to cross simply because it'll be easier down the line. I've been bitten more than once by server-side-first projects where going full-on client-side with the server-side as an API would've probably been better. Whether it was because I needed a mobile app to communicate with said API, or whether the complexity ended up being more of a client-side thing, the result was often that I had to focus on the back-end as as API and go for the full complexity of a front-end app anyways. I'm enough of a fan of my preferred back-end languages (Ruby, but mostly Elixir these days) that I try to find ways to keep the complexity there, but truthfully I often opt for going for the full complexity of a client-side JS/TS stack because I'm likely to end up needing it eventually anyways. I've looked into things like Drab (https://github.com/grych/drab https://github.com/grych/drab), but ultimately there are many reasons why 'going with the flow' seems like the better solution (even if just because it's so much easier to find JS devs than Elixir ones). So far I'm not confident enough to make any sweeping statements, but from that lack of confidence I tend to opt for the 'safer' option, which seems to be the SPA route much of the time.