Does anybody understand Ajax besides Google?

Does anybody understand Ajax besides Google?

Summary: Ajax is a year old. Does anybody really understand it?

SHARE:
TOPICS: Google
26

We all know the story of Ajax and XMLHttpRequest, about how a little known feature of Internet Explorer was mostly ignored until it was duplicated in some other browsers and Google started using it in their Mail, Maps, and Suggest features. It'll be a year ago this Saturday that Jesse Garrett coined the term. Dozens of books and articles and tutorials later, I have to wonder, is this too complex for mere mortals to understand?

Consider this article about the new GTalk feature in GMail. Once again, Google has figured out how to do something that most people thought was impossible. Or look at this article about how they draw lines on top of maps. If it weren't for 'View Source', would anybody but a few wizards at Google know how to do this? And how do they feel about us learning by looking at their source code anyway?

Where I grew up we had these trees that dropped what we called "sweetgum balls" all over the ground every fall. They were impossible to walk on or even pick up without getting pricked. Developers are scrambling to pull together toolkits and consortiums and projects to get a handle on the prickly technique that is "Ajax". Will it work? Since everyone seems to want it to work very badly, perhaps. But I think most people are just going to be sporting band-aids until we're all wow'ed by a better, hopefully simpler, solution.

Topic: Google

Ed Burnette

About Ed Burnette

Ed Burnette is a software industry veteran with more than 25 years of experience as a programmer, author, and speaker. He has written numerous technical articles and books, most recently "Hello, Android: Introducing Google's Mobile Development Platform" from the Pragmatic Programmers.

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

Talkback

