Actually, with GWT you don't have to load your whole app on page load. You can divide your code, and only load the code needed to display a loading / splash page, on initial load. This way, there's only about ~100KB of code loaded initially, which brings up a splash screen very quickly, and then the next batch of code is fetched and displayed.
Also all of these files are cached once loaded, so they don't have to be loaded again until they are changed.
A splash/loading page is a workaround to avoid the user seeing a blank/unusable page while your app loads.
The goal of server-side rendering is to show the user everything he supposed to see when a typical single-page-app loads, shows the a splash page, fetches the initial data and renders it on the page.
Fair enough, but if you render the page on server, you will likely have to do some processing (e.g database/api calls) in order to get the data to display to them. The screen will be blank while all of this is going on.
If you go the splash / loading page route, users will immediately see the loading screen come up.
Plus, with the 'render on server' route, if users visit any other page, they will have to wait for a full page reload, whereas with an SAP, they will just see a loading icon for a second or three before the new page will come up.
Its a lot more responsive overall, and the pros outweigh the cons in my experience.
The article is advocating for a framework that does both -- it renders the initial impression on the server (yes, including a few DB reads), snapshots it as an SPA, sends it to the browser, and then lets the user continue the interaction that began on the server.
It adds significant server complexity for what some would call a minimal improvement in setup time. The article is advocating it for exactly that: overcoming that (maybe minimal) setup time on the client, which includes a one or more server round trips.
In many cases, this will undoubtedly be premature optimization. But if the framework made it easy, then it might simplify your transaction model. You could unbundle transactions, knowing that you aren't paying a latency tax on them, at least on startup, since it's all happening on the server.
I would rather have something show up for the user immediately, than have him see a blank screen while DB calls are going on at server. But, to each their own.
My perception of how fast a page loads is that if you show me an 'app loading...' splash screen, it makes me feel your page is slow and bloated. I react better to a blank screen with the browser's progress bar moving. I suppose it's because it allows me to shift blame away from your webpage to the quality of my internet connection.
Also all of these files are cached once loaded, so they don't have to be loaded again until they are changed.