[dnajd]

I'm utterly confused. The main benefit of this approach is summed up in the paragraph: "Compare this with serving the full search results HTML from the server.... It feels 5x faster."

But doesn't ruby on rails (and most other web stacks) already do server side rendering VERY well and are hugely supported by enormous communities. Javascript is useful for things like infinite scroll, interactive client side calendars or making browser based games; but a web search is absolutely simple in ROR and doesn't need backbone or javascript at all.

Don't get me wrong, I love javascript and backbone / angular. But why push logic to the client side for a search page and then try to pull client-side technologies back to the server side in an effort to resolve performance problems that are already solved by existing technology?

In the words of Carl Sagan "why not skip a step". Unless you just love javascript so much that you're willing to recreate rails on the server side with it. That would be a sensible reason to do it.

Not trying to troll, just thought I'd throw this perspective out there.

[efnx]

Not to mention SEO. The points outlined above in the top comment (* Caching of shared static HTML for fast-as-possible page loads. * Google indexing and searchability.* Backbone apps that feel more like a series of pages and less like a single-page app.) are all things that Rendr accomplishes that are already taken care of by not making a full blown client-side JS app.

I think us developers are running into the same issues or pitfalls that we ran into during the rise of flash, where we move everything to the client because we can. The problems that Rendr is solving seems to be the same problems caused by giving too much responsibility to JS.

[frontendbeauty]

It sounds like you are really questioning the usefulness of client-side JS apps in general. Certainly not every app makes sense to be a "single-page app". But if you are creating a single-page app, then why not also allow it to render on the server?

I like to think of Rendr as just another Backbone app, that happens to be able to serve HTML from the server as well.

[dnajd]

There is the straw man again. If you are creating a completely client side app and you find it's better to have some work done on the server side... why not use mature existing server side technology along with client side technologies. It's not a one or the other scenario.

Why work hard to move client-side technologies to the server? javascript is not so good that I want it on the server-side. And server-side lanaguages are not hard to learn or hard to find people that know how to use them.

[efnx]

Yes, I think I am too. I can see the need for a single page apps for really immersive applications like games or possibly for very small targeted applications like reading mail, or showing stats, but in the case of the latter you probably wouldn't run into ten seconds worth of loading scripts.

I think I'll understand when I run into the problem Rendr solves...

[ianstormtaylor]

You're missing the part about how single-page, client-side apps are much more performant _once_ the page loads. Spike is trying to get the best of both worlds (hence "Holy Grail").

Server-side gives you fast page load times. Client-side gives you fast user interaction times.

[dnajd]

That was the straw man I was thinking I saw in the post.

Why not use rails to load the page (no BYO framework involved) and then use javascript/backbone/etc on the client-side; as opposed to bringing the client-side technologies server-side to accomplish the same thing?

I'm thinking specifically of the search page example that was represented as a screenshot in this blog.

[frontendbeauty]

Exactly.