If you can do server side great: do it. The difficulty is accurately predicting how much JavaScript you'll end up writing. If your client-side JavaScript is comparable in complexity to your SSR you'll eventually end up with the worst of both worlds.
If a client tells me what they want built, I bet I'd be able to roughly guess how much js there's going to be, probably within a few hundred lines for a, say, 3 month project.
The larger the project, the large the margin of error, but still, it's really not that hard for the vast majority of work we do. Or at least I do, e-commerce, enterprise apps, etc.
That sounds logical if you are doing client work with a defined scope. From personal experience working in the startup world, which I imagine a lot of posters on here are, you don't always know what you are building or what the end game is.
I'm not sure that's such a huge problem. HTTP routing provides a wonderful architectural seam so that we can use different solutions for different domains like `/profile` and `/document-editor`. We can create rich client-side experiences without creating a monolithic SPA. And as long as we make sure we have those architectural seams we have the flexibility to decide.
Organizing my HTML into pages is the easy part. The hard part is the rich client-side experience: things like building a sortable/filterable table with a rich datetime picker where the data is displayed dynamically in a chart with zoom/pan capabilities. That's why I build SPAs: I've already bit the bullet to get highly dynamic client-side code, it's just as easy to construct my pages client-side as well.
