Reduces server costs. Able to process data on client, including mathematical computation via We ebAssembley. Which in effect allows you to create "Web Apps," rather than just a news site, blog, ecommerce, etc... figma.com is an excellent example.
Not to mention that SPA have been used for video game UI. Rather than building that system from the ground up.
If your client's needs are to just display a static and do not dynamic updates from the server then ignoring the SPA approach is very wise.
Client side navigation handled poorly is just that handled poorly. And should be handled by the Senior Developer and not the Junior. As SPA is just another tool for a specific use case.
Honestly, what do you think we did before the Facebook gods deigned to grace us with React? You understand that we didn't need SPAs to build everything, right?
Most of what's gotten better on the web has been about standardization and drastic improvements to EcmaScript. Unfortunately, we've taken all of these new toys and made sites that load slower, on average, on today's phones than typical sites did in 2009. The problem is far worse in developing nations where phones are many generations behind.
Don't get me wrong: I'm glad that React exists and if I was building Trello, it would obviously be an excellent tech choice.
However, there's exactly nothing simpler or faster about a React app vs a properly-cached SSR fronted by Turbolinks and a tiny framework like Stimulus for 98% of applications. I don't know how this became a sacred cow but at some point the Reactive defenders started reminding me of Scientologists.
People were really, really stoked about Java when it came out, too. One codebase that will run without modification on every device, they said.
I use Angular and Svelte professionally. Reactive to me is reactive programming via the rx package that spans many languages. However I only use those frameworks if the job calls for it.
Call me a blending edge buff, but once WebGPU rolls out you can blur the distinction of web site and native program. But I would not utilize such on statically rendered website. But I would use it on a portable version of Photoshop, Blender, AutoCAD, or Minecraft.
Can you do the above today, inefficiently yes. But once WebGPU (gpu multi processing via a compute shaders with shared instructions) hits in combination with WebAssembley Workers (shared instruction cpu processing with proper floats across X cores) it will be an entirely different story.
What is insane to me is that these UI frameworks run in combination with the DOM on the main thread. That they are not designed from the ground up to run SSR and it is an afterthought.
Or in the instance of third world can even be managed by a Service Worker that drip feeds updates and presents th em on the site they are on next time they visit.
1 million and one ways to skin a cat. No way is better, it depends on the client's budget and use case.
Not to mention that SPA have been used for video game UI. Rather than building that system from the ground up.
If your client's needs are to just display a static and do not dynamic updates from the server then ignoring the SPA approach is very wise.
Client side navigation handled poorly is just that handled poorly. And should be handled by the Senior Developer and not the Junior. As SPA is just another tool for a specific use case.