So to give some perspective I've been using PJAX and hooking in front-end interaction using javascript (coffeescript) components to the DOM using jQuery (similar style to twitter bootstrap's javascript). I'm now looking at this: vimeo.com

PJAX obviously has it's uses. the 37signals stuff, the github stuff, and i'm sure the things your using it for are going to benefit from it.

it's just such a throw-back to the way asp.net ajax for webforms did it, that i cringe when i think about using it :P

i think pjax vs client side js rendering largely comes down to the specific needs of the project.

@DerickBailey see what you got yourself into :)

Hope I didn't come across flippant or arrogant. I always enjoy the change to debate and expand my views.

I've found that with pure JavaScript (again for us it's actually CS) on the client-side, the UI is very responsive and flexible. The drawback being supporting older browsers and browser quirkiness. I would imagine you would still suffer these drawbacks with something like PJAX, and you're basically trading off the full responsiveness of going totally client-side.

Also, client-side JS has really simplified things for us, especially when talking to a RESTful backend. Mixing rending across client and server seems like it would just complicate things more.

ha! I troll the twitters, and you apologize? there's something wrong here :D

+1 to old browsers and quirks. pjax has a huge advantage in that arena as you don't get near the compatibility problems. render server side, and i'm pretty sure every browser still in use supports ajax for transporting basic html and stuffing it in to the dom.

I love the idea of fully client-side rendering, but for complex apps it has a lot of challenges, especially on mobile. It's intuitively the future, but for a lot of applications it's not yet the present.

Doing a mix of client and server rendering is indeed unpleasant, so I lean for a given component towards all client or all pjax, if possible.

My finding is that at least for content driven websites client-side frameworks add very little and cost a lot in added complexity.

I suppose for a more interactive experience there is a benefit to these frameworks as they take care of a lot boilerplate event binding and data tracking.

Still, they seem to fill a very small void between content driven web and highly interactive javascript interfaces where even the most ambitious client side frameworks will fall short and we require something custom (think about rewriting the ACE text editor in one of these frameworks).

Right in the middle there is this basic need to just bind dynamic content to user input changes and/or dynamic server updates. I guess they fill that need.

that sounds about right, though i'm sure we could argue about the size of the interactive application space vs content-driven space, all day long :D

i rarely build content driven sites anymore. almost all of what i do is highly interactive applications, hence my propensity to lean on js frameworks like backbone.

for the sites that are just content, though, (like my screencasting site, my company site, etc) i don't make heavy use of js frameworks except for visual widgets like tabs to show / hide content.

Derick, do you still use Rails for the interactive web apps or do you back them up with something else, like node.js?

The fun and frustrating thing about client-side JavaScript is that the "bring your own" framework environment of the browsers - and the high cost of unused framework code - means that there is no framework that is good for most projects.

Allen,

I think this is generally a good thing. Some frameworks provide a very rich feature set (Angular, Ember), while others are minimal and designed as a foundation (Backbone).