Wither Away Ajax?

Dare Obasanjo has wrung the death knell on Ajax, but I disagree with him on several counts.

He writes:

Most people who’ve done significant AJAX development will admit that the development story is a mess. I personally don’t mind the the Javascript language but I’m appalled that the most state of the art development process I’ve found is to use Emacs to edit my code, Firebug to debug in Firefox and attaching Visual Studio to the Internet Explorer processes to debug in IE. This seems like a joke when compared to developing Java apps in Eclipse or .NET applications in Visual Studio. Given how hypercompetitive the “Web 2.0″ world is, I doubt that this state of affairs will last much longer.

There is an Eclipse plugin for JavaScript development (actually, more than one), and that’s only one of many JS development tools. I tend to use text editors and Firebug because I’ve found both to be sufficient for my needs. All you have to do is search on “edit JavaScript” to pull up a host of free, open, and/or commercial tools to simplify JavaScript editing. This is in addition to the graphical tools for working with SVG and Canvas.

As for Firebug, I think that Dare sells this application way too short. With Firebug I can not only inspect a web page contents, stop a process and inspect programming constructs, drill into the CSS and markup, investigate what’s taking so long for the page to load, and review responses back from Ajax calls, I can see the document object model at a glance, and how all these little pieces pull together. I’ve worked with a host of desktop tools: none has ever had the ability to drill into every aspect of the application as much as Firebug allows me to do so with a simple web page.

Dare also writes:

There is too much pressure on Web companies to improve their productivity and stand out in a world full of derivative YouTube/MySpace/Flickr knock offs.

Yes, but why did all of these become so popular? Because they’re all accessible using something that everyone has: a web browser. There’s nothing to install, other than the ubiquitous Flash plug-in. There’s nothing proprietary about most of the technology used. These applications work with most browsers, except perhaps the older Internet Explorers or Netscape 4.x. Even then, most work with operating systems and browsers that the companies that provided both dropped support for years ago.

In fact, Ajax, rather than being a technology that’s heading out the door, could actually be one of the few open doors left for the people who have not been able to buy that new Macbook Pro, or dual-processor Dell machine. Microsoft, Sun, Apple, Adobe–any one of these companies would leave the less affluent in the dust in a heart beat. The web page is the great equalizer on the internet.

I do somewhat agree with Dare, in that desktop development systems that incorporate Ajax-like technologies, such as JavaScript, will grow. I imagine that Flash/Flex, OpenLaszlo, and WPF/E will get a following and do well. But their health is not negatively correlated with the health of Ajax, with one gaining only at the expense of the other.

Ajax isn’t just a name or a set of technologies: it’s a way of pulling out as much functionality as can be pulled out of a web page as possible. The desktop applications such as Google’s office killers get a lot of the publicity, but the real power behind ‘Ajax’ is little things like comment live preview, Flickr’s in-place edits, or WordPress’ expandable form elements. It’s deleting a row and not having to re-find your place as the page loads. It’s zooming in on a picture, mapping out a route on a map, live updating unread feeds, and a host of other ways of Doing Things Better.

If there’s anything to worry about with Ajax is that sometimes accessibility and validity of web page contents are sacrificed for ‘cool effects’. That, and the hype. By hyping Ajax as a ‘thing’ than it becomes easier to dismiss that ‘thing’ in favor of other ‘things’. But the concepts, effect, libraries, tool, techniques, go beyond being just ‘a thing’–it’s just the way web development will be done in the future. You can no more say that its day is done, as you can say that the hyperlink is old and therefore passè.

Dare also mentions about Java being the most used language today. Frankly, I doubt that it is the most used language. I would say that JavaScript is the most used language, followed closely by PHP. Java is most likely the most used for corporate development, but I don’t think it can compete with all the folks running simple little PHP applications just to upload their photos. Or post thoughts online, like this one.

For every person using a WebLogic or WebSphere application, there’s ten thousand webloggers using WordPress. For ever consumer of EJBs, there’s a thousand people using Gallery. For every web site that runs off Tomcat, there’s a million, or more, running PHP, Perl, Python, and Ruby. Google and Yahoo big users of Java? MSN the same with .NET? None of them would be anything without the millions, billions of simple web pages the rest of us produce.

Now is when things are really starting to get good. More web services, more semantics, more agreement among the browser developers, advances in the technology–better graphics, better JavaScript, better CSS and markup, and interesting twisty new ways of bringing it together…give it up? Not likely.

