All sound like solutions to self-created problems.
> 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.
Hot code reloading is a way to test changes without dropping current state, something that's extremely handy during development to avoid wasting time replicating said state every time.
Does the tooling suck donkey ass? Yes. Does it have serious tradeoffs to consider? Yes. But in many cases it's the right thing to do to have a higher-quality product.
Client-side routing is rarely used to change small stuff. It's usually used to replicate an entire page transition.
> When well-executed, it provides a better experience to the average user.
It's rarely well-executed. Client-side routing means you have to replicate every feature of browser routing, and most frameworks get it wrong. Numerous issues like not supporting cmd/ctrl+click to open in a new tab, ext, are common.
> Hot code reloading is a way to test changes without dropping current state, something that's extremely handy during development to avoid wasting time replicating said state every time.
Like the GP said, this is a self-created problem. Separate development pages to test out small parts of an application is how you avoid replicating state. But today's web development environment is so wrapped up in tooling and build complexity that creating a new page to test out a small part of the application is actually really hard to do.
> Separate development pages to test out small parts
> of an application is how you avoid replicating state.
> But today's web development environment is so wrapped
> up in tooling and build complexity that creating a new
> page to test out a small part of the application is
> actually really hard to do.
It's not just a browser auto-refresh when you save a file. It's the browser refreshing with the same state that was on the page.
Even if you isolate a somewhat complicated <form> on its own /form-test-page, you still don't want to drill down into the form state you're testing as you make changes to the UI.
For example, it would remember that you had the datepicker open with Jan 2017 - Oct 2018 selected as you fix a bug regarding the cross-year boundary. Stuff like that, useful any time you have some Javascript on the page.
For content focused sites (specifically excluding things that really have to be done all client-side), it is practically always better to use pjax/hijax to enhance a server-rendered app.
As far as what's available now, I find that intercooler.js provides the right balance.
So much of the SPA ecosystem seems to exist to solve self-created problems.
This isn't true. Have a look at how the GitHub UI is implemented. [1] There's even a name for this approach. [2]
I'm not sure why people struggle so much and fight abstractions so much but I guess that's a sign a techie is getting "old".
Yeah, it's a sign they are older, and have seen the same shit play again and again, and starry eyed newcomers fall for every new fad with shit-eating grins...
Some abstractions cause more trouble than they solve, and then create solutions to their own problems on top. That's the point.
Older techie might have seen more abstractions, and choose more wisely the lesser complicated one for the job.
On the spectrum of abstraction by Cheng Lou (react-europe 2016) [1]
If you've read some of the classics, such as Structure and Interpretation of Computer Programs (1979, Gerald Jay Sussman and Hal Abelson) [2], this talk is a really interesting look at the state of affairs on abstraction circa 2016.
Some of those "older" techies have gotten a wisdom that only comes with experience.