Ajaxion - Standalone Ajax - Part 1 of 2 - Agile, Lifecycle, Web Design, Server Side, C#, Java

Introduction

This article discusses how to build Web applications of the future relying on the current standards.

Part 2 of this article presents a C# and Java example about what Standalone Ajax may be.

Background

Around January 2007, I was reading an article about the possible technology trends during 2007. One trend was identified as having the Ajax standalone - not needing any more ASP or JSP or PHP or other usual Web technology. Since then, I haven't seen great progress about this "Standalone Ajax", so I decided to give it a shot myself.

Doing Ajax enabled pages within my ASP.NET projects is not a convenient task sometimes even if I use great libraries like MagicAjax. Why bother with the viewstate, how about not needing it at all?

Let's have an Ajax standalone - in a simplified vision: static XHTML, JavaScript Ajax call layer, and service oriented server-side. Such an approach will perfectly fit with Agile, TDD, Web design... and will bring very close from the start the service oriented architecture for the server side!

A Story on the Web SDLC using Standalone Ajax

Let's say we need to build a Web application based on some initial discussions that end up by not giving a clear overview of the functionality (as usual), so you can build first at most an incomplete skeleton.

• A first step would be to unleash the team members having the best understanding of the requirements so far to quickly build a static XHTML Web site... that can also contain the Web design basics and believe me, the Web designers will love to touch only plain clean XHTML... and one nice banner can dramatically improve the look of a prototype with great impact on the audience!

• We are in the first Agile splint... now go quickly to meet the client and present the static XHTML that you have so far... with more than 80% of the basic functionality idea... the client will love it and is very likely to get more involved helping you to understand and gather more of what she or he really wants, rising ASAP concrete questions not only promises and deadlines. A very important point is to identify ASAP the parts clear so far and try to get the client approval along with raising questions to clarify the remaining issues... most of the time the client needs to achieve a better structure for its own processes before it would make sense to have custom software... The sooner you get better requirements, the lower the costs will be. Why build documents that nobody reads with meaningless screenshots of some previous version? Most of the clients want to see something before getting really involved. It would be great to provide ASAP a live Web site and let the client play around and get the feeling... and it would be only the static XHTML... that you will use further in the development - not some boring "Word document" that will make all developers sleepy... and your client as well.

• Having now most of the functionality clear and an already "moving" Web site, it is time for further Agile splints. It is already time to go further with the Web design on the live XHTML - you don't have to bother the Web designers anymore with some ASP or JSP or PHP since they usually like XHTML, CSS and "Photoshop" and also you don't have to drive the developers crazy to reproduce some Web designer "crazy ideas"... nice on XHTML but scary from within the "X" Server Pages script. Just refine the Web design and add the Ajax call layer, the guys doing those don't even need to be in the same room... not that good communication is bad, I only want to point the loosely coupling components "extended" idea.

• The server side... as soon as you understand how the database can be and what business logic you may need (even in the first splint in parallel with the rapidly growing static XHTML presentation), start to build a server side call skeleton with methods returning even test hard coded values and, why not, with their unit tests that will greatly help during further phases when the client will change his or her mind a lot... The goal is to supply ASAP the server side to support the first Ajax calls... from an already good looking Web site... and go to the client again... he will be thrilled about how fast his software grows tailored to his needs... and will pay attention to clarify all that you need.

• Now it is mostly clear what to do so just refine the database, the call layers, the validations, the design and you can do all this in parallel because the Web designers will use the XHTML, some of the developers JavaScript and some C# or Java and some SQL scripting or some ORM... The key is to bring from the server the least amount of HTML possible, to mostly exchange data.

• And if the client suddenly discovers that will have 1000 times more hits than expected... just deploy the server side on some big WebLogic cluster and you are done.

Points of Interest

• Avoid requirement document overheads, allow the functionality to be clarified on live components: what you see is what you get, the best approach to "get" the client.

• Fancy Web design is no longer a problem for OOP developers, that may be better with optimizations and logic and get finer specialized, focused on the logic.

• Be focused on writing loosely coupled services and render the least HTML you can - HTML should be static, it is only a matter of how you design the application. Why waste server resources to render "dynamic HTML" when you mostly don't need it?

• Keep the Ajax JavaScript layer simple, you need to mostly use document.getElementById and innerHTML. Also be aware that you do not bloat the Web server with Ajax calls...

• Try to involve TDD on the server side and... the Ajax JavaScript layer should be highly testable too - remember, the client will discover new "desires" right before the deadline... and how else can you rely on easy regression tests?

• XML is great if you can reduce the database complexity or even if you may need to apply some XSL, but don't overuse XML. Standards are good but you may not need WS and SOAP, a simple HTTP servlet is already a service. Not drowning in technology can greatly reduce costs.

Hope this helps.

History

• 8^th July, 2008: Initial post