Interesting, thanks.
I think Jason Miller, the Preact developer, re-tweetet the article about SEO & SPAs a few days ago.
But, because of progressive enhancement, I would using SSR on my next project anyways.
That seems like an example of a SPA that should really be a static site. Aside from it being the library's main page, why would you even need to implement this with any front end frameworks? I believe the parent post was referencing how companies usually have a static site for marketing/SEO, and the backend application is a SPA. This would effectively remove the need for SEO on an app that requires authentication anyways.
Re:Why we chose Vue.js
by andrewingram on Friday October 21, 2016 @11:30AM
(#12761228)
In that context, I agree. If your app doesn't need to be crawled or otherwise scraped, worrying about server-side rendering is just going to hold you back.
But there are public websites with a high degree of interactivity (such as social networks, or ecommerce sites) for which SEO is a huge concern.
Re:Why we chose Vue.js
by rorykoehler on Friday October 21, 2016 @09:41AM
(#12760289)
Is that not what sitemaps are for?
Here's a website that's an SPA https://preactjs.com
I don't have an exact page count, but I was able to find 15 pages from browsing around.
Here's how many pages various search engines have indexed using the query "site:preactjs.com"
Google: 17 Bing: 6 Yahoo: 6 Baidu: 1
One of the Google results is an error page, but it presumably can't be de-indexed automatically due to there not yet being a way of declaring a 404-equivalent in SPAs.
I've also read (I can't recall where) that Google has a latency of a few days when it comes to indexing SPAs compared to server-rendered apps. This may not be a problem for you, but it's worth knowing about.