Rails emerged at about the same time as Ajax did, and the two technologies can work tightly together. Ajax, a set of technologies for creating much more interactive interfaces in the browser, can connect neatly to Rails’ more server-based approach. There’s much more than that, though, as the Rails framework includes a number of components designed specifically for making it easier to build Ajax applications from inside of Rails.
Note
As we mentioned back in Chapter 5, you can download
plug-ins, such as ActiveScaffold (http://activescaffold.com), that provide a lot of
built-in Ajax functionality to get you started exploring.
If you need to read this section, it’s probably a sign that you should find a book devoted to Ajax before building Ajax applications on top of Rails. Rails provides an excellent set of technologies for supporting Ajax development, but you still need to know how to work with the JavaScript browser side of Ajax before you can make effective use of them.
Note
Ajax development is itself worth a book or even a shelf of books, depending on how you want to go about it. Even Rails-based Ajax development has a book: Scott Raymond’s Ajax on Rails (O’Reilly, 2007). This chapter will get you started, but there’s an almost infinite amount of potential complexity around this subject.
Most of what Ajax does today is what used to be called Dynamic HTML, or DHTML. DHTML built on regular HTML by adding JavaScript code that could change the underlying HTML. Change the HTML, and you’ve changed the page. As browsers became better at and more reliable at presenting those changes, developers created more and more applications offering users a much more interactive experience.
Ajax, which initially stood for Asynchronous JavaScript and XML, took another step toward interactivity. Manipulating the components on a page was useful, a big step forward for user interfaces, but after a while that interface really needed an equally interactive connection to the web server. The old model of loading one page, interacting with it, and then loading another page—shown in Figure 16-1—didn’t make very much sense when DHTML could build such powerful interfaces.
To give those DHTML interfaces a more flexible connection to the
server, developers began using the XmlHTTPRequest object. This object let JavaScript make HTTP requests back
to the server that the page came from, as shown in Figure 16-2, and the script
could then decide what to do with the response. (The name suggests that
the response must be XML, but that’s not actually required.)
It took some time for developers to realize that their scripts now
had their own powerful communications mechanism, but once the pattern
was established, XmlHTTPRequest was
popular. So popular, in fact, that developer after developer built
library after library to smooth over the odd differences among browser
implementations, and programmers with DHTML skills were suddenly back in
demand after years of quiet—as long as they rebranded themselves as
“Ajax developers.”
Using Ajax effectively requires knowing HTML, CSS, and JavaScript, as well as at least a basic understanding of interface design. That takes care of the browser side, but on the server side you can use anything you like—including Rails.