Of course, I’m finishing up a book on Ajax, and it’s natural I’ll say these things. But I didn’t write this book for the Mega-tool developers, the Kool Kids, or those who seemingly want to replace Photoshop or Office with online tools. I certainly didn’t write it to support the la-la land that is Silicon Valley, or the megapolis that is Microsoft. I wrote the book for the webloggers and the Gallery users; the folks running an online store, a corporate site, or an online publication; those digging after knowledge, and the knowledge providers; those who come to the web to teach and those who come to learn. Saying Ajax is ‘going away’ makes as much sense as saying all of these are going away.

This entry was posted in Technology. Bookmark the permalink.

9 Responses to Wither Away Ajax?

  1. I think we agree more than we disagree. My comments weren’t a diss to Emacs or Firebug, both of which are the cats pajamas. My point was that it is not an integrated development environment. Where is the Firebug for IE? How do I integrate my JavaScript plugin in Eclipse with Firebug? This is the kind of thing you take for granted in modern development environments [including Emacs for the things it is good at].

    >in [t]hat desktop development systems that incorporate Ajax-like technologies, such as JavaScript, will grow. I imagine that Flash/Flex, OpenLaszlo, and WPF/E will get a following and do well.

    But these aren’t desktop development systems. These are systems aimed at building a better Web development platform than what we have with DHTML (i.e. the J in AJAX).

    Where I’m confused with your blog post is that it seems you agree that we need something better than the current state of affairs with DHTML/AJAX (i.e. your comment about “There’s nothing to install, other than the ubiquitous Flash plug-in.”) but it seems you are willing to call whatever replaces it “AJAX” as well.

  2. Shelley says:

    No Dare, I don’t agree that we need to replace anything. We’ll continue to improve the existing tools, but we don’t need to toss the environment out in favor of something else. To me that’s the strength: there’s nothing that needs to be installed.

  3. Scott says:

    Dare and Shelley,

    Check out this review of Dashcode for OS X. I’ve been using the beta for a while to play around and the environment is really top notch for Javascript development.

    http://waffle.wootest.net/2007/03/05/dashcode/

    It is the most complete IDE I’ve found for Javascript based widget development.

  4. Shelley says:

    IE’s limitations are such that most are well known. I’m not going to penalize the environment just because Microsoft dropped the ball with IE. I develop, test, and debug in Firebug, and then I test in other browsers, and on other machines. This is no different than developing with VS on one machine, but then testing it on a host of others. Or developing with Java and having to test in a host of environments.

    Developers have always run into this challenge when testing and debugging.

    PS Scott, thanks for the link to the development tool.

  5. Steve says:

    Incidentally, there is a version of Firebug for IE: http://www.getfirebug.com/lite.html

    It’s not perfect, but it does work.

  6. Shelley says:

    Thanks for the heads up on this Steve.

  7. Peter de Laat says:

    The cause that AJAX is difficult is not just because of a lack of a proper development environment.

    The problem is mainly that browsers are incompatible, especially when it comes to interaction. This is not because ‘MS is evil’. Other browsers are incompatible too.

    While standardization works very well when the focus is on standardizing based on primitives (as in HTTP or XML), standardizing rich environments is extremely difficult. Keeping up with innovation with standards in rich environments is hardly possible. (Changes in standards are much less likely if the focus of the standard is on primitives to begin with.)

    For that reason, product platforms have won most battles in rich environments, while standardization has won most battles when the focus was on primitives.

    My prediction for the future is therefore, that a product platform will win in programming interactivity on the web. Most likely candidate is flash. If you want to offer any complex interaction within a browser, currently the easiest way by an order of magnitude is Flash. Flash means no hassles with incompatibilities.

    I also predict that RDF has a very good chance to win in the future, because it is a standard that is based on primitives.

  8. Ted Husted says:

    Libraries like YUI and Dojo neatly resolve the browser compatibility issues. All that’s missing is server-side JavaScript. We have Groovy for Java, and IronPython for .NET. Why not native implementations of JS that run server-side? Then we’d have a contiguous development environment, with JSON-RPC acting as a link between client side and server side.

    The selling point of GWT is that Java IDEs are state of the art. But everything we learned about Java IDEs can be applied to JavaScript IDEs. It’s just about having a market, and SSJS will create an IDE market beyond anyone’s wildest imagining.

    -Ted.

  9. Peter de Laat says:

    Ted Husted wrote

    Libraries like YUI and Dojo neatly resolve the browser compatibility issues.

    Such libraries have little chance in becoming a a proper development platform, and if they did, it would be a product platform, meaning dependence on the product supplier.