

Learnings from Client-side and Server-side rendering in Backbone.js - mrjoelkemp
http://mrjoelkemp.com/2013/11/learnings-from-client-side-and-server-side-rendering-in-backbone-js/

======
jashkenas
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.

~~~
mrjoelkemp
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!

------
anonyfox
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.

~~~
mrjoelkemp
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!

------
drinchev
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.

~~~
untog
I'm not Google's biggest fan, but I don't see how they're to blame for
developers removing semantic meaning from their pages.

------
ulisesrmzroche
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.

