Desperately seeking: More AJAX developers

Desperately seeking: More AJAX developers

Summary: 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.

TOPICS: Browser

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.

Topic: Browser

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • I like it!

    I usually rail against the proliferation of new computer languages, but this one is more of a morph of some older ones. I was all signed up for a javascript class - when it became no longer available (at Company "F"). I was bummin, since I wrote a client-side browser script using Netscape and perl (and Netscape and bourne shell). No net connectivity required! I WANTED to do this in javascript - but the resources out there STINK! (at least they did a few years back). I felt that ALL GUI scripts/tools that were developed locally should use the SAME INTERFACE - the web browser (No Tcl/Tk, no SWING, no ...). This AJAX JUST may do the trick . . .
    Roger Ramjet
  • AJAX sounds interesting but...

    ...the description of it reminds me of the old web architechture of the 90s: C/C++, PERL, CGI, before Java (and now .Net) and application servers took over. CGI was used to relay requests back and forth, PERL was used to parse requests, forms data, and probably create the response pages, and C/C++ was used to do the data access. These technologies were cobbled together to create what are now called application servers. I suspect that if AJAX takes off, in a few years someone will encapsulate it and create a client-side technology that does essentially what AJAX does without the need to take technologies with their own domains and make them work together. If I were to make a prediction it would be one of the browser makers who does this, adding functionality that makes this dynamic interactivity easier to create.
    Mark Miller
  • Adobe and Macromedia

    Graphics drive the web. It's a magazine. Vector graphics have
    proven to be a more efficient and more decorative way to populate
    the page. Why this endless retrofitting of a technology that is now
    as old and outdated as html. The Adobe/Macromedia merger has
    consolidated the power of content creation around the gold
    standards of authoring tools. The standards are set by print and
    video, not the current web. Advanced programmable functionality
    is now available in Flash. What difference will the use of a plug-in
    make, when the plug-in becomes the browser?
    Harry Bardal
    • When FireFox wants to load Flash

      I ignore it . . .
      Roger Ramjet
    • flash is not for serious programming

      it kills me to find people that never were able to understand
      html, css, javascript, dhtml (the building blocks of web
      programming) and because they are unable to use more
      advanced tools they end up building in flash or dreamweaver ot
      other tool for beginners.
      Can you imagine a serious web site builded in flash? PURE

      • More Nonsense

        It has become my opinion, that serious programmers build
        authoring tools, not web sites. The Adobe Macromedia merger will
        provide authoring tools with increasingly turn-key solutions for
        content creation. The reinvention and retrofitting of the wheel will
        come to a halt at some point soon. The distribution of pictures and
        Words, that's we are talking about here. it never was supposed to
        be rocket science. E-commerce solutions exist now in droves. My
        hat is off to those prepared to administer the internet's plumbing.
        More power to you as you continue to build serious web sites.
        Harry Bardal
    • Bull!

      Because Flash doesn't have the flexibility to completely run a webmail client, and even if it did, the application would be too large to use. Besides, these technologies have been around for quite a long time, and we all know they WORK, period.
      What you are proposing is like saying we should all ditch ANSI C, C++ and the like, because they're not as good as Visual Basic.NET.
      Try and say that, and probably most of the posters in the talkback will seriously consider doing you some harm.
      Plese get real, and know your facts before posting
    • A lot of people HATE Flash web sites....

      I know I sure do, and I often hear this sentiment expressed by others. Many people have told me that they refuse to use Flash web sites. In addition, they (and I) become extremely annoyed when they have to look for content on a web page with dancing graphics and other distracting crap on the screen. It's kind of like trying to read a newspaper while someone moves a flashlight beam around on the page your reading.

      Sorry, but this "gold standard" is nothing more than costume jewelry in my opinion. Yes, being annoyed by a web site is the fault of the "programmer" (for lack of a better word), but the fact is that there are far too many idiots using Flash on their web sites.
  • JavaScript is pain for complicated program

    This requires using JavaScript for all UI (not HTML generated on server using real programming languages). Script is always script - no compiler to detect mistakes. Minor mistakes can cost you days of work. The idea is cool, but the method practically does not scale!
    • It ain't what you do it's the...

      way that you do it.

      ..This requires using JavaScript for all UI...

      No it doesn't.
      The JS looks after the async comms to a webservice and marshals the returned payload for redering - XML/XSLT for example and the output of the transformation would be our old friend, HTML.
      GMail uses lots of script for spell checking etc and it seems to scale but it is a pain to develop JS.
      Maybe some bright spark will come out with a better JS dev tool than Notepad technology.

      • There's a better development tool than notepad!

        It's called O'Reilly + notepad :-P
  • yeah, right

    clearly the author has never spent days working with javascript trying to overcome its failings and to get it to do what you want. i call it 'javascript hell'. plus you have to know which pieces of the language each browser version supports and there are a lot of browser versions out there. you do have to draw a line somewhere. ajax sounds good, but try it before you commit to it.
  • plugin is required

    Atleast in IE you have to have microsoft's XML parser installed.

    I don't know if Firefox uses that under the hood or not tho.

    And javascript isn't exactly an elegant solution, altho you could just use divs/iframes and .innerHTML and spit the appropriate HTML out the backend? Loverly!

    Wouldn't it be easier just to use virtual terminals and run rich client applications? :P
  • Ajax

    I wish this was true, one should be capable of creating client/server apps in a browser, Asynch with XML Ajax is a great first step, but until someone creates better html/javascript/Ajax debugging/development tools it will stay in infancy.
  • Software Development Tools Needed

    AJAX can provide useful effects, but what if I'm not prepared to write such a JavaScript-heavy application?

    Check out <a href="" target="_self">PowerWEB LiveControls</a>. These ASP.NET Web Controls exceed AJAX functionality in many ways, but places the logic server-side instead of on the client. The controls automatically generate JavaScript that updates client graphic elements from server-side code.
  • Finally

    I have been working with the Ajax technologies on my site for four years and I been concerned that Microsoft would block the technologies that we use to make it work (security concerns). Now that there is wider acceptance of the techniques we can be more confortable using these technologies.
  • Not new. Question remain

    The idea is again a front end and a back end.
    Java has the potential to do it and still do.
    One big question is how you distribute work load
    between client and server. How you best use
    the available power on both end. With a Win31
    as client, you can't do much on the client

    Except that the whole thing is based on javascript, the idea isn't new. But just think. When demand increases, this will be just another
    Java that take time to download the code.

    So. Yes, I think there will be engine code that user would like kept at local instead of download
    it when needed - sort like Java run time.