Desperately seeking: More AJAX developers

If you're a developer or a developer-wanna-be and you're trying to catch the next big lucrative wave of programming, I'm convinced that AJAX (aka: Asynchronous Javascript + XML) is it. This morning, I was reminded of why.

If you're a developer or a developer-wanna-be and you're trying to catch the next big lucrative wave of programming, I'm convinced that AJAX (aka: Asynchronous Javascript + XML) is it. This morning, I was reminded of why.  More on that in a second.  The best description of AJAX that I've found comes from Adaptive Path's Jesse James Garrett.  In his primer on the interactive Web programming technique, Garrett wrote:


An Ajax application eliminates the start-stop-start-stop nature of interaction on the Web by introducing an intermediary — an Ajax engine — between the user and the server. It seems like adding a layer to the application would make it less responsive, but the opposite is true.

Instead of loading a web page, at the start of the session, the browser loads an Ajax engine — written in JavaScript and usually tucked away in a hidden frame. This engine is responsible for both rendering the interface the user sees and communicating with the server on the user’s behalf. The Ajax engine allows the user’s interaction with the application to happen asynchronously — independent of communication with the server. So the user is never staring at a blank browser window and an hourglass icon, waiting around for the server to do something.

By the way, no plug-ins are required to achieve this level of interactivity.  A lot of experienced Web programmers will argue that AJAX has been around for a while, just under a different name (XMLHttpRequest).  But the XML culture really needed to hit its stride before something like AJAX that relies on it could take off.  That time has come and Google has turned a lot of heads with its implementations of AJAX.  Garrett explains:

Take a look at Google Suggest. Watch the way the suggested terms update as you type, almost instantly. Now look at Google Maps. Zoom in. Use your cursor to grab the map and scroll around a bit. Again, everything happens almost instantly, with no waiting for pages to reload.


Google isn't the only company using the technique. Another incredibly forward thinking company that's looking to relieve organizations of their addiction to Microsoft's difficult-to-unseat Outlook/Exchange Server/Windows Server trifecta -- Scalix -- has built a highly interactive, fully browser-based Outlook-like e-mail client using the same techniques.  After getting a demonstration of it, one can't help but say "All this, in a browser, with no plug-ins? Remarkable!"

The absence of plug-ins to achieve these sorts of levels of interactivity may be more special than most people know.   Because a plug-in that's written for Internet Explorer doesn't just plug in to Firefox, there are plug-ins that exist for one browser, but not the others.  Developers of non-Microsoft browsers as well as those of the plug-ins have had to jump through hoops to ease the pain on end users who want the freedom to pick a browser (or a non-Windows operating system for that matter), rather than be forced into using one because of differing plug-in architectures and APIs. 