26 comments
Log in or register to join the discussion
  • Clearly

    Read 'Ajax in Action'.
    Clearly, Google Maps, Zimbra, Scalix, and the like demonstrate where AJAX is going and show that 'rich' functionality can be incorporated into browser-based web applications.

    But I see another 'potential' paradigm shift on the horizon which will leverage and exploit Virtual Machine (VM) and Virtual Private Server (VPS) technologies, most particularly coupled to the new 'VT' technology that Intel and AMD offer.

    Eventually, the demand will be such that getting a 'Virtual Desktop' running in a VM from the net will be commoditized and be accessible as a portal based isp infrastructure.

    How does this happen? with www.linode.com coupled to NX 'thin client' technology, one can PXE to a server VM geographically located 'anywhere' in the world at 'local' response-time speeds.

    As for myself, I have a www.linode.com account with KDE running over FreeNX and a www.nomachine.com NX Client.

    The VM Desktop market potential is large.
    I can still browse the net, securely, because NX utilitzes ssh, secure shell tunneling, and feel relatively secure that my Virtual Desktop is safe.

    See the www.linode.com infrastructure here:

    http://www.linode.com/products/network.cfm

    Sound 'futuristic'? Not so. This is now!

    From the 'future'.
    Dietrich :)
    D T Schmitz
    • Virtualization

      Virtualization will indeed be huge but I don't think it will go the way you indicate. Maybe some on the intranet.

      People moved off of VT-100 terminals for a reason. Even cheap X-windows network clients weren't that popular. I like virtualization to support different OS's on the same hardware, and to isolate big installations from each other.
      Ed Burnette
  • Where have you been?

    It seems clear to me that Mr. Burnette does not understand AJAX.

    "We all know the story of Ajax and XMLHttpRequest, about how a little known feature of Internet Explorer was mostly ignored until it was duplicated in some other browsers and Google started using it in their Mail, Maps, and Suggest features."

    I suppose the fact that Microsoft Exchange's Webmail client is nearly identical to using Outlook desktop (with all of the attendant warts :) ) means absolutely NOTHING to Mr Burnette. Or that ASP.Net stuff has done this for years as well, done to the point where components will automagically change their behavior based on how "upscale" the browser is.

    I'm not saying Microsoft is King of the Jungle here. I'm saying that Mr. Burnette obviously has not been outside of a relatively small IT box.

    The jump from doing things with the onMouseOver(), onDrag(), etc. events to adding a request to the webserver is a rather small one. In fact, it is a nearly pointless jump much of the time. If the author of this story had any knowledge of web development, network protocols, and web servers (granted, not too many people understand all three simultaneously), he would understand that the TOTAL overhead (bandwidth, server CPU/RAM, client CPU/RAM, etc.) to process AJAX requests is actually going to be about the same or higher as re-requesting the entire page with the new information in a majority of the projects out there.

    Why?

    * XML is a spectacularly dismal format. It manages to combine the raw CPU hogging of a delimited file (actually, it is much WORSE on a CPU than a delimited file, because the delimiter always changes!) with the space wasting characteristics of a fixed-length file (it is common to see XML where the tags are the same size or bigger, on average, than the data they contain).

    * HTTP is a lousy protocol for small amounts of data. All of those XmlHttpRequests that the AJAX crowd thinks are so cool are just about, bar none, the least efficient way to accomplish the task. You are building up and tearing down (with all of the incredibly demanding on a server tasks such as file authentication, user authentication, logging, tracking, blah blah blah) an ENTIRE HTTP SESSION WITH EVERY MOUSE MOVEMENT. What is wrong with you people? Why do you think that this is a GOOD THING? HTTP is a sessionless, connectionless protocol designed for the anonymous transfer of files that tend to be text and tend to run in the 5k - 60k range. HTTP creaks and groans under the weight of large file requests as well as a lot of small requests. If you don't beleive me, go read the RFC. After reading the RFC, and seeing what a web server actually does each time your stupid little AJAX stock ticker or "Hello World" or whatever it is that you think is so glorious makes a request, and you STILL think that AJAX is great, let me know; I'm getting a bit bored with my job and I think I could use yours.

    * JavaScript is a miserable language. There always seem to be small inconsistencies between browers with JavaScript. Unlike HTML, which will simply gracefully degrade and look like garbage, it will throw up errors. It's funny how even a major site like ZDNet throws up JavaScript errors on me pretty frequently, and that's before they even try to do anything fancy. The interpreters built into browsers for it are also pretty slow. Try iterating through a large object set and do a basic comparison in a web page with JavaScript, and compare its performance to just about any other language, you will see what I mean. JavaScript is difficult to write anything bigger than a few hundred or so lines of code in, plus you need to worry about a few dozen different browser/version combinations. No thanks, I'll stick to doing as much work as possible on the server, thank you kindly.

    In other words, every single component of the AJAX formula is miserable.

    "Dozens of books and articles and tutorials later, I have to wonder, is this too complex for mere mortals to understand?"

    AJAX isn't "too complex" as a concept for mere mortals to understand. But writing developing, debugging, etc. the code is a waste of time, and at best tends to produce nearly unmaintainable garbage. It's not that us mere mortals don't understand it, it's that we don't use it because it isn't worth it. For a small, simple application like Google Maps, it's fine, no complaints there. But even for something more advanced, it is worse than useless. I do blogging over at TechRepublic. They have this entry editor that does little more than let me apply some basic markups to my input. It isn't even AJAX, it is just JavaScript. If I write more than a thousand or so words, it slows my computer to a crawl with each letter I write. This is a lousy experience for me. Since I tend to write long posts (can't you tell?) I am better off writing in a plain text editor and pasting it in. This is simply for entering a blog post. Imagine trying to use some half-baked AJAX word processor? Neither can I.

    AJAX is a fine idea, but only useful in a small subset of applications. If you want to know why more people aren't using it, then maybe it's because most applications arne't appropriate to it. I know how to hit a 90 degree turn in my car at 50+ MPH with careful use of the emergency brake and fancy footwork on the pedals. Impressive? Sure, leaves about 5,000 miles worth of my tires on the road. Fun? Sure, whipping the car like that is awesome. Do I do it for every turn I encounter? Absolutely not. AJAX is like that. Impressive and fun when it is done right *under the right circumstances* in the right application, and dangerous, scary, and deadly (to a career, at least) under the wrong circumstances.

    J.Ja
    Justin James
    • Spot on

      Hats off J.Ja.

      Like you, I wonder where some people are getting their ideas about AJAX: It is not complex; it is not a new dawn of any sort; it is not efficient.

      Using AJAX is akin to putting on a suit and tie to go swimming - you might look smart at the line up, you might even look alright when you get out the other side (if you do), but in between...
      Fandorin
      • Don't worry...

        AJAX is simply the latest in a never-ending stream of journalistic fads. No journalist worth his salt will want to admit that he hasn't jumped on the latest bandwagon. Remember how not too long ago RSS was the wave of the future? Then it was Web 2.0? Then Web 3.0? Then mash-ups? Ad nauseum...

        I often wonder who is the journalist that starts these fads, and why all other journalists seem obligated to follow. Give it a few weeks or months, and the tech journalists will have moved on to the next fad to catch their fancy.

        Carl Rapson
        rapson
      • Efficient for whom?

        In Ajax's defense, what matters most is the user experience. I can hit the 'check spelling' button on Gmail, or the 'preview' button on BlogSpot and have it work instantly. That's a real productivity boost for the user. Studies have shown that Ajaxified apps can be easier on the server, but they can be harder on it too. It just depends on your design. And, BTW, nobody says you have to use XML as your transport format.
        Ed Burnette
    • Re: Where have you been?

      I was one of the early adopters of OWA (Outlook Web access) and it worked great - on IE. And just FYI, I do have knowledge of web development, protocols, and web servers, having written my own dynamic code generating server (kind of a C alternative to JSP, internal only) and spending many an hour using hardware and software network monitors debugging client/server apps professionally.

      For little touches here and there Ajax (in particular the JavaScript part) is not that bad. But I'm talking about larger applications where browser combinations and maintainability quickly get out of hand. Most heavily JavaScripted and/or Ajaxified apps I've used are crap. But for some reason I continue to be impressed by Google's use of the technology.
      Ed Burnette
  • Are they THAT shortsighted?

    As I read posts from jmjames, pedroc and rapson, I wonder... are they that shortsighted?

    Let's review. jmjames goes into an exhausting monologue about the inefficiencies of AJAX, and the amount of overhead it produces. (And JM, if you're reading this, try posting less rhetoric and opinion and more fact. Most of your last post sounded more like some of ZD's more notorious trolls as opposed to being informative! I'll reply to it shortly so you can see it for yourself.)

    As for JM's points, I agree, to a degree. What I am very disappointed by, is the fact that he, and the others, fail to bring up AJAX's virtues. He starts off with MS fluffing, then goes down a road of complaint. He never discusses the less-than-obvious. So I'll do what he didn't.

    He complains that AJAX adds the same overhead as a post back to the server... well, duh! Take Google's Maps as a case in point. The user drags the map, and the page must update itself. Well, either the page can postback entirely and refresh, or it can use AJAX. In both scenarios, the client will have to parse and render some form of markup... regardless. In both scenarios, the HTTP protocol will have to be invoked and used. In both scenarios, the web server will have to do work.

    In one scenario, the user will have a richer experience.

    Get it? Either way you cut it, both client and server have to do [roughly] the same amount of work. AJAX is more thick-client-like for the user.

    Another thing. His whole post speaks of inefficiencies, and even makes the mistake of citing ASP.NET. I can't help but criticize his mistake.

    In one scenario, your posting back an entire range of parameters that will never be used, this amounts to added overhead to the HTTP protocol. In that same scenario, the web server is processing and spitting out THE SAME HTML that it already did on the first request. Now take the AJAX scenario. The only thing that gets posted back to the server is the list of parameters needed to satisfy the single action. The data sent back is what is necessary to perform the action, as opposed to all the HTML that got rendered the first time. On request, and reponse, the amount of data IS MUCH LESS with AJAX. Mind you, AJAX does it more often, but takes sips of data, and not whole gulps. Mind you, we're not even considering peripheral requests to the web server for images, style sheets and javascript files.

    So really, when it comes down to it, AJAX is limited to the protocols it relies on. Yes, it may produce more traffic than is really necessary. But is it as grossly inefficient as JM makes it sound? No way.

    There are two types of techs on this planet. Those that feel the technology should be built with what is at hand, thereby limiting the user experience. Or those that believe that the technology should be built to push the limits of what is available today, to keep innovation pushing through tomorrow. JM's comments align him with the former. I, like most of those rushing to use AJAX am the latter. Push the data through, so that those with the pipes can improve them.

    Bottom line, there are too many reasons to use AJAX, and not enough people actually using it. And yes, it seems like everyone is jumping on the bandwagon as JM states, but this article is definitely true... there are not enough implementations for a really slick technology, and way too many books and articles about it.

    ------------------------------------------
    <font color="#FF0000">Does ZDN allow HTML?</font>
    kckn4fun
    • PS: I believe in a different web 2.0

      One thing I forgot to mention is that with all the hype behind web x.0, I think that there is something that has been missed. I've got a little hobby I'd like to share with you all. I'm trying to finish the site as of right now (Weds, 9:15a), so it should be up sometime within the next 2-3 days.

      If you're interested, keep tabs at:
      http://www.evoisys.com/projects/peerpax

      -RS
      kckn4fun
    • Rushing in

      Does this mean that you have not yet used it?

      If that is the case, stop and take the time to draw up a business case. Don't get all excited about improved user functionality without _really_ considering whether it is necessary. Don't get stuck thinking about the telco./server stuff, because unless you are talking about major stuff the cost/benefit is negligible (*1). Do think about how easy the development and testing cycle will be, and whether the result will be reliable and cost effective to maintain.

      Once you have been through all that you might think again. Then again, you might not: AJAX has its uses ? the point is that they are _not_ universal - as some people have tried to make out.

      And here's the rub: If people just promoted AJAX for what it is (which is simple to understand, not least because its been around in its constituent parts for ages) and gave some simple examples of what it can do (and Google maps is a really poor example), there would be no problem with takeup.

      (*1) IMHO, the ASP.NET point in JMs post validly points out that things have not moved on that much - but then I read it knowing what you went on to write.
      Fandorin
    • Nothing *but* factual information in my post

      "As I read posts from jmjames, pedroc and rapson, I wonder... are they that shortsighted?"

      No, we are not being shortsighted. We are recognizing the difficulties and limitations with this particular use of technologies. AJAX, as I said many times in a post which you misread for one reason or another, is not inherently bad. But to try slapping in on everything is a major mistake, and to hail it as equal to the invention of sliced bread is foolish at best.

      "He starts off with MS fluffing..."

      No, I simply chose to point out a *fact* which is that AJAX has been around much longer than the much-vaunted Google Maps, and that Google is not the only company that "gets is". Indeed, if you look at many Microsoft products and websites, they have a lot of Google, and some excellent uses of it. The fact that they (and Google, for that matter) do not use it everywhere is proof of my point, that it should only be used in certain circumstances.

      "In both scenarios, the HTTP protocol will have to be invoked and used. In both scenarios, the web server will have to do work."

      There are significant differences, as well as similarities. If you understand the HTTP protocol, and how servers handle it, producing 40k worth of XML dynamically involved just as much, or insignificantly less resources than generating the same content with an extra 5l worth of HTML. On the client side, the browser is an application specialized and optimized to process and display HTML content. The JavaScript interpreters they use, on the other hand, are not just slow, inefficient, and miserable in general, but are certainly not optimized to process XML well. But let's pretend, for the sake of argument, that JavaScript interpeters were as fast as, say, the Perl interpreter. Even then, it would still be more efficient to process a comma-delinated file or fixed-record length file than an XML file, even if that same data was tranferred via HTTP. In other words, using XML is for lazy programmers, not smart ones.

      "In one scenario, the user will have a richer experience."

      Yes, and Google Maps is a good example of where AJAX actually makes sense. As I said in my previous post, write a simple piece of JavaScript that iterates through an HTML form an updates the value in each field (say, increment by one). With a few fields, it works great. Now try it with a few thousand fields. It falls apart. It is faster to put a postback to the server and have the server sort a dataset and return it as a new HTML page than it would be to write JavaScript that holds the data, does the sort itself, and then updates the HTML display. Much, much, MUCH faster. Try it if you don't beleive me.

      "In one scenario, your posting back an entire range of parameters that will never be used"

      And in that scenario, you have a lazy programmer, once again. If you can write AJAX that uses only the needed parameter for the update, you can write the same code to only post to the server the needed variables for a standard request.

      "Mind you, AJAX does it more often, but takes sips of data, and not whole gulps."

      Sure, it looks that way *to your system*. It does not look that way to the network, the HTTP protocol, the TCP/IP packets, etc. Learn about networking. Read the HTTP RFC. Learn about the operation of a web server. Learn what it needs to actually do on each request. Once you understand all of this, you will recognize that for the majority of requests (the ones that I don't consider "bone crushing", at least), the overhead from processing a "sip" is nearly identical to processing a "gulp". On your "sips", the HTTP headers alone are probably as big, if not bigger than the request/response. And the methods that data gets framed in TCP/IP when it hits the network makes it pretty irrelevant if you are doing "sips" or "gulp". A "sip" simply sends a mostly empty frame over a T1, whereas a "gulp" uses that frame to maximum advantage. Learn your deep protocols and technologies, don't be lazy.

      "Those that feel the technology should be built with what is at hand, thereby limiting the user experience. Or those that believe that the technology should be built to push the limits of what is available today, to keep innovation pushing through tomorrow. JM's comments align him with the former. I, like most of those rushing to use AJAX am the latter. Push the data through, so that those with the pipes can improve them."

      Sorry, but when my customer has a lousy experience because something is slow, I get called onto the carpet for it. Providing a user with a buggy, difficult to maintain system that is slow costs my company business. My customers are extremely pleased with the work I produce and frequently comment at how smooth everything runs, even on dialup VPN connections (traveling sales force is the end users). Customers could not care less about drag/drop, expanding trees, right-clicking (drag/drop is still rarely used when an alternative exists by most users, tree structure is difficult for users to understand, and most suers *still* do not right click unless they have been told to). AJAX gives great user experience, when done right in the right application, but only to those with advanced understanding of how to manipulate a computer interface (I suggest you read Jakob Neilsen's excellent website about usablitlity, www.alertbox.com).

      And since I'm a nice guy, I'm not even going to make a quip about the dead link (404 error) you posted.

      J.Ja
      Justin James
      • Maps

        I think that Google Maps is a great way to demonstrate potential. In my experience, it is a really poor way to try and demonstrate how else it can be used.
        Fandorin
        • Thanks!

          Thanks for stating in an elegant, precise way exactly the point I've been attemtping to convey in many, many paragraphs. Maps is a cool tool, with a clever (at best) use of technology, and people are extending the idea to all sorts of stuff that it should be extended to.

          J.Ja
          Justin James
        • Maps API

          Check out their Maps API though. Very progressive. APIs from vendors like Google, Amazon, and eBay are sparking a whole new type of application, the mash-up.
          Ed Burnette
      • More rhetoric?

        Let's see...

        "And since I'm a nice guy, I'm not even going to make a quip about the dead link (404 error) you posted."

        I'm not nice, at all, what I am, is knowledgeable. If you read the rest of my post with that link, you'd read that the *site* is still being built... so for a guy referencing RFCs you'd think you could understand that links *within* sites wouldn't work, if it was still being built.

        In all that jabber, when it comes down to it, its a matter of where you wish to place your processing power, client or server... a matter of whether the technology fits your application's overall architectural objectives.

        Also, you question the knowledge of someone you have no idea about, and most eagerly I might add. I've seen that behavior before... in my junior programmers ... in admins fresh out of college thinking they know how to fix the world based on idealogy ... in seasoned professionals that never bothered to learn the delicate balance of tech vs. business, nor rhetoric vs. fact.

        In your case, anyone that reads that post and *does* have the knowledge to see the errors in it will know as I do, that you're not smart enough to know that writing long enough to criticize others leaves your writing *just* long enough for you to make a mistake... or in your case: several.

        Cheers.
        kckn4fun
        • Yes more...

          From you.

          You are delivering a seemingly inconsistent message.

          In your first post you talked about two types of techs [i.e. technical people]. You placed yourself under the type that like to push the limits. Now you state in your above post that ideological people are not so good after all. This would seem inconsistent unless you had seen this type of stance before: In people who are completely dogmatic - my way or highway.

          The other inconsistency is where you mention more experienced people who have not bothered to learn the delicate balance of tech vs. business. Firstly, there is no balance - in the corporate environment technical developments _have_ to be aligned with business requirement. Secondly, you have not provided any reason why AJAX is more compelling to developers than other solutions.

          The *jabber* you mention in your fourth para. You are arguing with yourself.
          Fandorin
        • Attack the message, not the messenger

          "I'm not nice, at all, what I am, is knowledgeable. If you read the rest of my post with that link, you'd read that the *site* is still being built... so for a guy referencing RFCs you'd think you could understand that links *within* sites wouldn't work, if it was still being built."

          This is my exact problem with AJAX, is the people who develop code for it. Your attitude is, "I posted a link, invited you to follow it, but the link was bad and it was up to you to figure it out." I followed that link because I was curious to see what you were talking about, especially since you said you did AJAX development and were working on something using it. If I posted a link in public like that, the link would work and would have been tested. <sigh> I guess I should put my money where my mouth is, and at least get a "Site down for the time being" page on my personal website, since there are a lot of links out there pointing to it.

          "In all that jabber, when it comes down to it, its a matter of where you wish to place your processing power, client or server... a matter of whether the technology fits your application's overall architectural objectives."

          Then you are not reading my posts correctly. Maybe I'm not being clear, maybe you are not able to understand, I don't know which it is. What I said (I'll try to be clear) is that a good portion of the problem is that AJAX relies upon JavaScript, and the JavaScript interpreters in browsers are inefficient and slow, leading to a poor user experience. A CPU on a server running Perl, Java, Python, C++, even ASP.Net is more effificient than a CPU on the client running JavaScript. If AJAX used something other than JavaScript and the tools to run it were swift, or if existing JavaScript interpreters were better, then I would be significantly more accepting of AJAX. But at the current state of JS interpreters, AJAX is unworkable for large items. In addition, the bundling of all of that code within the HTML document is messy at best, once the application becomes large. Testing of JS is an absolute nightmare and the tools to work with it are wretched.

          "Also, you question the knowledge of someone you have no idea about, and most eagerly I might add."

          You are 100% correct. I do question someone's knowledge. Read around the TalkBacks a bit more, you will see that I question everyone's knowledge, particularly those that I beleive should know better, such as Mr. Berlind (I get on his case a lot). Feel free to question mine. Put me to the test. I make a point of not talking shop when I haven't turned the wrench. It is always better to question and learn, than to sit back and assume (especially in a blog forum) that the other person has a clue. If you don't like being questioned, all I can say is that I have met a lot of people like that as well... pointy-haired bosses and know-it all college grads come to mind. Most of the truly senior technical poeple I have encountered love to be questioned, because it gives them a chance to teach, as well as to show off a little bit in a healthy way.

          "rhetoric vs. fact"

          You keep claiming that I am spouting "rhetoric". Where is my "rhetoric"? Am I quoting some vendor's lines? Am I citing some half-baked study? No, not at all. I am using technical facts to make a case. Facts that came from sources like network protocol standards and such. I wonder if "rhetoric" means "what I do not agree with".

          "In your case, anyone that reads that post and *does* have the knowledge to see the errors in it will know as I do, that you're not smart enough to know that writing long enough to criticize others leaves your writing *just* long enough for you to make a mistake... or in your case: several."

          You have not once shown where I am incorrect. You have not once put forth a technical statement, outside of the "sips and gulps" piece. Even that, I said is accurate at the code level and often inaccurate at the network level. So far, you have not said anything except that I am "shortsighted", full of "rhetoric", that I produce "jabber", that I do not know the "delicate balance of tech vs. business" (I am a seasoned professional, so that's the insult I beleive you meant to apply to me), and that I'm "not smart enough to know that writing..." Odd. In this entire "rebuttal", you have not once said anything about interpreters, XML, servers, networks, etc. etc. etc.

          In the period of time that I have been posting comments in these forums, I have had many debates, back and forths, etc. There have been times where I said, "you are right, I did not see that aspect of things" or something along those lines. I have no problem admitting that I'm wrong, when someone brings new information to the table, or better illuminates existing information. You have tried none of these. Instead, you have launched an assault upon me, as well as some of the other posters here. I know from past experience that Rapson, for one, is extremely knowledgeable as well. He and I do not always see eye-to-eye, but there is a respect and a learning that occurs. Indeed, for all of the times that someone has had a thinly veiled "you're an idiot!" aimed at me, they always *always* had a good reason for it, and posted that and backed it up. Good on them! But you haven't done any of that.

          When you attack the messenger and not the message, you are trying to fight a different war because you already lost the real one. If you want to reply to this, great. If you want to make a reply based upon actual technical information, I'll be happy to read it and objectively consider it. If you're just going to continue with insults, I'll politely ignore it.

          J.Ja
          Justin James
          • Initiation

            My first day on ZDNet and I already have a little flame war going on. Is this part of the initiation rites? :)
            Ed Burnette
          • Fairly rare, actually...

            In my many months of extremely frequent posts to ZDNet TalkBacks (I'm a master of the 2,000 word essay, do a search for "jmjames ZDNet TalkBack" for my greatest hits collection), this is actually the closest I came to a flame war. Indeed, a few weeks ago, I think I may have been the only poster to escape one regarding politics, if you can beleive that (http://www.zdnet.com/5208-10533-0.html?forumID=1&threadID=17187&messageID=339730&start=-5). Some of the writers often draw frequent put-downs, though. George Ou gets called a "shill for Microsoft" and "troll" a lot. Paul Murphy gets "shill for Sun" on a regular basis. John Carroll has it the worst because he's actually a Microsoft employee. I jump on David Berlind on very frequent basis but try to be civil about it. Mitch Ratcliffe and myself also get into it and end up quoting a lot of dead people. :) My intial dig on you ("It seems clear to me that Mr. Burnette does not understand AJAX.") was supposed to be a spoof of the title, but sans verbal cues, could have been taken as an insult (apologies if it was!). I just get really peeved when people accept prima facie the superiority of something new and shiny without asking the critical questions first, like "does this actually solve a problem?" and "how will this hold up in the long run?" I've cleaned up too many messes by people who charged ahead with some bold initiative without thinking, and I feel that the IT industry is 80% hype, 19% dismal failures, and 1% successes. It's not that I'm against change; I started web dev in '97 or so, learned Java before it was cool, ran a computer with Windows 95 Beta 1 (when "beta" truly meant "beta", not "free peek at something that is almost production quality") for months before giving up, etc. But change for the sake of change is always a bad idea, from my experience.

            J.Ja
            Justin James
          • No problem

            I know what you mean. I started with the web back in '93 when Mosaic first came out and I've seen a lot of hype come and go. Remember when "push" was going to take over the world? At least "Ajax" is a much cooler name than "push". :)

            --Ed
            Ed Burnette