March 2008 - AJAX - Not Just A Household Cleanser
By Scott Kerr
Whether you've used Outlook Web Access, Google Maps, Gmail, or Courthouse JMS, you've used it. Not AJAX the cleanser, but Asynchronous JavaScript and XML. AJAX enables "behind the scenes" communication (that's the Asynchronous part) between a Web page and its Web server so that only a small portion of a page needs to be updated when you interact with it. In short, AJAX gives Web applications the kind of responsiveness that users have come to expect from desktop applications.
We use AJAX in Courthouse JMS to render fast data entry windows so that users can quickly enter commonly captured data. We also use AJAX to render quick menus for frequently used functions like excusing, disqualifying, and deferring jurors, or printing documents and letters. AJAX also streamlines page transitions in Courthouse JMS. In most instances, instead of a page "post-back" - that eye goggling event where a Web page refreshes - users of Courthouse JMS see a quick flash of gray while the page refreshes only those areas where data changed.
In 2006, in his article "AJAX is the Future of Web App Development", Thomas Powell of Network World declared that "AJAX is unequivocally the future of Web application development." Why the bold prediction? AJAX-enabled applications provide the best of two worlds. First, they eliminate the costs of distributing, supporting, and maintaining "installed software" on many desktops in many physical locations. They rely solely on the browser. There is no client software to install, no browser add-ons or plug-ins to download. Second, they provide richer, desktop-like user interfaces that increase interactivity, speed, functionality, and usability.
So, if you are under the impression that history is repeating, that today's Web applications are analogous to mainframe applications of 20 years ago, think again. The desktop is not the new "dumb terminal." And accordingly, limited-memory, limited-CPU environments simply won't cut it in today's Web which very much realizes Powell's '06 prophesy.
In the old Web, developers didn't have to be too concerned with workstation specifications. There was a limit to what could be done in a browser and so the class of client machine accessing a Web application was of limited consequence. Browser version and cross-browser performance were more the object of obsession. In the eyes of Joel Spolsky, founder of Fog Creek Software, this is still true, "Except in one place: JavaScript running on browsers in AJAX applications". As Spolsky points out, it's not uncommon for today's AJAX applications to push 1 MB or more of JavaScript code down to the browser for processing there, on the "client side". This requires RAM, CPU cycles as well as bandwidth. Says Spolsky, "And since that's the direction almost all software development is moving, that's a big deal."
What's a court to do? Be prepared. Realize that when you implement an enterprise-class Web application, it's not likely a simple page-based model. And it most certainly won't be in the future.
By Scott Kerr
Whether you've used Outlook Web Access, Google Maps, Gmail, or Courthouse JMS, you've used it. Not AJAX the cleanser, but Asynchronous JavaScript and XML. AJAX enables "behind the scenes" communication (that's the Asynchronous part) between a Web page and its Web server so that only a small portion of a page needs to be updated when you interact with it. In short, AJAX gives Web applications the kind of responsiveness that users have come to expect from desktop applications.
We use AJAX in Courthouse JMS to render fast data entry windows so that users can quickly enter commonly captured data. We also use AJAX to render quick menus for frequently used functions like excusing, disqualifying, and deferring jurors, or printing documents and letters. AJAX also streamlines page transitions in Courthouse JMS. In most instances, instead of a page "post-back" - that eye goggling event where a Web page refreshes - users of Courthouse JMS see a quick flash of gray while the page refreshes only those areas where data changed.
In 2006, in his article "AJAX is the Future of Web App Development", Thomas Powell of Network World declared that "AJAX is unequivocally the future of Web application development." Why the bold prediction? AJAX-enabled applications provide the best of two worlds. First, they eliminate the costs of distributing, supporting, and maintaining "installed software" on many desktops in many physical locations. They rely solely on the browser. There is no client software to install, no browser add-ons or plug-ins to download. Second, they provide richer, desktop-like user interfaces that increase interactivity, speed, functionality, and usability.
So, if you are under the impression that history is repeating, that today's Web applications are analogous to mainframe applications of 20 years ago, think again. The desktop is not the new "dumb terminal." And accordingly, limited-memory, limited-CPU environments simply won't cut it in today's Web which very much realizes Powell's '06 prophesy.
In the old Web, developers didn't have to be too concerned with workstation specifications. There was a limit to what could be done in a browser and so the class of client machine accessing a Web application was of limited consequence. Browser version and cross-browser performance were more the object of obsession. In the eyes of Joel Spolsky, founder of Fog Creek Software, this is still true, "Except in one place: JavaScript running on browsers in AJAX applications". As Spolsky points out, it's not uncommon for today's AJAX applications to push 1 MB or more of JavaScript code down to the browser for processing there, on the "client side". This requires RAM, CPU cycles as well as bandwidth. Says Spolsky, "And since that's the direction almost all software development is moving, that's a big deal."
What's a court to do? Be prepared. Realize that when you implement an enterprise-class Web application, it's not likely a simple page-based model. And it most certainly won't be in the future.
