Previously:
Atlas at last-Part I: Getting down and dirty with JavaScript

The following text is my own take on the AJAX/Atlas future, and DOES NOT reflect any future Microsoft strategy.

Lets face it; web sites today, regardless of the technology they've been built on, do not come even close to providing the utility envisaged and hyped about in the Dot Com era. Though the future outlook initially looked very promising for e-learning, e-business, and e-everything, the reality has been very different. And so, as it happens, once in a while a technology comes along that holds the promise of changing something that we have become so accustomed to that we don't realize needs fixing. Question is, does AJAX fall under that category? Certainly not. AJAX, as time will tell, is not an end, but a means to an end. AJAX (and all its implementation frameworks) will do nothing more then allow the idea of asynchronous call-backs to the server without mandating a page refresh to gain acceptance. This would enable a much richer class of web applications then ever before. The trade-off to this, however, is a much longer inital loading time for the page.

Imagine having to tune your television to the channel you want to watch everytime you want to watch it. Isn't that what has been going on for so many years the internet has been in existence; the whole page refreshing just to display a message on a small portion of the webpage.

Going with the analogy of television, imagine turning on your television and seeing a "Loading...Please wait" message on the screen. Isn't that what AJAX would put web surfers through when the page loads for the first time? If you happen to have a slow internet connection as I do, it would take a couple of "manual" page refreshes just to see the whole UI on the screen, hopefully without a JavaScript error appearing in the web browser's status bar. Thankfully, such considerations will not slow the buzz that has been generated in web developer circles since the advent of the AJAX approach.

Getting back to the point I made about asynchronous call-backs and initial loading time above, developers and users/surfers alike would attune to the idea of longer initial loading times just so they get fast responses and a richer experience once the UI has loaded; communicating with web services asynchronously without whole round-trips to the server and complete page refreshes.

For the time being, that looks like the change we will be seeing in websites. However, if you think that the story ends there, think again. For the Web 2.0 idea to become a reality, and not fade into oblivion after a while, the web has to be a platform. That would put more pressure on the web browsers, since no one would want to see one website work on IE and FireFox but break down in Opera. These unresolved issues are still in abundance as companies move to invest in web applications that would make use of the AJAX approach.

How do we move forward then? What does the future hold for AJAX and Atlas? Well, to answer these questions, architects and developers would need to focus on the Smart Client paradigm. The biggest benefit Smart Clients have is that they only need to be installed once on the client PC after being downloaded from the Internet (Click Once deployment). This would allow the application to be used without visiting any website again and wait for the UI to load. The reason the Smart Client model was sidelined (by AJAX) was because it killed the web browsing experience; it did not function inside the web browser, but instead appeared as a stand-alone application. To cut a long story short, for the next generation of web applications, 3 things are of utmost importance:

1. Responsiveness (brought about using communication with web services)


2. Rich User Experience and UI


3. Least or No download time

Uptill now, only the first of the 3 above has been addresed by the AJAX approach. The only way I see 2 and 3 (along with 1) becoming a reality is with XAML and Windows Presentation Foundation (WPF). XAML or eXtensible Application Markup Language in its current form still has a long way to go, but it does hold a promise, simply because it has the capacity to encompass a lot of UI logic declaratively (using tags) without any scripting language. Hence, the next generation web applications UI's would be developed in tools such as Microsoft Expression Interactive Designer, and exist as WPF Express applications. The third point of least or no download time can be made possible by caching the XAML UI after it has loaded into the web-browser so that it does not need to download the next time the user visits the site. Webpages are kept in the browser's cache even now, but that serves no purpose in making the next visit to that page more responsive. Some might argue the need for keeping large amount of UI data in the web-browser's cache even if the surfer may be visiting the site for the first and last time; to which my answer would be: You keep the phone number of the people you call frequently stored in your cellphone so that you dont have to memorize them, or even dial them everytime. However, even if you make a call to someone for the first (and possibly last) time, even then, that number remains in your cellphone's memory for some time. So, web-browsers may prompt the users if they want to keep the UI cached so they dont have to download it again in the next visit. Ideally (and for good reason), web surfers would keep the websites they visit frequently cached in their browsers. What a surfing experience that would be?!

For now, the idea of declarative programming will gain wider acceptance in the web developer community as they use tags in Atlas to bind UI elements to data or extend existing web controls with control extenders. If nothing else, one thing is certain; JavaScript is back from her death-bed (if not her grave), and has become something for companies to explore and take seriously for the next couple of years.

See you at the Pakistan Developers Conference 2006