SEO was our first concern, but then we realized performance was the big win. Serving the user a full page of HTML rather than waiting for JS to download before rendering HTML makes a big difference, especially on high-latency or low-bandwidth connections (mobile).

EDIT: We decided against using something like PhantomJS or node-chimera because why deal with a DOM if you don't have to? DOM is complicated and slow, compared to string-based templating. Plus, it's another moving part, another process to keep up and running. The Meteor guys aren't too excited about the PhantomJS approach either, and IIRC they'd like to be able to serve HTML without firing up a DOM.

Does this mean Rendrjs applications will run in a JavaScript disabled browser? That would be a big win!

Yep! Because links use full URLs which get intercepted by JavaScript, if JS is disabled, you can still navigate around the app, getting full HTML from the server. Of course, any client-specific code wouldn't run (slideshows, etc).

So far, this is the most convincing argument I've heard for Rendr.

I'm a little confused here. Maybe I'm just not seeing it, but how does that make Rendr any different from any other server-side framework that responds with HTML?

Because you're using the same JavaScript code for rendering on either the client or the server.

How do you measure performance? I'm interested specifically in where & how you instrument, and how you collect the data.

Cool stuff, thanks for the response!

Or Zombie, which is way faster than PhantomJS: https://github.com/bfirsh/otter