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

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.