Front-End Architecture: AJAX & DOM Scripting
Tuesday May 23, 2006 / 4 CommentsThe tipping point that really got me wondering about front-end architecture is AJAX. It’s unique in that it really crosses the chasm between user experience and the deeper technical bits. On one hand, AJAX is important because it enables us to create exponentially richer user experiences. On the other hand however, its implementation can leave much to be desired if handled incorrectly, and to make matters worse, because of the way it straddles the line between the front and back-end, it’s difficult to determine how it fits in with everything.
Hijax & Progressive Enhancement
In his book, DOM Scripting, Jeremy Keith discusses the concept of Hijax, meaning that a page should be designed with a plan for AJAX, but built around the traditional page model. Then, after you have a page working in its most basic state, scripting and AJAX can be used to intercept, or hijack, requests and offer a different, enhanced, behavior.
By creating the page first and knowing that it works correctly in a bare state, you know that you have a solid foundation for your AJAX enhancements. Obviously there is a short-term cost to developing this way, but it’s the right thing to do for long term maintenance and enabling access for those with screen readers and other devices.
Progressive enhancement isn’t always the easiest route for creating an application, but it’s the most forward-looking. Not only are you providing a fallback for anyone with a less than capable browser, but you’re forced to more clearly distinguish and organize your layers. That enables you to adjust or completely change the behavior in the future with fewer problems. Once again, with good semantic markup as a foundation, you’ll be prepared to more easily make modifications down the line.
Accessibility
Obviously, if AJAX didn’t enable us to significantly improve the user experience, very few people would be paying attention to it. However, just because it improves the experience for a majority of the people doesn’t mean that it’s perfect.
Hopefully, if you’re using AJAX, you’ve familiarized yourself with the serious accessibility shortcomings of AJAX. Clearly, there are still some significant questions around how to handle these situations, and whether it’s acceptable to even offer AJAX to screenreaders.
Frankly, if you’re building the application correctly, it should be significantly easier to overcome these obstacles. With proper separation and following the basic principles of Hijax, it should be fairly simple to offer an option on an accessibility preferences screen to disable AJAX. Of course, it would need some basic explanations of why the visitor might want to disable the “enhanced experience” as well.
This doesn’t necessarily apply just to screenreaders. However, they are the most prevalent given that there is no good way to communicate the state changes of a page if the whole page is not refreshed. The jury is still out on how to elegantly handle this, but unless we start doing our best to make an effort now, we won’t see any progress on this front anytime soon.
Bandwidth Savings
While it’s only an estimate, MacRumors, reported that they saved approximately 160 GB of bandwidth during the MWSF 2006 keynote by using an AJAX enabled page. That’s nothing to shake a stick at. So, under the right circumstances, AJAX can provide technical benefits as well.
Business Logic & Redundant Code
Another potential problem with AJAX is redundant code or misplaced business logic. Remember, JavaScript is only meant for enhancing behavior and performing client-side manipulations. It was never meant to handle complex business logic or hefty calculations. However, if you’re not careful, it’s easy to overlook this and have your business logic split between your server-side code and a client-side script file. That is almost guaranteed to turn into a maintenance nightmare.
Another possible problem is potentially having to duplicate logic in both your server-side code and your client-side scripts. This is more of an architectural decision. As long as the client-side scripting only enhances the experience and doesn’t perform any actually functionality, which it shouldn’t, then you should be fine. Bear in mind, if you have any redundant logic, you just doubled your effort when it comes time to maintain or enhance your work.
Response Object Options
Peter-Paul Koch recently dove into exploring the different kind of response object options you can use for AJAX requests and elaborated on their distinct advantages and disadvantages. Understanding the pros and cons of each in the context of your application can also serve you well when making long-term decisions for your application or site. I won’t go into the details, as Peter does an excellent job, and the comments serve to provide some solid insight as well. However, I strongly encourage you look into and understand each of the options and the associated implications.
Summary
AJAX & DOM scripting can introduce significant complexity to a project if you hope to build it properly, and as is the case with any type of programming, you have a significant, if not overwhelming number of options at your disposal. If you want to build an application that stands the test of time, it’s imperative you understand those decisions, and put some thought into making the right decisions for your situation. As with any other aspect of front-end architecture, if it’s worth doing, it’s worth doing right.
Featured Stuff - Resources: Wireframes & Page Description Diagrames
Omnigraffle and Visio versions of the wireframe templates and stencils I use on all of my projects. There’s even a few examples included for good measure. More about Wireframe & Page Description Diagram Stencils and Templates
[...] and whether it’s acceptable to even offer AJAX to screenreaders [...]
That’s the point I’m talking about with colleagues recently, I think that screenreaders really should ignore JS at all and stick with alternative/degraded core functionality. While they are not some kind of “aural media” actually, but simply interprets of onscreen information, they should a) have a better API to connect to the browser as their part to understand the underlying structure independent of presentation or behavior and/or b) turn automagically JS off in their host environment until they’re better capable of representing the basic document and functionality.
Jan BrašnaI think that screenreaders really should ignore JS at all and stick with alternative/degraded core functionality.
It’s not up to you to change how screenreaders work; it’s up to you to work with them. There are many places where Javascript is used and screenreaders not only understand it but deal with it perfectly well.
The basic document and functionality should be represented perfectly well without Javascript. Screenreaders are perfectly capable of understanding that. It’s the layers of “extra” functionality on top they have issues with; most notably, failing to notify the listener when an element has altered without the page reloading.
Basic functionality is standard HTTP. As long as you offer an option to disable it, screenreaders cope fine. If the “basic functionality” of your site/application demands Javascript, however, I’d argue you need to go back and rethink it. Progressive enhancement should make it easy to cater to any client. And that includes your most valuable one – searchbots.
Tom ArmitageTom, but this is not the case here. Even when you take completely perfectly working page/app with forms/links/whatever that got structure, meaning that is absolutely fine with screen readers, and then add the AJAX remote/partial functionality even via HIJAX, you still come the the point where you confuse the screenreaders and users respectively. Since the reader sits on top of a fully functional browser, it “sees” only the surface (if I simplify that), so they got caught in the JS events, even though they can’t resolve/interpret the response – in the meaning of notifying the user. I really think the tasks would get done better if the screenreaders ignored the JS “surface” and used only the underlying fully functional non-remote, non-asynchronous stuff.
Jan BrašnaI share your concern over AJAX leading to business logic leaking into the client. I don’t want to be alarmist, but it appears that the first theft of an AJAX application has occurred. I’m referring to the Snipshot-Cellsea controversy. Snipshot, for those who don’t know, is an AJAX-based image editing tool. Cellsea seems to have lifted the code for Snipshot and added some more functionality. Snipshot, note, is not open source.
This isn’t the end of the world, but hopefully folks will start being a little more careful before putting their crown jewels out there for everyone to see.
Dietrich KappeComments are closed for this entry.