It's a pretty good argument: the three features mentioned as advantages over static or server-rendered html only exist to mitigate problems created by the SPA structure itself. It's like touting "fast battery charging" as an advantage of a Tesla over a Porsche.
I don't agree, but let's break this down, comparing to a traditional app in Rails/Django that renders HTML server-side, then progressively enhances with a sprinkling of JS.
> automatic code splitting
By code-splitting we implicitly mean we're also managing dependencies (e.g. via require() or import statements).
In a traditional server-rendered-app, you can achieve something similar to code-splitting by manually breaking up your script tags across pages as needed, but you lose dependency management. With code-splitting you get both, and your bundles are going to be better optimised than if you hand-picked script-tags (at least that's the promise of automatic code-splitting, and it'll only be enhanced as 'tree shaking' techniques mature).
> routing
Really, this should say 'filesystem-based routing', which you don't get for free in rails/django afaik. Granted you get it in old-school PHP, which I think Next is open about wanting to copy the 'ease' of. I think that's cool.
> hot code reloading
You don't get that in server-rendered frameworks. It's a hugely pleasurable boon to development to not lose all your page state when you just changed a bit of CSS or JS that shouldn't affect state. It even won't destroy CSS or HTML text-content changes I made with the Chrome devtools, which would get lost if I used something like 'live reload' to reload the page with a server-rendered framework.
> universal (server-side and client-side) rendering
It's not the server-side rendering that's the advantage, because like you say ... we already had that. It's the fact it's both. The initial load is server-side, which is a big win for mobile devices especially (remember when Twitter switched from an SPA back to server-side-rendering to improve 'time-to-first-tweet'). But every subsequent page load is done by requesting the minimal data needed and rendering client-side, which is faster than loading a full page from the server.
PHP has include()/autoload, you can structure your code any way you want. If you wonder about client side, the client side should be greatly reduced, by the virtue that page is ready to use as returned by the server. You'd just put JS code into a single script tag, and let it do its progressive enhancement when it's ready. Also you'd have much less JS code to load, because server is doing all the heavy lifting.
So this is mostly a solution to a problem of having to put all the website's code into the browser first, even if you want to view a single page and go away.
> routing
I think routing is a fine feature, even for PHP. But all you need is about 100 lines of generic PHP code, you can reuse for the rest of your life. So yeah, I guess this is useful if you want nice URLs and common initialization code.
But you can easily do without, either by using query parameters or URL rewriting. Really routing server side is such a simple problem it really is not even worth mentioning. It's always get me a final HTML code for some URL.
Client side it can get quite complicated, because your job is to transition between arbitrary app states, or to restore the state based on the route, switch views, update things incrementally. Again, it's just because SPAs are this complicated, that routing is even a feature worth mentioning.
> hot code reloading
You can put setInterval() on your page that will iterate through all <link rel=stylesheet> tags and reloads them every second, or you can hook it to a keyboard shortcut in the browser, to get immediate style changes, without reloading the page.
Though your server side app should be able to withstand F5 without loosing state at any point. One trouble is usually form inputs state. The thing with server side apps is that you can modify the code and just try to submit the form again without reloading the page first. You're not loosing the state, because the state is in cookies, query parameters, url, and server side. None of this changes when you modify your server side code. So you shouldn't have these issues. This is the biggest benefit of server side web apps.
> universal (server-side and client-side) rendering
Unless the client side code is optional, that's a disadvantage vs the progressive enhancement solution, because it's still unusable without the client code. It's just a performance optimization for the problem of client side only rendering being slow.
Even on twitter universal rendering is implemented in such a way that it's useless without client side code. You can't navigate, load more tweets, open images, nothing. It's just a gimmick.
When this universal rendering thing starts to mean that I can either use server side code only, or let the client side code run if I want more modern crap that doesn't work server side apps, like DnD, etc. Then that would be a feature itself. Otherwise it's just a solution to its own problem of the SPAs.
