I think that issue, while valid, is entirely different from what OP is talking about. That is the question of client to server side rendering tradeoff, and it looks something like this in my view:
- If you have a website that people will come to then spend a bit of time in different views (like gmail, facebook, or an analytics dashboard), it will usually pay off to dock the initial load time a bit in exchange for much faster loads of subsequent views. This is the base tradeoff made by switching to client-side rendering.
- If you have a website where most people will come check out one page then bounce (like a news site, a blog, a page with directions or info, anything where an article will be linked to rather than something that's used like an app), you won't want to make that same trade, since the extra blow to load time initially is going to hit most people and they won't see the benefits of the reduced load time for slowly adds up as you hit more views on the page, because they will read the info then leave.
Any page can be built as a single page app, and many people will do this automatically since it's the new hotness. But the question we should be asking ourselves is whether what you are building actually will be used as an app or not. I'll close out with an interesting example:
If you are building a news site, you should not build as a single page app because it's likely that you'll have a lot of single page views and a high bounce rate. Those single pages should be rendered as quickly as humanly possible. However, if you are building something like a feed reader, the situation would be the opposite. People will likely spend a bit of time in your interface reading a variety of articles, so the additional load time at the beginning will quickly pay itself off in faster renders for each item they read.
EDIT: An interesting approach for a news site would be to render single article views straight from the server or have them compiled, but render their homepage as a single page app. Tailor different parts of your website to the way that they are viewed. Has anyone written about this? Maybe I should write about it...
Template rendering is rarely a bottleneck. When JS-only pages seem slow, it is often because they are loading large JS libraries or are waiting for after page load to begin fetching AJAX data. By prerendering the initial JSON data for the page in script tags, and keeping javascript to the minimum necessary to render the page, pure javascript can render very quickly.
It's no secret that you need to minify your scripts and pass them along in a single request and put them at the bottom where they won't be blocking the UI to render. You should also link to CDN's to avoid that costly lookup or wait for the HTTP request hit (which is just so much larger when you're talking about it coming from the server (hopefully its light JSON and not a beast riddled with server-side templates.
Bustle is an example used by Tom Dale, and their js app is what? Not even 150kb? your headers alone are probably slowing you much more than this.
Locking the UI is bad, but it's not all JS apps that lock up the page as the browser puts it all together. You just need to know how the browser reads your styles and scripts and put them in the right place.
I think your edit is spot on. Cache a single page render in the event that someone is hitting it from search or a direct link and if they hit the home page, give them the dynamic single page app treatment. Sounds like a happy medium with a little overhead. (JS apps who want to be indexed would want the static pages for crawlers anyway.)
- If you have a website that people will come to then spend a bit of time in different views (like gmail, facebook, or an analytics dashboard), it will usually pay off to dock the initial load time a bit in exchange for much faster loads of subsequent views. This is the base tradeoff made by switching to client-side rendering.
- If you have a website where most people will come check out one page then bounce (like a news site, a blog, a page with directions or info, anything where an article will be linked to rather than something that's used like an app), you won't want to make that same trade, since the extra blow to load time initially is going to hit most people and they won't see the benefits of the reduced load time for slowly adds up as you hit more views on the page, because they will read the info then leave.
Any page can be built as a single page app, and many people will do this automatically since it's the new hotness. But the question we should be asking ourselves is whether what you are building actually will be used as an app or not. I'll close out with an interesting example:
If you are building a news site, you should not build as a single page app because it's likely that you'll have a lot of single page views and a high bounce rate. Those single pages should be rendered as quickly as humanly possible. However, if you are building something like a feed reader, the situation would be the opposite. People will likely spend a bit of time in your interface reading a variety of articles, so the additional load time at the beginning will quickly pay itself off in faster renders for each item they read.
EDIT: An interesting approach for a news site would be to render single article views straight from the server or have them compiled, but render their homepage as a single page app. Tailor different parts of your website to the way that they are viewed. Has anyone written about this? Maybe I should write about it...