How Rails Developers do Ajax in 2011 | Hacker News Reader

How Rails Developers do Ajax in 2011

chadfowler.com

118 pointschadfowler23 comments

I wrote a small wrapper on top of backbone and Backbone.Rails.js [1]. The combo replaced a very bulky internal framework, and I would never go back.

[1] https://gist.github.com/719080

Before I started developing Rails I always used JSON + client side templates which were constructed in pure jQuery and really tedious.

Then, with Rails, I asked myself, why would I want to have the template somewhere in the middle of a JS file where it isn't even recognizable as an HTML template at first sight? Why not have it, like all the other views, in one convenient place? Furthermore, often you have a partial you render on the server side and with some AJAX you send more entities of this partial to the client. Having this partial twice is really tedious if you wan't to tweak the HTML.

Could anyone share some good tutorials or guides on getting started with (preferably jQuery) AJAX and Rails 3?

I'm doing a little here and there in a current web app, but I could absolutely use some tips, pointers, and direction on better ways.

The big new feature is unobtrusive javascript: http://asciicasts.com/episodes/205-unobtrusive-javascript

I'd also be interested in some up-to-date guides on this. I've always used the .js.erb method Fowler talks about because it's what I see Ryan Bates do in his Railscasts (the last screencast Bates used this method is in [#240][1]).

[1]: http://asciicasts.com/episodes/240-search-sort-paginate-with...

Is anyone using pure.js? That's been one on my radar since they use pure HTML templates with JSON models. I don't think it does data binding to update the template automatically after the first render if the model changes, but apart from that, it seems preferable to using custom templates like jQuery or Mustache etc.

http://beebole.com/pure/

That having been said, I haven't started using it yet. I'm open to other viewpoints.

I wrote it. What makes jQuery and Mustache preferable? I know pure.js is different, but having the HTML clean of any tags or logic is something new and very flexible.

That's what I was saying. From what I've seen, pure.js does seem preferable to using Mustache or jQuery templates. I was curious if anyone else had other feedback after using it.

The reason I am considering it is to be able to use Ruby erb templates on the server to initially populate data on a page, then use pure.js and its directives to treat that same HTML as a javascript template.

With mustache or jquery templates and everything else I've seen, you're tied to rendering at least some basic empty HTML first, then populating it with javascript templates once javascript is ready.

I've messed around with it some and it seems to work fine. I guess my question is why isn't everyone doing it this way? :)

I guess people feel at home with a double-brackets template engine. It mimics what exist server side for ages. A pity as HTML in the browser is a DOM, not a sliced string.

I like to use a combination of these. There is no wrong way or right way, just the way that gets you done fast, and maintainable. You may begin using one way and find it may be easier trying another way, depending on what you're trying to do. The great thing is the flexibility.

why suffer the performance implications of client side rendering for something like partials?

can you be more specific or cite examples on performance.

We use pure.js to render our entire app. There is no server rendering at all and I find it fast. Here's a link to a demo https://beebole-apps.com/?demo&lang=en_US&x=2

Sounds to me like there would be a trade-off between network latency (delivering HTML ⇒ possibly more network traffic) and a number of string operations & DOM manipulations. Given how fast browsers are at the latter lately, I would imagine client side rendering could be the faster option — but let’s look at the real numbers before deciding, I suppose.

Wouldn't the right question be "why suffer the performance implications of server side rendering for something like partials?"

Agreed. Client side rendering for most things is instant. Client side rendering scales better than server side, in my opinion. 1 user or 1,000 users using your website, will not affect the rendering time on the client's machine (just the data transfer times), but will affect the rendering time on the server.

actually i believe the right question would be "in which scenarios does it make sense to deliver them rendered, and in which scenarios does it make sense to render on the client"; which was the intention of my original question.

based on the responses it's clear that my question sounded like a leading one. it was not and i employ both methods actively.

Accessibility, for one.

Definitely. I wasn't posing the question, just pointing out that the performance hit is actually doing it server side.

I see this one come up time and time again, Accessibility is not implicit to server side rendering and is easily managed via client side rendering. It is one of my companies specilizations we do client side web app accessibility and to be honest building an accessibility layer with client side logic is far easier than dealing with it via the degree of separation that the server creates. There are many tricks that we use to fool JAWS into doing what we want that are just not available via server side rendering. Accessibility is not hindered by client side rendering if anything it can be enhanced.

There are definitely drawbacks, but I'll tell you the best two reasons I know why you should render partials in JS:

- It means you can render partials to the user before you receive data from the server. So things seem to happen instantaneously to the user.

- It also means you can have your partials rendering in a single place and rendered by a single template engine.

surely. the first reason is clear to me. i use client side transformations for this purpose.

performance was admittedly awfully misdirected in a general context. i suppose my situation is unique; several templates on my app require complex logic or additional requests based on properties of the initial request. this is where you start to see it get hairy.

again though, admittedly not the normal scenario. i appreciate you taking my question literally, as it was meant.

It's a good point. When you have complicated templates, usually these JS template libraries fall a bit short.

Reply on news.ycombinator.com