Nice writeup. But a large part of the main point seems to be surprise that client-side rendering isn't going to be indexed by search engines:
> It occurred to me that the hype around client-side rendered apps
> is still alive and kicking. It’s not the first time I’ve heard
> server-side rendering negatively referred to as an “old school” technique.
and ...
> Chalk that up to my ignorance, believing the client-side rendered
> app-of-the-future hype, and not caring about SEO until the organic
> traffic numbers came in.
This should not be a surprise. Obviously, if you only render content on the client, then search engines aren't going to see any of it. Client-side-only-rendered applications should only be for private pages, user's workspaces, and web applications — pages that a search engine will never see, regardless.
Thanks Jeremy. You're right and the point is obvious in hindsight.
I think the end of your comment should be shared with others; for those that are eager to try, but not fully aware of the consequences of client-side rendered apps.
I'd like to include your statement somewhere in the post to further emphasize the point; I hope that's okay. Thanks!
One solution is to detect Googlebot and render the page server-side in a headless browser, and send the generated HTML instead of the full JS app. You could even cache the generated HTML to S3 to speed up pageload, which Google likes.
Of course you can use backbone.js apps without losses of SEO. You need to render versions for the crawler. Google crawls ajax sites perfectly, if implemented correctly.
How about just sniff the user-agent and deliver perfectly rendered views/fragments of your SPA through a serverside PhantomJS process to crawlers?
If you used backbone routing properly this shouldn't be a problem.
Or, use one of the "Full-Stack" Frameworks for Javascript which merge the client and the server almost completely. Derby.js comes to mind, maybe even meteor.
[edit]: you mentioned PhantomJS in your summary, didn't see it. But you don't mention why you didn't use it.
You're right about not mentioning why I didn't use it. Thanks for bringing this up.
I had the rare opportunity to re-imagine the profile app in the context of another app that was being built from scratch and went with the server-rendered approach.
The phantomjs approach is totally valid. Thanks for reading!
I'm a bit afraid of this. Is it so hard for Google to run PhantomJS and crawl JS sites. If google reads CSS display:none correctly why it's so hard to make the JS crawling work... That's madness. This SEO ( Google ) stuff is making decisions for frameworks and tech-stacks. That's bad, it has to be the other way around. I don't want to make websites for Google I want to make them for the users.
> I don't want to make websites for Google I want to make them for the users
Well,most of your users come to your website through Google, which is just another website.
I dont see why Google should adapt its stack to yours, since Google is actually the one who brings you users. It doesnt have to do anything for you, especially when you abuse javascript and dont provide a bot-readable fallback to indexable pages.
You cant have it both ways.Make readable html documents like you are supposed to and you'll be fine. Make a dynamic scripted mess and you'll lose some potential custormers because of bad ranking. You cant expect Google to do your job for you.
The first con needs a bigger cavat because image size and number of requests play a huge part in browser rendering. This is probably why the mobile app was so much slower than the desktop app. The small minified js file that contains your app has little performance hit.