Incompatible plug-in architectures aren't the only culprits to have foiled our hopes for an interactive Web experience that seamlessly works across all browsers.  Dynamic HTML (DHTML) -- another widely deployed technology for making Web pages a bit more interactive with things like exploding menus -- also comes in multiple flavors that don't work across all browsers.  Books like this one that are dedicated to understanding how to take advantage of proprietary DHTML (and Cascading Style Sheets, another compatibility sore spot) are also teaching Web programmers how to lock out some users (or force them to use a technology they don't want to). 

The last time I read an O'Reilly book on Javascript cover-to-cover and followed its examples, the examples worked across all browsers.  In fact, it has always been Javascript that has helped to resolve incompatibilities between browsers.  As the only true standard (the standard is actually called ECMAScript) for client-side Web scripting, Web authors invariably used Javascript to figure out what browser was in use by each user of their site (down to the version level since there were incompatibilities between versions of the same browsers), and then branch off to the appropriate HTML to ensure that those users got the same user experience (or one that was a close as possible) regardless of which browser they were using.  And fortunately, Javascript is one part of the Web infrastructure that Microsoft, much as it tried, was never successful at embracing and extending with its Internet Explorer-specific technology known as JScript. 

One reason Microsoft probably gave up on the idea is that Javascript was never really regarded by anybody as being super strategic to domination of the Web and/or dynamic/interactive browser-based applications.  More strategic to both Microsoft and Sun were technologies like Java, ActiveX, VBScript and Active/Java Server Pages (ASP, JSPs).  But now that the XML culture has matured and AJAX is on the scene, Javascript is enjoying a bit of a resurrection.  Not only is it fueling a reinvention of interactivity, but its cross-browser standard nature is ensuring that the resulting user experiences are available to all, regardless of browser. Boy, talk about your comeback kids.

AJAX represents a huge opportunity to different communities within the Web industry.  First and foremost, if you're running one of those sites that has browser compatibility issues and that could also benefit from a more interactive user experience, then you should be giving AJAX a long hard look.  I was reminded of this today when, in the process of testing the Cingular flavor of RIM's Blackberry 7100 (the 7100g), I visited my Cingular Blackberry Web Mail account with Firefox only to receive the following error:


I cropped it for fit and what you can't see is that older versions of Netscape are listed as compatible versions too.  But the point is clear.  I need to switch to a technology that I don't want to use (or in the case of the older versions of Netscape, don't have) in order to make use of the site.  Assuming that RIM's partners (Cingular, T-Mobile, etc.) would want to make Web mail available to all of their customers regardless of their choice of browser, and given that e-mail is precisely the sort of Web-based application that can use a bit more in the way of interactivity (as demonstrated by Google's GMail), RIM is the perfect example of a company that needs to understand AJAX and get with the program.  My guess is that RIM is not alone.  There are thousands of others.

And therein lies an opportunity for one of the other Web communities: developers.  Most Web developers are pretty handy with Javascript.  But only for light scripting work.  Many of them can code HTML in their sleep, and the more experienced ones can build some exciting stuff based on Java, .Net, and other server-side programming environments such as Perl, Python, or PHP (the "P" in "LAMP": Linux-Apache-MySQL-P).  A lot of these talented people are also having difficulty finding work.   By way of outsourcing -- either to ASPs like or to India -- the need for their services is dwindling. And it's worse for senior IT people who must return to their programming roots to just to put food on the table,  but whose last language was C or COBOL and whose last line of code hearkens back to a time when code was neither network-aware nor object-oriented. 

In addition to getting mail from these vets, I also get mail from newbies, including high school students whose parents are telling them to make a career out of tech.  They all ask the same question: What programming skills will make me most marketable tomorrow?   For a while, I answered this question with Java (all flavors... mobile, desktop, and server).  But proficiency in Java alone wasn't enough.   Since Java often interacts with other entities such as databases, Web pages, and Web servers,  some solid background in those areas was required as well.  For a long time, you couldn't go wrong with Java and I still believe that it's a safe bet.  

Recently, when I've recommend the aforementioned Java soup, I also toss XML and Web services into the soup.  I advise people to build and experiment with applications that involve interactions between Java and .Net because, as services oriented architectures really begin to take off and companies start to realize the benefits of integrating their systems with other systems (including ones external to their own),  the people with proven skills in getting those two environments working together will rise to the top.  Knowing the LAMP stack can't hurt either.  Because of how versatile the language is, a good PERL programmer can still make a killing these days.   And for you C/C++ jockeys out there, have you noticed how some of the biggest and most interesting companies to work for are hiring the creme-de-la-creme out of the open source world?  One way to get noticed is to get involved as a very visible contributor to the most visible projects.

Today, after seeing what companies like Google and Scalix have done, I'm adding AJAX to the list. According to a company spokesperson, "RIM has plans to add support for Firefox and Safari and plans to roll it out in the fall.  RIM is looking into AJAX but cannot confirm any plans at this time." If companies like RIM aren't waking up to the beauty of AJAX, they darn well should be.    When they do, there will be a vacuum of developers who can help those companies go from 0 to 60 in 4.2 seconds (which is what they'll need to do in this wacky Web world).  Ones that really know AJAX best practices (for example, with a lot of older browsers and non-AJAX capable kiosks still out there, what's the fallback plan?).  If that doesn't spell opportunity, I don't know what does.