Ajax Architecture
The popularity of Ajax and the trend towards richer user interfaces changes the way applications work, and that means we need to check that that the software architecture we are using will still fit in a more Ajax world. Your combination of frameworks and libraries and jar files may be good for now, but what about tomorrow?
I nearly called this blog-entry Extreme Ajax because it is about looking at where Ajax pages are headed and taking it to an extreme. XP-stylee. But Extreme Ajax sounds like I'm trying to start a movement or something. I'm not.
The trend
The trend is that the browser does more of the work that the server used to do. For example:
- HTML might be generated using XSLT on the client rather than JSPs/ASPs etc on the server.
- Data is loaded from the server using Ajax and the web page altered using DOM manipulation and innerHTML.
- Visual effects to guide the user are processed in Javascript rather than in JSPs and ASPs.
In all of these examples the trend is for less JSP/ASP etc and more Javascript. So lets take that road to an extreme and see what we get.
Well clearly road ends up with us replacing JSP/ASP and all our MVC web-frameworks, WebWork/JSTL/JSF/etc with just HTML and Javascript.
Outch.
The data is fetched from the server using Ajax via something like DWR or Ajax.net, and dynamically inserted into the page using Javascript. The server becomes responsible for serving data and not specially crafted pages. Then libraries like script.aculo.us and Trim Path help you create fancy looking pages.
So if that's the road the Ajax revolution is taking us down, are we going to like it when we get there. Do we ask to get off the bus now? How do web applications in this extreme Ajax model compare with web applications now?
User Experience – Speed
This type of application is much faster than traditional web applications for 3 reasons.
- The first big speed jump is in better use of the browsers cache. Since the majority of the volume of the site is static HTML/Javascript the browsers cache can to a much better job of saving network bandwidth.
- The second big speed hit is that when you do need to hit the network, all you are transferring is data and not customized pages. For many Ajax applications, requests can happen in a single network packet which helps with network latency too.
- The third big speed hit might be on the server. Since the client is taking a significant computational role in generating the final pages the server can get on with managing data and logic rather than manipulating web pages. This does assume that you're not swamping the server with millions of tiny Ajax requests every time the onNeuronFire() event gets called, but that's down to good design.
The second 2 of those points are a feature of all Ajax web applications, but the more you go down the road the more you reap the benefits.
Development (Libraries/Tools)
The proportions of time spent developing the view, logic and data parts of any web application vary. The more extreme Ajax way of doing things means that we will spend more time writing Javascript and less time writing JSP etc. So the down-side is that our development tools like Eclipse/Intellij/Netbeans etc have only just got properly into HTML/JSP editing. What we need is Javascript re-factoring. Intellij looks like it might have a slight lead, but it's not worth writing home about. The up-side is that traditional web page editors like Dreamweaver are going to work a lot better in the Ajax world.
One of the big issues with many web frameworks is all the tedious mucking around with config files and implementing interfaces. With tools like DWR and Ajax.net you can forget all of that tedium.
Accessibility
The short answer is that I don't know, and I suspect none of us really knows how Ajax and Accessibility will pan out. Ajax is just plain broken if Javascript is disabled. So this currently rules out sites with heavier security requirements and people that use Lynx. My guess is that Javascript will become so pervasive that the number of people that turn Javascript off (or have it turned of for them) will go down.
There is also no good reason why Lynx (and other text mode browsers) can't get down with this new Javascript craze. Just because they render text-only doesn't mean that Javascript is impossible. So maybe Lynx or it's cousin Links will enable text-mode Ajax browsing?
Currently I understand that some screen readers like JAWS for example work just fine with XHR and friends from an execution point of view (it's just a browser plug-in after all), but are erratic when it comes to reading out dynamic text. I'm no expert, but I would guess that screen readers could get to the point where they can read out dynamic text properly.
I don't mean to blow aside concerns about accessibility in an extreme Ajax world, there is clearly some work to be done. But my guess is that we can make strides to overcome the current obstacles.
Other Issues
What other issues are there? And is this a world you want to live in either as a developer or as a user?
Technorati tags: ajax architecture dwr