A sign-up form? Yeah, you aren't getting much from your SPA framework. Pure overhead.
A data-table with user-selectable columns, pagination, and arbitrary sorting and filtering, where the data is too large to fit in memory (billions of rows) so you have to re-render by hitting the server; but the rows contain view-state components, so you can't re-render on the server? Two lines of code in an SPA; three months on your own. Equal resulting JS size, either way.
And something like Grafana: how would you even do that server-side? Emit a server-sent-event stream of SVG images? This is a case where server-side rendering would result in heavier client-side code than an SPA would!
-----
Now, the majority of people using SPAs don't need SPAs. I think people get into SPA frameworks like React because everybody wants to learn the frameworks and libraries, to have them in their pocket and on their resume, for when they (hypothetically) one day get hired for that one job where they do get to build the fancy slice-and-dice analytical data dashboard. That job probably would pay pretty well. They want to be qualified for that job.
If you're a project manager, and you really value getting an MVP shipped quickly, you should push back on the engineering lead's desire to use an SPA framework. Ask them whether there's anything they're really gaining for this specific project. If there's no reason not to, then just suggest they build the app as a plain-old server-side-rendered-HTML app. Use Rails; heck, use PHP. (Or be fancy and use Phoenix LiveView.)
A sign-up form? Yeah, you aren't getting much from your SPA framework. Pure overhead.
A data-table with user-selectable columns, pagination, and arbitrary sorting and filtering, where the data is too large to fit in memory (billions of rows) so you have to re-render by hitting the server; but the rows contain view-state components, so you can't re-render on the server? Two lines of code in an SPA; three months on your own. Equal resulting JS size, either way.
And something like Grafana: how would you even do that server-side? Emit a server-sent-event stream of SVG images? This is a case where server-side rendering would result in heavier client-side code than an SPA would!
-----
Now, the majority of people using SPAs don't need SPAs. I think people get into SPA frameworks like React because everybody wants to learn the frameworks and libraries, to have them in their pocket and on their resume, for when they (hypothetically) one day get hired for that one job where they do get to build the fancy slice-and-dice analytical data dashboard. That job probably would pay pretty well. They want to be qualified for that job.
If you're a project manager, and you really value getting an MVP shipped quickly, you should push back on the engineering lead's desire to use an SPA framework. Ask them whether there's anything they're really gaining for this specific project. If there's no reason not to, then just suggest they build the app as a plain-old server-side-rendered-HTML app. Use Rails; heck, use PHP. (Or be fancy and use Phoenix LiveView.)