Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

The Current State of Ajax 347

Posted by samzenpus from the overview dept.
Dion Hinchcliffe writes "Ajax hasn't even been big a year yet and already open source development tools by the dozen are pouring out. Not to mention big names like TIBCO and Microsoft already have previews on the way of full-fledged IDEs for developing Ajax applications. Ajax may be the biggest software development story of 2005. Dion Hinchcliffe has a detailed article about how Ajax has evolved over the last six months and assesses the current state of tools, libraries, and mindshare. He also points out that Ajax will inadvertently end up being a driving force for Service-Oriented Architecture (SOA) for many organizations since it requires high performance back-end XML services."
This discussion has been archived. No new comments can be posted.

The Current State of Ajax More

The Current State of Ajax

Comments Filter:

  • Thin Clients, Fat Pockets (Score:5, Interesting)

    by mfh ( 56 ) on Friday August 19, 2005 @04:43PM (#13358051) Homepage Journal
    Ajax will inadvertently end up being a driving force for Service-Oriented Architecture (SOA) for many organizations since it requires high performance back-end XML services.

    I think we've been seeing this shift for a while now, since people went from fat client software towards more streamlined C/S replacements, due mostly to convenience and easier features, server updates etc. Plus you can't argue with the repeat revenue stream generated by services that you can offer your customer, as opposed to a single sale.

    When did you move your email handling from a fat client to webmail? My first move was from Eudora to Outlook, then Outlook (yuk) to Pegasus (don't ask) and then to Hotmail and now Gmail. I don't think I'll move away from Gmail, but you never know.

    Ajax unplugs you because you get the immediate, targeted response from the server that wasn't available before. So refreshing a whole page when I only need to see a small widget change is really what Ajax fixes. I look at Ajax as being only a bugfix to the intarweb and nothing else, really. Seriously, why do I want to refresh a whole template when I want to send only a little widget of text in the middle?

    Frames were not the way to handle this kind of presentation/data separation, mostly because they could be indexed and that would confuse visitors coming to the center frame and not the whole display. Eventually many people just stopped using frames because they are clunky, and have strange display problems on varrious systems. Ajax remedies this problem, really. Hypothetically you could set up a site that had a bunch of frames that interacted independantly and achieve a similar result to Ajax, but who would want to have to handle the cross platform and cross browser problems that arrive when you rely on frames?

    Ajax is definately going to push for more service oriented contracts and eventually I can see products dwindling or becoming wrapped into services and monthly subscriptions instead of out of the box solutions that are popular today.

    I will bet that eventually we'll see some very thin looking clients in the near future, thanks to Ajax.
    • Frames also didn't solve all the problems. IFrames came much closer, but still no cigar. One of the problems is that sometimes you just need a round trip to the server to tell script to do something to the page, you can accomplish that with a hidden IFrame or Frame, but that's not really what they were designed for and it requires the browser to interpret the result and attempt to render a page. That slows everything down just enough to be noticable.

      p.s. I used Pegasus as my primary mail client some 8-10

      • One of the problems is that sometimes you just need a round trip to the server to tell script to do something to the page, you can accomplish that with a hidden IFrame or Frame, but that's not really what they were designed for and it requires the browser to interpret the result and attempt to render a page.

        If you get an XML response in a hidden IFrame, it's just as good as the XMLHttpRequest. You can assign a listener to the IFrame so that you know when it's done loading. The listener can then walk the XML
        • And doing it in an IFrame can get around one of the biggest disadvantages of XMLHTTPRequest, the broken browser back button. This is the method that Google Maps uses to be able to page back through search results. The Ajax Wikipidia article [wikipedia.org] mentions this and other workarounds.
      • I use Pegasus on my Windows system, and a mix of KMail and mutt on my Linux system. Pegasus is by far the best mailer for me, as I get a lot of junk that needs sifting through quickly (AFTER junk filtration) and in fact I prefer it to any other PIM - the telephone message function is quite handy too.

        The only disbenefit is the IMAP functionality - whilst it is getting the IMAP login/folders etc, the systen freezes, annoying when you have 40 folders and it takes ~5 seconds.

    • Re:Thin Clients, Fat Pockets (Score:4, Insightful)

      by C.Batt ( 715986 ) on Friday August 19, 2005 @05:29PM (#13358366) Homepage Journal
      Hypothetically you could set up a site that had a bunch of frames that interacted independantly and achieve a similar result to Ajax, but who would want to have to handle the cross platform and cross browser problems that arrive when you rely on frames?
      I can speak as someone who has in fact done just that and would have killed for an XMLHttpRequest object back in 2001.

      Today I'm architecting a significant new web project and my first order of business on the UI side was to specify XMLHttpRequest (buzzword catchphrase, yuck.) as the core around which the client would be developed. It's working fantastically. It simplifies just about everything, imho, once the basics are in place.

      It is now possible to do highly-reactive monitoring applications in a browser without applets, plug-ins, or frames+script chicanery. Download the core app, then stream in the rest of the bits behind the scenes. Sweet!

      The clients love it, we love to develop using it. Win, win situation - a strange place to be on an IT project.
    • thinner clients?...

      I use mutt, irssi, slrn and ELinks. I don't think I want thinner than that.
    • Great, now all we need to do is fix the pitiful state of HTML "widgets" and we will be all set! Seriously, HTML has to be the single worst way to make a "rich" web application. You get like 3 or 4 basic widgets with very little flexibility to make a GUI with, and that is about it. The rest is rather complex CSS. Now, XUL, that is a slick way to make a nice web app. And you can use the very same Ajax technology with it. Too bad it is Mozilla only.

      -matthew

    • When did you move your email handling from a fat client to webmail? My first move was from Eudora to Outlook, then Outlook (yuk) to Pegasus (don't ask) and then to Hotmail and now Gmail. I don't think I'll move away from Gmail, but you never know.

      Ajax unplugs you because you get the immediate, targeted response from the server that wasn't available before. So refreshing a whole page when I only need to see a small widget change is really what Ajax fixes.

      Oh, you mean the kind of responsiveness and bandwidth

  • SERVICE UNAVAILABLE
    • Yeah I love that, that was a good laugh. I can see someone saying, "Hey boss, check out this article about Ajax, we gotta get ourselves some of dat Ajax stuff, its way awesome! Let's click on the link to read more about it - SERVICE UNAVAILABLE - doh!"
    • The guy who submitted it, is the same guy who wrote the article and has the downed server. shesshhhh

    • Re:High Performance Back-end Services (Score:3, Informative)

      by Anonymous Coward

      Dion Hinchcliffe's Blog - Musings and Ruminations on Building Great Systems

      Agility, Service-Orientation, Enterprise Architecture, and Software Development
      State of Ajax: Progress, Challenges, and Implications for SOAs
      A lot of bits have been pushed around the blogosphere on the topic of Ajax over the last few months. This includes my own post back in March, which gave a general overview of what Ajax was and what it does. A lot of exciting stuff has happened since then, and Ajax has rapidy matured into a devel

  • If Slashdot supported AJAX (Score:5, Funny)

    by Anonymous Coward on Friday August 19, 2005 @04:45PM (#13358074)
    You could see the dupes as the editors approved them.

  • More than a year thanks (Score:5, Informative)

    by buro9 ( 633210 ) <david&buro9,com> on Friday August 19, 2005 @04:47PM (#13358083) Homepage
    "Ajax hasn't even been around a year yet"

    Which is strange, because in 1999 I was making web applications that utilised hidden frames to post information to the server and return JavaScript arrays which I would then use to modify the limited parts of the DOM I had access to at that time. It worked in Netscape 3, Netscape 4, and IE 3 and IE 4.

    So the techniques in question have been around for ages, and the use of Xml and the XmlHttp objects appeared several years ago with Outlook Web Access.

    The ONLY thing that has been around for approx' a year is the utterly stupid name for it, "AJAX".

    I'm glad other people are picking up on it and using it, it's very powerful, but let's not credit Adaptive Path with creating a technology or method that many people have been using for a long time.

    If you have to use a name, then RIA (Rich Interactive Applications) is far more suitable and doesn't restrict the developer to asynchronous work only for it to be included in that.
    • Yep. Very true.

      We were having performance issues with our Intranet home page. The page was data-driven and requests took too long to execute. People would get impatient, hit refresh, add more items to the queue, and eventually things would melt into a puddle.

      I rewrote as much as possible using static javascript includes and cookies, greatly improving performance. There were still a couple things personalized to the individual. Those I threw into a hidden frame which filled in a couple drop-down b

    • No Kidding (Score:3, Interesting)

      by Tony ( 765 )
      I started in about 2000 with hidden frames, Javascript, and DOM. I got the idea from someone else on the web; I thought it was brilliant at the time. I was able to auto-update forms without clearing the form, etc. All the stuff that AJAX is doing now.

      It's nothing new. Other folks just think it is.

      • Re:No Kidding (Score:3, Interesting)

        by temojen ( 678985 )
        I did it in 1998 in NN & IE. Just make a frame that loads dynamic web pages that contain javascript to make the changes to the main document, with no borgers & the same background colour as the main frame. Worked like a charm.

    • If you have to use a name, then RIA (Rich Interactive Applications) is far more suitable and doesn't restrict the developer to asynchronous work only for it to be included in that.

      Thank you for the explanation. I've been wondering what in the world AJAX is, and why I should care. I don't know what AJAX is. But I can tell what a Rich Interactive Application is. Isn't it nice how language can be used as a communication tool rather than a way to hide your meaning so you can feel elitist compared to tho

      • Re:More than a year thanks (Score:5, Insightful)

        by buro9 ( 633210 ) <david&buro9,com> on Friday August 19, 2005 @05:05PM (#13358217) Homepage
        AJAX = Asynchronous Javascript And Xml

        It's a terrible name because it says nothing about what it is, only what it is made of. Even then it poorly describes what it is made of, as it can be made of other things too.

        So from this CBL (Carbon Based Lifeform) to another, I say, "Goodnight".
        • "It's a terrible name because it says nothing about what it is, only what it is made of."

          XML = Extensible Markup Language. Not exactly an extremely informative name there, but certainly acceptable. I rather it be AJAX instead of:

          UJATDUIXFTDUPWRTWPOLANWP = Using Javascript And Templated Documents Usually In XML Format To Dynamically Update Pages Without Refreshing The Web Page Or Loading A New Web Page.
    • A startup I worked for, State Software [prnewswire.com] had a full out API developed that did the exact same thing back in 2001 -- used a hidden IFRAME to pass javascript objects to and from a server. It was enterprise ready... But it was proprietary, and while they recieved quite a bit of attention from the biggest names in ECommerce apps, they never did get any real sales/installations.

    • Popularization is an important job ... (Score:5, Insightful)

      by __aadkms7016 ( 29860 ) on Friday August 19, 2005 @05:10PM (#13358246)
      The person who makes a technology popular receives technical fame for a good reason -- by making more of the world aware of a good technology, in a way that leads to deployment, the world becomes a better place. Sometimes, popularization adds more value than invention to an idea.

  • The Current state of ajax? (Score:3, Funny)

    by Anonymous Coward on Friday August 19, 2005 @04:49PM (#13358103)
    I think you can still find the cleanser at any Wal-Mart, Meijer or Kroger. ;)

  • Since it's Slashdotted... (Score:5, Informative)

    by tcopeland ( 32225 ) * <tom AT thomasleecopeland DOT com> on Friday August 19, 2005 @04:50PM (#13358104) Homepage
    ...here's an article [onlamp.com] by Curt Hibbs on Ajax with Rails. He's got an "Ajax in 60 seconds" history lesson at the top of the article...

  • AJAX and Centrino (Score:3, Insightful)

    by cerelib ( 903469 ) on Friday August 19, 2005 @04:50PM (#13358112)
    Does anybody think of Intel Centrino when they hear AJAX? They are quite similar in the fact that it is just giving a name to using a combination of technologies. Also, has anybody ever heard a Best Buy computer salesman say "This one has a Centrino processor."?

  • Ruby on Rails settles everything (Score:5, Funny)

    by duffbeer703 ( 177751 ) on Friday August 19, 2005 @04:51PM (#13358115)
    Ruby on Rails and AJAX makes everything else obsolete. A coworker and I just implemented the J2EE spec in 25 minutes. We're working on the win32 api on monday!

  • You know.. (Score:2, Insightful)

    by Anonymous Coward
    He also points out that Ajax will inadvertently end up being a driving force for Service-Oriented Architecture (SOA) for many organizations since it requires high performance back-end XML services.

    Advertising programming languages with a pre-com-bust-style-buzzword-overload isn't very useful for gaining the attention of developers.

  • What is it? Its this (Score:4, Informative)

    by razmaspaz ( 568034 ) on Friday August 19, 2005 @04:53PM (#13358133)
    http://en.wikipedia.org/wiki/AJAX [wikipedia.org]

    Ajax is using Javascript to fetch only part of a web page and then updating the page with DHTML and JavaScript, reducing round trip time and server load and making the application "feel " more native.

  • accessability guidelines (Score:5, Insightful)

    by sammy baby ( 14909 ) on Friday August 19, 2005 @04:54PM (#13358137) Journal
    Does anyone here know of a good reference for balancing the "gee-whiz, nifty" aspects of ajax techniques with designing towards accessibility? I like the thought of, say, livesearch, but dislike the idea of breaking support for text-to-speech readers, assistive devices, et cetera.

    In fact, the article in the story might have a terrific section about just this issue. But I wouldn't know, because the server fell over worse than I do after a gin-and-tonic bender.
    • Accessibility takes a back seat to flashiness so far. A lot of "gee-whiz" ajax applications are great eye candy and the surprising responsiveness can make you wonder if it's just a web page or something more. I think that most of what we're seeing now doesn't get past that stage.

      I follow Ajaxian [ajaxian.com], and even though it doesn't cover accessibility directly, I find that the developers they link to do get in to these issues sometimes. It's a new field, so you have to dig deeper to find people doing apps that are
    • There was an article on slashdot a couple days ago about ibm donating a large section of code to firefox to enhance accessibility in ajax apps.

  • qooxdoo (Score:3, Informative)

    by The Bungi ( 221687 ) <thebungi@gmail.com> on Friday August 19, 2005 @04:54PM (#13358140) Homepage
    http://qooxdoo.sourceforge.net/ [sourceforge.net]

    Weird name, but very impressive. Though not an "AJAX" framework, with some effort it can be "bound" to an OOB request factory or something similar to have your cake and eat it (rich client-side stuff + backend server). Very cool. And it works with IE and FF, but obviously better with Firefox.

    BTW, I love how this "AJAX" thing is just a cute name for a Microsoft technology that was first introduced with IE4. The first "AJAX" app was the Exchange OWA client.

    • True, but the XML part of this framework isn't really necessary. Why send a lot of xml text back to the browser and then make it load it into memory and walk through it? It's often better to send back a Javascript array - no real overhead for the browser or the internet connection.

      BTW, OWA is so much more pleasant to use in Firefox (without all the dynamic crap) than it is in IE. It's sooooo slow in IE when all I want is webmail.

  • Got in before it went down (Score:5, Interesting)

    by NoTheory ( 580275 ) on Friday August 19, 2005 @04:55PM (#13358153)
    Dion Hinchcliffe's Blog - Musings and Ruminations on Building Great Systems [hinchcliffe.org]

    Agility, Service-Orientation, Enterprise Architecture, and Software Development

    A lot of bits have been pushed around the blogosphere on the topic of Ajax [wikipedia.org] over the last few months. This includes my own post [hinchcliffe.org] back in March, which gave a general overview of what Ajax was and what it does. A lot of exciting stuff has happened since then, and Ajax has rapidy matured into a development of major significance. Coverage has been all over the map and runs the gamut from Rasmus' been-there-done-that 30 second Ajax tutorial [rajshekhar.net] to Alex Bosworth's list of Ajax Mistakes [sourcelabs.com] to the uber-repository of Ajax knowedge, Ajax Matters. [ajaxmatters.com]

    Many of you already know that Ajax is a web client programming style which eschews traditional HTML web pages, which are only sprinkled lightly with JavaScript and reload pretty much every time they are updated or clicked on. Instead, an Ajax web client receives an Ajax JavaScript library into a hidden frame which provides run-time visuals on the main browser window that look and feel very much like a native application. Ajax web clients, once loaded, communicate with XML services on the back end (via a browser's built-in powerful XMLHttpRequest API [wikipedia.org]), and then use JavaScript to manipulate what the users sees programmatically via DHTML.

    All of this allows Ajax to provide a compelling user experience because 1) it doesn't reload the web page, and 2) it runs asynchronously allowing background server-side requests for information to be issued, all while the users clicks, types, and otherwise interacts with the application in the foreground. Google Maps [google.com] is the pre-eminent example of a modern Ajax application: rich, interactive, easy-to-use, and predictive in that it loads the map tiles that are just offscreen in case you need them. This is all very good for web client client development, but why all the attention across the board?

    Figure 1: Ajax: The first compelling new client application model since the modern web browser

    Because Ajax is a sincerely compelling synthesis of the ubiquitous features found in the most popular Internet browsers is why. Practitioners of Ajax get high-intensity user interaction (end-user productivity), asynchronicity (efficient backround processing), web browser access to web services (web service access, reuse, and interoperability, as well as SOA integration), platform neutrality (browser and operating system agnosticity), and the Ajax feature set can be delivered as a framework you don't have to create yourself (developer productivity).

    Individually, these items are very nice, but taken as a whole, working solution and you have something extremely special. While many folks thought the web browser story had stopped around the year 2000, Ajax takes us to a whole new place. Slashdot recently highlighted a notable new article [wired.com] in Wired that claims that the industry, mostly on the basis of Ajax, "has affirmed the viability of the web as a standalone software development platform."

    This is no small thing, and has the potential to repave the modern application development landscape. Why? Because Ajax creates a rich and fertile new space for developing software solutions that can reach almost anyone, anywhere whatev

  • Ajax hasn't even been around a year yet?! (Score:3, Funny)

    by Flinx_ca ( 809816 ) on Friday August 19, 2005 @04:55PM (#13358155) Homepage
    Ajax [townofajax.com] has been around for 50 years...
  • "Ajax hasn't even been around a year yet"

    excuse me?

    ajax the functionality has been around for 6 years or more

    the buzzword "ajax" and the google maps implementation that skyrocketed the word to buzzword status has only been around for less than a year

    i'm usually not one to champion geek snobbery

    but when geek snobbery is pitted against cattle herds of phbs spouting buzzwords with little understanding of the buzzword itself, geek snobbery is more appealing

  • Mmm, yeah, ok (Score:2, Interesting)

    by Anonymous Coward
    Dion Hinchcliffe writes...

    'Dion Hinchcliffe has a detailed article about how Ajax has evolved'

    It is never a good sign when someone talks about themselves in the 3rd person.

    You gotta love those consultants, always after some free ad space in search of the dollar...

  • Annoyed (Score:3, Informative)

    by defile ( 1059 ) on Friday August 19, 2005 @05:06PM (#13358220) Homepage Journal

    You can't (via "AJAX") query any site but the one that served the script without the browser imposing this scary security warning. We run the sites in question, they just have different domain names.

    Sigh.

    I realize there's worry about cross site scripting attacks, and in the end it's not a big deal, it just means moving the request to a server side proxy. It's just added complexity that wouldn't exist if someone didn't impose something "for our own good".

  • Old AJAX in New Buzzwords (Score:3, Interesting)

    by Doc Ruby ( 173196 ) on Friday August 19, 2005 @05:06PM (#13358222) Homepage Journal
    The "name" AJAX hasn't been around long, but client JavaScript loading XML from servers for dynamic page rendering, inrteractive with client GUI events, has beeen around as long as JavaScript and XML. Before XML, it was data in proprietary or app-specific formats. Along the way it was FRAMES. The technique has always been the wizardry of the most aggressive web developers.

    But now the marketers have a buzzword for it. It's good to have them back. They got so spun out as the Bubble popped that we haven't been able to get them to get anyone to buy stuff for years. Now it's time for them get back to work, marketing the tech that the rest of us have been producing for the past 5 years. It's good to have you back on the team - now show us the money.

  • This is laughable (Score:5, Insightful)

    by ikekrull ( 59661 ) on Friday August 19, 2005 @05:13PM (#13358265) Homepage
    We need to write out business apps in Javascript now because this is the only standard browser vendors can agree on?

    Javascript, it's non-standard browser-specific extension syntax and the restrictive, incomplete and non-standard HTML DOM is an awful environment to write apps in, and it illustrates clearly just how dysfunctional the modern software industry is today.

    AJAX is a shit way to write apps, it's central concept revolves around badly hacking around a problem that shouldn't even exist in a language that was never intended for use in such a way, its like we've got the worst aspects of every major technology available today, grudgingly provided by browser vendors who are want to take their ball and go home since nobody wants to use their proprietary ActiveX or XUL - in an incompatible fashion and we're supposed to see this as a step forward?

    It's stupid, AJAX is stupid, and browser based apps are crap.

    • Re:This is laughable (Score:4, Insightful)

      by Tumbleweed ( 3706 ) * on Friday August 19, 2005 @05:28PM (#13358351)
      It's stupid, AJAX is stupid, and browser based apps are crap.

      Dear Sir or Madam,

      You rock.

      Sincerely,

      Moi
    • Sounds like x86 :)

      Crap, crap, crap, loaded with more crap. But 99% of the world uses it due to market forces.
    • There are instances where an AJAX like web app is the right way to go. A few years back I made one (just using an iframe and text, no XML nonsense) which really couldn't have been done as well any other way, especially since it had to be updated at least once a week.

      Just because something is an over-used, over-hyped fad doesn't mean it has no uses at all.

  • Ajax compared to Flash (Score:5, Interesting)

    by ObligatoryUserName ( 126027 ) on Friday August 19, 2005 @05:15PM (#13358273) Journal
    Now I'm not saying that these are mutually exclusive technologies (Macromedia itself has put out some examples of them working together), but as someone who started out writing a lot of Javascript and moved over to Flash in part to escape browser incompatibilites, what is the technical advantage of Ajax as compared to Flash.

    As far as I can tell, Flash is more accessible (they've built in hooks for this), and Flash uses less bandwidth. (It comiplies to a binary format.) There's an open source compiler (MotionTwin). Flash also seems to provide a better user experience. (Compare Google Earth to Flash Earth [flashearth.com].)

    I know everyone here doesn't like Flash because it's used for advertising, but people here talk a lot about how wrong it is to attack a technology because of how some people choose to use it.

    So, seriously, I've been thinking about looking into Ajax some more, but right now I don't have a good reason to. Convince this Flash programmer that Ajax is a better solution.
    • AJAX doesn't require the user to download a plugin as long as they are using a modern browser. Also, AJAX is not beholden to a single company who doesn't release their player in an open source format. I know I'm the weird exception, but I was running LinuxPPC and no flash client was available to me. If there would have been a full open source client, I could have compiled it myself. Firefox worked fine on that platform and hence, so did AJAX.

      • In Internet Explorer the XMLHttpRequest object comes from an Active X object, which is what Flash is in IE, an Active X object.

        As far as an open source Flash Player the Free Software Foundation is now supporting GPLFlash, an open source Flash Player. ( http://gplflash.sourceforge.net/ [sourceforge.net] ) A version of this project that plays older Flash files has been around since 2000.

    • Re:Ajax compared to Flash (Score:3, Informative)

      by temi ( 899624 )
      Here it is, and while it is the ONLY difference it is a HUGE difference and one that is big enough to make vendors know to switch to AJAX.

      AJAX will work with nearly any major browser off the shelf. poof. No downloading plug-ins once or twice based on how many browsers you are using, no nothing. Just come to the site and begin using the application.

      With FLASH, you must download a plug-in. That may not sound like a lot but it is huge. It is at least one barrier for customers (who are by and large tech-retarde

      • Flash comes with most browsers [not with Firefox, though I don't know why it always came with Netscape and I think it came with Mozilla before Firefox --- you might disagree, but I'm going to assume that if you're savy enough to install a new browser you can also install Flash].

        Also, with Flash 8 (ok, new technology granted) there is a method to update the player without having to go to another website.

  • Site already slow (Score:3, Funny)

    by Saiyine ( 689367 ) on Friday August 19, 2005 @05:17PM (#13358281) Homepage

    Here's a mirror:

    Service Unavailable

    --
    Dreamhost [dreamhost.com] superb hosting.
    Kunowalls!!! [kunowalls.host.sk] Random sexy wallpapers.

  • Still pissed, I think. (Score:3, Funny)

    by Leontes ( 653331 ) on Friday August 19, 2005 @05:18PM (#13358287)
    I tried to get him to talk to me [wikipedia.org], but he was still muttering some shit about armor and went back into Erebus. So his current state: dead and bothered.

  • Thin Client, My Ass! (Score:2, Informative)

    by _bug_ ( 112702 )
    This is nothing more than a repeat of what we saw when Flash started to get popular.

    AJAX requires a client that supports javascript in the first place, along with XML and whatever other bits of things (hidden frames.. god knows what else) to get and manipulate all this data.

    So truly thin-clients (think Lynx circa 1996, guys) are SOL. Now it's AJAX or bust.

    And you're probably thinking "well who the hell uses Lynx or some other, archaic, web browser?"

    Well there are those people out there, but that's not all.

    • Re:Thin Client, My Ass! (Score:4, Insightful)

      by Bogtha ( 906264 ) on Friday August 19, 2005 @08:15PM (#13359293)

      AJAX requires a client that supports javascript in the first place, along with XML and whatever other bits of things (hidden frames.. god knows what else) to get and manipulate all this data.

      No. "AJAX" uses the XMLHttpRequest object to dynamically load things from the server. You have been able to do such things in the past with hidden frame hacks, but AJAX doesn't require hidden frames. Anybody who has actually used XMLHttpRequest knows this.

      So truly thin-clients (think Lynx circa 1996, guys) are SOL. Now it's AJAX or bust.

      No, it's perfectly possible to develop a website that uses AJAX and is compatible with Lynx. It's no different to any other use of Javascript.

      I'm thinking about the non-human factor, computer applications that come in whatever form to consume the information available on the web. Many (though not all) don't have a javascript engine to execute the various instructions needed to get at the data.

      Except a Javascript engine is not required to get at the data unless you've constructed your website incorrectly. Furthermore, AJAX typically exposes data in an XML format as well, making it more useful to applications consuming data.

      So once AJAX becomes ubiquitous (enough), search engines will either need to start using smart crawlers that can execute javascript, or their indexes will start to really be meaningless.

      The only thing I can derive from this statement is that you haven't got the first clue about AJAX or Javascript in general. There is nothing about either that locks out search engines. It is only clueless developers that locks out search engines. Unfortunately, many developers listening to your rhetoric about "AJAX or search engines" are going to choose AJAX, not realising that they don't need to choose.

      You still can't (really) bookmark a single page inside a Flash movie... so if there's vital data you need, you have to watch/move through the movie to get to the key page you're after. AJAX will prove to be no different.

      You seem to have the misconception that bookmarks are incompatible with AJAX. This is not the case.

      But RSS,SOAP,etc. is simply re-inventing the HTML wheel. They exist simply because HTML isn't being used the way it was always intended to be.

      Again, you are giving the impression that you don't have experience with RSS or SOAP.

      RSS is a format for providing a list of items that is intended to be updated on a regular basis. While you could use a subset of HTML for the list, HTML doesn't provide the semantics for the "updated on a regular basis" bit. For example, there's no equivalent to the <ttl> element type.

      SOAP is a protocol for exposing objects, their properties and their methods to remote systems. HTML doesn't do this. HTTP comes close, but the only way to get browsers to be flexible enough to use HTTP's verbs and resources as substitutes for SOAP's methods and objects is to use AJAX.

      I'm sorry, but your whole rant comes over as being rather uninformed. Sure, AJAX is no panacea, but your criticisms don't make sense.

  • DOM 3 (Score:2, Interesting)

    by mov_eax_eax ( 906912 )
    What i learned with the painful development with javascript, is that standards are good, using the DOM model instead browser specific extensions is a good thing, better compatibility, the API is more stable, for this reason i think that the right thing to do is embrace the Document Object Model (DOM) Level 3 Load and Save Specification standard [w3.org] for asynchronous communication instead XMLHttpRequest.

  • Changing my tune (Score:3, Interesting)

    by cbare ( 313467 ) on Friday August 19, 2005 @05:29PM (#13358365) Homepage Journal
    Rich web applications... what a great idea.

    I've been telling clients for years (since about 2000) to give up on any grandiose ideas of a highly interactive web site. Javascript and DHTML were just hype and didn't work worth a shit in the real world.

    Ironicly, my main example was Google... a dead simple interface that lived within the limited means of HTML and was still extremely usefull. Nowadays, Google is leading the way into more interactive web applications. So, I guess it's time to change my advice.

    Still, AJAX is basically a dirty javascript hack to achieve rich interactivity in today's browsers.

    I hope the evolution of interactivity in the browser doesn't stop here. It seems like there's got to be a less hacky way. One good thing is that the use of XML should allow client side technologies to evolve independently without having to rewrite server-side code.

    Anyway, it's about time!

  • Just developed 2 large AJAX-enabled apps (Score:5, Informative)

    by mflorell ( 546944 ) on Friday August 19, 2005 @05:31PM (#13358384)
    I just finished about 4 months of work writing two AJAX apps using PHP with javascript and while the end result is what we were hoping for and the app runs beautifully, it took me a tremendous amount of time to code it as compared to a standard fat-GUI-app that runs on the client machine.

    I basically did a port of the functionality I had in two Perl/TK apps, but I wanted portability and easy updates of code and I had just done a stress test of AJAX in Firefox and IE and they both seemed to handle the load OK so I started developing.

    I did not use any tools aside from a text editor and the browsers to test in. The tools like SAJAX just created bloated code that crashed the browsers once things got too complex for them so I decided just to hand-code it from there on. I built in some session security and user authentication both of which ended up working rather well.

    These apps are querying other pages to get updates on phone system extensions statuses(from Asterisk) and other bits of information and updating DHTML elements constantly, so they do generate a lot of HTTP requests and use at least three times of the bandwidth that the fat-client perl/Tk app used to, but the database and web server seem to take the traffic OK and we thought that both of the browsers did too until we did some time tests.

    We were able to leave the AJAX app running in the same Firefox session for over 2 weeks before we had to reboot the machine for other reasons which was wonderful and much longer than we thought. But, Internet Explorer never lasted a day. It seems that in the ActiveX element that handles XML requests(IE itself doesn't do it internally like Firefox does) there is a memory leak and within 2 hours our app was chewing up over 120MB of RAM and was getting slower. We tried several fixes and the only way to get the memory back was to kill the iexplore.exe process(This was on IE5.0 through 6.1). And that is the reason we recommend only Firefox for intensive AJAX apps.

    In case anyone has read this far, the apps are GPLd and available on sourceforge. They are apps that extend the functionality of Asterisk PBX phone system extensions. You need to have Asterisk and the astGUIclient suite installed in order to test them:
    astGUIclient project page [sf.net]

    MATT---

    • Critique (Score:3, Insightful)

      by N8F8 ( 4562 )
      Normally I'm not one to comment on someone's coding style, but:
      • You do realize you can print/echo multiple lines of output at once in PHP? I also recommend using "print" for normal stuff and "echo" for debugging - that's just my preference though.
      • You also seem to program very linearly (I see a lot of stuff that should be functioned off).
      • Endless "if" statements can be written more clearly with the "switch" [php.net] statement.
      • Stay consistant with HTML case. I would suggest sticking with XHTML lowercase for tags.

        If yo

    • Re:Just developed 2 large AJAX-enabled apps (Score:4, Interesting)

      by Nic-o-demus ( 169477 ) <jwecker.entride@com> on Friday August 19, 2005 @07:48PM (#13359189) Journal
      And if you're going to be doing AJAX with Firefox, then you may as well use XUL [wikipedia.org]. I'm very excited for the day when we see intensive XUL/AJAX applications. THAT's going to be slick.

    • But, Internet Explorer never lasted a day. It seems that in the ActiveX element that handles XML requests(IE itself doesn't do it internally like Firefox does) there is a memory leak and within 2 hours our app was chewing up over 120MB of RAM and was getting slower. We tried several fixes and the only way to get the memory back was to kill the iexplore.exe process(This was on IE5.0 through 6.1). And that is the reason we recommend only Firefox for intensive AJAX apps.

      The leak is not with the XMLHTTP ob

  • AJAX will stop XAML dead in its tracks. (Score:3, Interesting)

    by IGnatius T Foobar ( 4328 ) on Friday August 19, 2005 @05:54PM (#13358550) Homepage Journal

    I can't believe nobody has mentioned XAML yet. Doesn't anyone remember hearing Miguel de Icaza ranting and raving about how XAML was going to spell the end of cross-browser, cross-platform web applications as we knew them, because everyone would be writing stuff that requires a browser that has the entire .NET API embedded inside it?

    It's becoming very clear that AJAX is going to stop XAML dead in its tracks. [citadel.org] Microsoft was pushing this whole "rich vs. reach" thing, but with AJAX you really can have it all. No need to restrict your user base to Windows XP or Vista in order to get rich controls in your web apps.

    I think that's the more interesting story here. The monopolistic Windows desktop isn't going to disappear overnight, but the continued existence, improvement, and increasing pervasiveness of web applications will continue to make the non-Windows desktop more viable and widespread. (Click on the link in the previous paragraph to read a longer piece on why this is the more interesting story.)

  • Everytime a new technology hits the streets or gains a large audiance there are always those who hail it as "the next big thing" like this article is doing with AJAX. Usually, it's a giant pop then a slow fizzle back into the toolbox.

    AJAX is great. But it's not like it's a reinvention of the WWW or the Internet or something like that.

  • I hate web interfaces. I'm happy they've gotten better, and also realize that in many instances, there are no alternative, but in general, I don't think the web browser was made for such type of interactions, nor should it be relied on for such hardships.

    While complex apps [intelimen.com.br] have been written for the web, not to mention the great things google has done, they are in the end still very hack-oriented.

    I think what is really needed to get things off the ground as far as usability is something that is: (a) (rea

  • OpenLaszlo is more portable (Score:3, Informative)

    by hqm ( 49964 ) on Friday August 19, 2005 @06:23PM (#13358719)
    OpenLaszlo [openlaszlo.org] is an open-source tool for building Rich Internet Apps that compiles them down to Flash applications. The advantage is that the graphics are smooth, it runs pixel-for-pixel identical in virtually any browser, no cross-platform incompatibilities.

    An OpenLaszlo app behaves essentially like an Ajax app; data requests are made for XML data (or media) in the background, and the user interface is presented as a seamless window-system style desktop app.

    Simple Example [laszlosystems.com]

    • problem is that that requires flash on the browser end to be installed. While not usually a problem, sometimes it is a requirement not to have ANY client side 'extras' ( applets, flash, plugins ) installed on the client. The XmlHttpRequest, which is really improperly named, it should be the AsyncJsHttpRequest object or something, actually allows me to do updates on a fill out form without refreshing the entire page. There is no XML in my stuff, just a JS onchange make the request, put result in div or sp

  • Why the hype? (Score:2, Insightful)

    by prophecyvi ( 249996 )
    I have to ask why all this is news lately? There's nothing new about using JavaScript to asynchronously update a portion of a page. At my company [lightyearxstream.com] (where I am the Web Services lead) we have been using this technique since 2001, and I don't begin to think we're on the leading edge of that. There have been people doing this since probably 1999.

    I ask the question, but I really know the answer. Somebody stuck the word "XML" in it and it suddenly became the holy grail of Web programming. It's a good methodology f

Slashdot Top Deals

The optimum committee has no members. -- Norman Augustine

Close