PART II
Chapter 9: Site and Application Architecture with Ajax 479
Architectural Final Analysis
Do end users care what your application is written in? Do they feel a sense of security
knowing you wrote it in Ruby or do they have fear and dread because JavaScript was
included? Do they marvel at your MVC pattern and programming prowess? Do they read
your comments and wonder what you were thinking when you build off that neat recursive
algorithm? We hope these ludicrous statements drive home a point: the users don’t care.
When it comes to your use of Ajax in a Web site or application, users care if it works. They
care if it is fast. They care that it is rich and motivating and not annoying. They care if it
provides the functionality it should, and that’s it. All obvious points, but ones we may not
like to acknowledge.
Good architecture helps you build sites and applications quickly that are solid,
maintainable, and hopefully easily expandable with a new look and function. In this
chapter, we attempted to show a few approaches to how to move from traditional-style Web
applications to Ajax-style Web applications with a bit of grace rather than a tumultuous
upgrade for users where suddenly the back button is broken, the bookmarks don’t work
and the site falls apart under less than ideal conditions.
Yet our approach to Ajax application architecture isn’t limited to those ideas we added
in this chapter. They are just the final pieces, as we have been addressing browser concerns,
network concerns, security concerns, and interface concerns for quite some time. The sum
of these is our complete architecture. If the architecture is correctly applied, we hope the
users will focus on what is important: the content and purpose of the site or application
you built.Summary
In this book we’ve tended to focus on a client- and network-centric view of Ajax. The server
shouldn’t have to change much with the rise of Ajax. In fact, it can divest itself of some
presentational duties. In our attempt to design a solid architecture for Ajax development, we
have discussed how you should employ progressive enhancement so that your application
still works in light of transport, technology, or presentation concerns. Presentation-wise, the
movement of templates from server to client presents an elegant solution to using the same
application infrastructure for two different versions of an application: traditional and Ajax.
We also tackled the significant architectural change that Ajax introduces if the URL stays
static. Using the well-known hash location solution coupled with client-side persistence, we
were able to solve back button, history, and bookmark issues that plague Ajax applications.
With all the techniques fully applied, we demonstrated a complete CRUD application that
provided both traditional and rich support with one code base. Despite the elegance of our
solution, we note that many in the industry favor a server-centric tight coupling approach
with JavaScript generated or hidden from the developer. We performed a brief survey of the
approaches such environments take to expose the challenges they introduce and ended our
discussion with an observation that if purity of technology on both client and server is really
the concern, wrapping the JavaScript doesn’t make it go away, and maybe we ought to think
to embrace directly. In the next chapter we take up some advanced topics such as Web
services and the desire for real-time data using Comet and related approaches. We conclude
the book with the interest in offline Web applications that puts Ajax and like technologies
directly on an intercept course with desktop development ideas.