Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×

Foundations of Ajax 176

Posted by samzenpus from the clean-programming dept.
Craig Maloney writes "You've no doubt heard about Ajax. Practically every new and exciting application on the web uses some form of Ajax. Google's suite of applications (GMail, Google Maps, etc.), Amazon's A9 search engine, and Netflix use Ajax interfaces to give the user a better browsing experience. By using some pretty basic innovations to current technology, browsers can now deliver content in ways unimaginable only a few short years ago. Foundations of Ajax provides developers who haven't taken the time to look into Ajax a hands-on guide for quickly leveraging these technologies in their own applications." Read on for Craig's review.
Foundations of Ajax
author Ryan Asleson and Nathaniel T. Schutta
pages 273
publisher Apress
rating 8/10
reviewer Craig Maloney
ISBN
summary A good first-look at Ajax and client-side development using JavaScript, HTML, and CSS.


Foundations of Ajax starts with a brief history of interactive web-applications, starting from the crudest CGI and Java Applets, and chronicling various interactive technologies (Javascript, Servelets, ASP, PHP, Flash, DHTML, and the various XML browser languages like XUL, XAMJ, etc.). Ajax seems like another acronym in a sea of acronyms, but the authors quickly point out why Ajax can help with the development cycle. Ajax allows the server to validate the user's input, without creating ugly and messy JavaScript validation rules, and it allows the server to use the same rules for input validation on both the client and the server. Unfortunately, Ajax does break some of the conventions users have grown accustomed to in using traditional web applications. XMLHTTPRequest requests aren't stored in the browser history, and it can be confusing to the user to determine what changed on the page after refresh. Issues aside, the book is very encouraging on the prospects of using Ajax in web applications, and invites the reader to use Ajax where it makes sense.

Chapter 2 talks about the request method that makes Ajax possible: XMLHTTPRequest (XHR). The XHR methods are explained with several examples that detail the fundamentals occurring with the request. The examples are very clear, and the entire process is laid out in careful detail, although the Dynamic Object Model (DOM) is mentioned, but not explained until the end of the chapter.

Chapter 3 delves into server communication. It's interesting to note that the authors haven't instantiated a server yet for their Ajax communication, and for the balance of chapter 3, the server is replaced by text files. It's not until the GET/POST examples that the authors start using Servelets. While it may seem strange for the authors to be talking about client/server programming without instantiating a server, it does allow the developer to get their proverbial feet wet without battling server configuration issues. The chapter starts by introducing innerHTML, but then moves to using XML DOM for data transfer from the client. From there, the authors demonstrate a few examples of the server sending XML to the client, and the client sending XML to the server. Happily, the authors weren't content to leave us parsing XML using JavaScript, instead they finish up the chapter by introducing the JSON framework with a few examples.

Chapter 4 is really where the book starts doing very interesting examples with Ajax. It's also, coincidentally, the largest chapter in the book, and the chapter readers will find the most useful reference examples. The book steps through the creation of examples of Simple date validation, Reading response headers for a simple ping application, Dynamically Loading List Boxes, Automatically Refreshing Pages, Progress bar (a personal favorite), Tool tips, Accessing Web Services using REST, and Auto complete. Each example is introduced with a real-world working application as an example (such as the auto complete feature of the Google search engine), and could easily be implemented in a developer's application. I found myself thinking of ways to enhance my code using these techniques.

Following chapter 4's examples, the chapters on creating a developer toolbox, testing scripts using JsUnit, and debugging Javascript seem a bit of a let-down. Chapter 5 outlines various packages for helping JavaScript coders to better spot errors in their code, and create documentation using the JavaDoc-like application JSDoc. There is also a mention of an application for crunching and compressing JavaScript code, as well as the excellent Web Developer Extension. Rounding out the chapter is a brief history of JavaScript, and some advanced JavaScript techniques. Chapter 6 introduces JsUnit and Unit Testing. Chapter 7 talks about JavaScript debuggers, such as Microsoft's Script Debugger, and the very powerful Venkman. The Venkman tutorial is very good, and would be a great starting point for anyone wanting more information on how to use this great tool.

Chapter 8 rounds out the book with the typical "for more information" sites to visit. However, in true Steve Jobs "One more thing" fashion, the authors not only plug their Ajax Framework, but also create a browser-based, Macintosh-like Dashboard application with four widgets. I was all set to finish the book, but the authors quietly slipped the best for last in the final pages of the book, bringing out a complete Mac OSX-like "Dashboard" windowed-environment in a browser complete with the drag-and-drop elements I've most associated with Ajax sites. This is by far the most complicated project in the book, and it make for an excellent ending to an already fine book.

Foundations of Ajax is a great starting point for developers wondering how they can incorporate Ajax into their own web-based projects. One minor gripe I had with this book was the examples looked pale in comparison with their real-world models, but design is hardly the focus of the book. Where Foundations of Ajax shines is it's no-nonsense introduction, implementation, and expansion of the basics of Ajax programming, leaving the reader confidently ready to utilize the concepts within. The authors have seen the potential of Ajax, and competently convey their expertise and enthusiasm for this technology."

You can purchase Foundations of Ajax from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
This discussion has been archived. No new comments can be posted.

Foundations of Ajax More

Foundations of Ajax

Comments Filter:
  • Not even one mention of "Web 2.0"!
    • That was by design. I hate the term Web 2.0, and will personally spoon out the brains of anyone who uses the term with a straight face.
      • You've got my vote!
      • Heh, I don't see why people have such a hatred of everything that can't be quantified. Just because it can't be measured, doesn't mean it doesn't exist.
        • It's because it's used whenever the speaker wants to sound like they've got the inside track on whatever is new or exciting. Unfortunately it's been so overused when describing new and exciting things, it's lost all of it's novelty and excitement. Now, when I hear the term "Web 2.0", my "bullcrap" meter is engaged instinctively.

      • I hate the term Web 2.0, and will personally spoon out the brains of anyone who uses the term with a straight face.

        Fantastic. What do you do to people who use the term Web 3.0?
      • I hate "Web 2.0" too. How can you simplify such a cross-section of intrensic and diversion paradigm shifts and technology consequence bubbles into a single simplistic phrase like "Web 2.0". Answer: you can't. We're at a major technoecosocial crossroads here... let's keep the plan flying, our eyes focused on the goal, and remember that doers do and winners win.
    • Tim O'Reilly has the trademark on the phrase "Web 2.0".

    • Not even one mention of "Web 2.0"!

      You can always count on slashdotters to shoot down anything that smacks of enthusiasm.
  • could someone kindly link a page that demos ajax's features?
    • Google suggest [google.com] is a simple one.
    • GMail [google.com] and Google Maps [google.com] are the obvious ones.
    • Here ya go :D

      World Airport and Airspace Database [roborg.co.uk] - Really cool if you like looking at aeroplanes and airports

      GeoNews - News with geographical data [roborg.co.uk] - See global news feeds parsed for place data and plotted on a map.

      Both these projects use Google Maps - the second one has a few special features added, like a custom zoom tool and locator beacons. I'm going to make the source available as soon as I neaten it up a bit and write some documentation.
    • http://script.aculo.us/ [aculo.us] has some interesting scripts (like drag-n-drop)

    • To the author(s) of the book and everyone else - AJAX is an acronym, for Asynchronous JavaScript And XML (or more appropriately, Asynchronous JavaScript + XML). Unfortunately, the book [amazon.com] does not recognize this.

      More unfortunately, Adaptive Path, the coiners of the original term/acronym also do not [adaptivepath.com].

      Unless I'm missing something...

      • Damn not previewing. My comment was meant to imply that BEING an acronym, AJAX should be in all caps, just like HTML, XML, etc. Not "Ajax".
      • From a page on IBM Developer Works [ibm.com]: "The phrase was coined by Jesse James Garrett of Adaptive Path ... and is, according to Jesse, not meant to be an acronym." (emphasis in the article).
        • according to Jesse, not meant to be an acronym." (emphasis in the article).

          It's nice if, in retrospect, you don't want a word to be an acronym, but as popular as certain words get, they are and will still be acronyms, like RADAR, which is often represented as "Radar" or "radar" in terms of capitalization in print media.

          The fact is that AJAX (or Ajax) is in fact a direct derivation of the first letters of the words it represents, and thusly is, like it or not, an acronym. Further, I would think it impr

          • Further, I would think it improper to allow developers to use AJAX without understanding the actual underlying meaning.

            Really? Improper? For a little perspective, we used to think that it would be improper to code in C if you couldn't write assembler. Suprisingly lots of people were successful at a higher level of abstraction without understanding the underlying structure.

            Ajax is just a more recent example of the same phenomena. For now, it's important to understand the underlying technologies becau

      • Are you sure about it being an acronym? From the Adaptive Path site [adaptivepath.com]:

        "Q. Why did you feel the need to give this a name?

        A. I needed something shorter than "Asynchronous JavaScript+CSS+DOM+XMLHttpRequest" to use when discussing this approach with clients."
    • The journalspace fast media finder [journalspace.com] is yet another example. Start typing in the box, and watch what happens.
  • While I appreciate this review, is the book really neccessary? AJAX moves very quickly, with new/better examples popping up everyday. Maybe it's me but I find less of a need for technical books and magazines since I can get all of my information from the internet. The personal example I'll use is Sys Admin; great magazine but I haven't leanred much from it during the last year. If I want to learn a specific server app or hack it's just easier and more up to date to grep it online.
    • Call me an old fogie (I'm not THAT old!) but I prefer real books in a lot of circumstances. Especially when trying to get a full/complete understanding of a topic. Reading a few hundred pages on-screen gets to be painful on the eyes. And it's easier to take a book a lot of places - outside, on a plane during take-off, the toilet, on a date. ;)

      Now if it were a reference manual, then I'd be more likely to agree. But even there, a lot of us like to lay the hard-copy book down on our desks while we program. Jus
      • "Call me an old fogie (I'm not THAT old!) but I prefer real books in a lot of circumstances.".

        You're not old you just haven't gone paperless yet. It is difficult.

        If you already know cgi programming and don't know ajax all you need is this:

        Rasmus' 30 second AJAX tutorial. [rajshekhar.net]

        It's just call back functions for the web; most good programmers could pick this up in an hour. I looked at the 30 second tutiorial and only needed to understand the syntax, it's obvious what it does. That took 11 seconds not 30.

        • Please don't promote that awful tutorial. It makes two classic newbie mistakes: javascript: hrefs and browser detection. These are stupid [jibbering.com] and wrong [quirksmode.org]. Yes, I know Rasmus is a hot shot PHP developer, but his Javascript sucks.

          • I know Rasmus is a hot shot PHP developer
            There's an understatement!

            I don't find Rasmus' AJAX tutorial all that bad. His point is that it's not all that hard to do AJAX. I do agree that he's not up on the latest JavaScript best practices though, so he ends up doing JS things the wrong way sometimes.

            • Oh it's a shitty example. Maybe it's ad javascipt. That's ok I write terrible HTML. But it works. On all platforms in all browsers, even lynx.

              It can't be that bad of a tutorial as I actually added Web 2.0 AJAX functionality leveraging legacy infrastructurte.

              In other words I added a quick hack to an exising webware app of mine in under 5 minutes.

              Sincerely,
              Dilbert

            • These are hardly "latest best practices", they are well-established principles that have been around for the best part of a decade. For instance, here's a posting from 1997 [google.com]:

              Ugh. Don't do that. Browser detection is a last resort. Always use object detection if possible.

              Here's a posting from 2001 [google.com]:

              Most experts recommend not using the pseudo-protocol "javascript:" for different reasons. There have been numerous discussions about this in this very NG

              And another from 1999 [google.com]:

              The practical side of

        • You're not old you just haven't gone paperless yet. It is difficult.

          You make it sound like being paperless is the goal. I suppose that's a decent goal to have, in order to help the environment. But I have a bigger goal -- to read what I need/want, when and where I want, comfortably. And in many cases, books are still a lot better at meeting that goal. Granted, the Internet helps me achieve that goal a lot of the time, but not always. I'd consider going paperless a secondary goal for myself.

          As far as Rasm

          • "You make it sound like being paperless is the goal."

            Well, it does save on ink.

            When I learned this stuff (c/unix) there were no books, except the K+R books so I'm used to learing by hacking. I find books tedious and annoyingly slow. I can learn things faster by doing than reading and have been doing this long enough that I'm generally aware of common pitfalls.

            Other than K+R 1st edition I did buy an O'reilly book once, for one page had some answers that at the time google could not produce.

            I realize the book
    • As someone who's read the book (and previously commented on it here), this book is just what the title says, "Foundations". It is not a comprehensive analysis, nor does it attempt to lead the reader through graduate level UML and design pattern analysis like some other massive tomes. It delivers the basic concepts, shows a few nice examples, and provides lots of links to sites doing interesting things w/ AJAX.

      So I'd say, yes, the book is neccesary. Rather than meandering all over the web trying to figure

  • So, is there an IDE like Visual Studio for AJAX, or are we expected to wade through pages of HTML and Javascript like in the old days of the web? In my opinion, GUI applications are best developed inside GUI applications.

    • In my opinion, GUI applications are best developed inside GUI applications.

      Ajax applications are not GUI applications. They are web applications, and the web isn't tied to a single type of interface.

      People who pretend the web is GUI-only usually end up building things that are fragile and inaccessible, not just for the people who don't use GUIs, but power-users and people using alternative user-agents as well (e.g. search engines, UserJS/Greasemonkey scripts, etc).

    • Microsoft has a project called Atlas [asp.net] that does exactly that. Bill
    • An IDE for AJAX? Heavens no. Take the Ruby on rails approach. Try like hell to avoid javascript. ROR has it all nicely abstracted so you don't have to deal with javascript (mostly)

  • I feel sorry for all the trees that have to be cut down needlessly so that developers can try to keep up with the latest crappy technology that will obsolete in less than 2 years.

    On the bright side, at least its under 300 pages long.

  • I know PHP/Javascript/HTML relitivly well. Do you think this book would be an easy read for me. Or would I really have to sit down and try. Heh, got the book for christmas and just looking for time to read it.
    • I think the book may be more of a sit-down book for you, only because there's a bit of it that relies on Tomcat and JSPs. Outside of that hurdle, you'll likely find it pretty easy to work through. There's not that much to Ajax, all told, but this book will help you piece together the various parts to make it work better for you.

      Hope this helps!
    • I was in the same position as you... just read through online tutorials and you'll pick it up in a few hours. There's no need to sit through an entire book. With the tutorials you'll pick up the basics and then from there you can decide how much MORE you want to learn. I don't think most people want to get up to the google maps API level anyway.
    • i've used that method and it will never be as popular as AJAX, because AJAX leverages everyone's love for XML. really it seems to work just the same, with the server sending javascript code and data structures instead of XML. be sure to add a random querystring value to the script call, or else you're going to get some monstrous caching issues :)
    • or

      doc = document.implementation.createDocument("","",null) ;
      doc.onload = onload_function;
      doc.onError = onerror_function;
      doc.load("data/request.php?" + arguments + "&" + timestamp );

      Which is the standards-compliant, non-crazy-scripty way of doing it. Also this method and yours SHOULD both respect the same-source rule. If it doesn't, it's a browser bug. Also, it won't display your data in the page by accident if you make a mistake in your stylesheet (class/name that's styled "position: absolute;" in yo

      • Which is the standards-compliant, non-crazy-scripty way of doing it.

        Actually, that's not true. The load() method [w3.org] was part of early DOM3LS drafts, but was taken out before the specification reached Recommendation [w3.org] status. As far as I'm aware, there's no non-draft specification describing load(), nor plans to write one.

        XMLHttpRequest, on the other hand, is part of the draft "HTML 5" specification [whatwg.org] published by the WHATWG, and I expect it will remain there permanently.

        • And the "script injection" method IS standard-compilant as far as you believe in standards. Thing is "standards" don't equal to "perfection", standards have their own errors too.

          Standard specifies you're allowed to insert any DOM element at will, and makes no special exceptions for "script." It makes lots of assertions about cross-window, cross-frame etc scripting, about limits of what can you do with elements inherited by inserted elements etc, but in normal conditions you're free to load a script from an

          • And the "script injection" method IS standard-compilant as far as you believe in standards.

            Um... as far as I believe in them? Is their existence in question?

            It's abusing a hole in the specs, because "script" elements should be treated differently than others and follow different rules when created upon document creation than when inserted through DOM methods

            That's your opinion. But how is it "abusing a hole in the specs" to do something according to spec and have it work according to spec?

            • Do you believe in Apocrypha? Apocrypha exist.

              you add a script element and it is parsed and executed... seems fairly straightforward to me.
              Except the specs came to lengths to prevent this kind of behaviour in cross-domain linking. You can't perform xmlHTTPRequest for a website other than the one the page is loaded from. You can't do shit to a DOM tree of a document in other frame/window. The specs' intention of preventing ability to dynamically load scripts from sites other than where the page comes from see

              • Do you believe in Apocrypha? Apocrypha exist.

                Please be more clear. This is the second time you've skirted around what you are trying to say here without coming out and saying it.

                Except the specs came to lengths to prevent this kind of behaviour in cross-domain linking. You can't perform xmlHTTPRequest for a website other than the one the page is loaded from. You can't do shit to a DOM tree of a document in other frame/window.

                So? There's a huge difference between XMLHttpRequest, iframes, etc,

    • Yeah, but no built in support for errors or callbacks.

    • It's

      document.createElement("script")

      There's no such method as

      createNode

      in DOM [w3.org] (which, contrary to what the reviewer says, stands for Document Object Model, not Dynamic Object Model).

  • yep, its a good book (Score:3, Informative)

    by DeveloperAdvantage ( 923539 ) on Wednesday March 01, 2006 @02:55PM (#14828957) Homepage
    I have actually read/worked through this book and indeed it was not only one of the first books on Ajax but also one of the better books on Ajax. Some of the portions are now a little outdated, like the discussion on frameworks, but these areas can easily be filled in with a little research on the Internet.
  • I personally, use Comet, but only because it has a cool song [wikipedia.org]

    Oh, that Ajax.

    Nevermind...

  • Off Topic (Score:3, Interesting)

    by TubeSteak ( 669689 ) on Wednesday March 01, 2006 @03:06PM (#14829069) Journal
    But is something going on with the moderator points? Or is it just a slow day (or three)?

    I noticed all the stories have very few comments modded to 3 or above. And by few I mean 20. Just skip through any of the articles on the front page.

    Did I not get the memo?
  • ...InstantRails [rubyforge.org] makes it easy to get it up and running, and Rails definitely has AJAX support built in.

    I'm using AJAX a fair bit (mostly on the admin pages) on getindi [getindi.com]; it's very handy stuff!

  • All "Ajax" means is that Javascript now works. I used to accomplish the same tasks (i.e. asynchronously send/receive bits of data, dynamically update tables without refreshing the whole page) using hidden frames and javascript submits back in 1999. Javascript now has built-in functions to do this so it's less of a hack, but I don't think that it merits a whole new buzzword.

    Then again, I guess it's something for new startups to tout and investors to latch on to, so maybe it's more of a business/marketing b

    • Yeah, this was hardly "unimaginable" a few years ago. It was more like "what do you mean, none of this stuff really works the way it ought to?"

      AJAX is just a hack on top of a kludge to try to make a stateless batch protocol into a persistent interactive "experience". HTTP works fine for what it was designed for, HTML works fine for what it was designed for, AJAX reminds me of the classic Yiddish joke about the tailor:

      Schlumpf the tailor made a suit, but one sleeve was longer than the other. To the cust

    • Yeah, I was doing pages on paper way back in 1984, and now we've got to go calling it "the web." Goddamn buzzwords.

      Seriously, everyone here clearly understands what is meant by Ajax, and it's less clunky than "asynchronously send/receive bits of data, dynamically update tables without refreshing the whole page," so I can't complain. You, however, are welcome to bitch until the cows come home.
  • I want to use it.

    Damn marketing driods
  • I picked this book up on my last trip to Vegas. I read it cover to cover. I found it to be on the elemtary side of the AJAX discussion. I was disappointed when I found most of the content, code examples and demos can be found online in different places. AJAX is just a hot topic right now, I find this book as an attempt to ride the coat tails of the AJAX phenom.

  • OK book (Score:5, Informative)

    by wanorris ( 473323 ) on Wednesday March 01, 2006 @03:35PM (#14829413) Homepage
    I have this book. It's a pretty straightforward introduction to the topic. The central problem with it is that all the examples that use server-side components only use Java.

    If you use Java, great. But the book title is misleading, and it should be called "Foundations of Ajax in JavaScript and Java."

    The other caveat: the book is designed for people who want to use Ajax to spruce up an existing web page a little, not design new applications built from the ground up to use Ajax as the data transport mechanism. If this meets your needs, great. If you're looking to do bigger stuff, get "Ajax in Action" froom Manning.
  • I also recommend that you check out the Gecko DOM Reference [mozilla.org]. It's a great, handy online resource which I've consulted frequently as of late for many DHTML apps and functionality.
    • Well there's a bad idea. If you want your code to be cross platform, always go to the source [w3.org] for your information. Otherwise you're guaranteed to get burned. It's bad enough that Internet Exploder refuses to support DOM Events. Throwing stuff that may be Mozilla specific into the fray is a sure-fire way to make it that much worse.

  • Is it good or is it wack?

  • I think it is more like, when using AJAX, user interfaces are slowly creeping back up to where they were 10 years ago, before everything was crippled to work as a web form in the lowest common denominator browser. Web interfaces still have a hell of a long way to go before they are even close to the level of sophistication that rich clients were at 10+ years ago. Everything that is new was old once before.

  • DOM (Score:2)

    by tamnir ( 230394 )
    Dynamic Object Model!?

  • Practically every new and exciting application on the web uses some form of Ajax.

    If by "new and exciting" you mean "redundant and obnoxious", then yes. Yes they do. So much for being able to browse information in a way that I dictate; now I'm subject to the whims of some insane application living inside my web browser.

    If that's what it comes to, why not just stick with Flash? At least with Flash, it doesn't take a dozen images and pages of CSS to effect a rounded rectangle! (This may be an exaggeration!)

    • Ok, let's consider an example: Google Maps. Are you suggesting that Google Maps prevents you from browsing a map the way you dictate? What exactly was it about MapQuest that was so flexible? Look, Ajax at its worst is no better than Flash at its worst, but at its best it provides *more* options, not fewer. And without the performance hit of reloading a page header and a bunch of navigation over and over.

      Me thinks his knee jerketh too much.
      • Google Maps is a fantastic application of AJAX, most definitely. I wouldn't have written this map module [severinghaus.org] for Gallery2 [menalto.com] if it did not rock my tiny world.

        Keep in mind, though, two things. First, Google Maps is the exception to the rule in terms of the tradeoff between usefulness and complexity (in the sense of lacking a reasonable degradability for browsers without the necessary functionality). Second, imagine how much better [google.com] Google Maps would be if it didn't have to be crammed into a browser.

        • I have to disagree on a couple points. First, I don't think it's the exception at all. I'm not going to provide a list of great Ajax applications, as that's been done a million times on Slashdot. What I have *not* seen is a reasonable list of Ajax failures. I am inclined to believe that a lot of criticism of Ajax is merely theoretical.

          As for Google Earth v Google Maps, sure Google Earth is an interesting app. Is it a better app? Well, not really in terms of usefulness. Most of the time if I'm looking for an

  • JsUnit and AJAX don't mix! (Score:3, Informative)

    by Darkforge ( 28199 ) on Wednesday March 01, 2006 @07:17PM (#14831341) Homepage
    I had originally picked up a copy of this book because it appeared to be the only book on the market that spent any time discussing automated testing of AJAX components.

    As I'm sure you all know, testing AJAX stuff in multiple browsers is really important if you want to guarantee cross-browser compatibility; it's also really tedious. JsUnit seemed like it would be a promising tool for AJAX automation.

    In fact, I'm sad to say, JsUnit can't be used to validate AJAX components at all; in fact, it can't it be used to validate *any* command that requires a callback, including XmlHttpRequest, event handlers, pop-up windows, etc.

    This is because browsers (IE/Firefox both) interpret JavaScript in a single thread, but actions you perform may have asynchronous side effects OUTSIDE of your own thread. So when you attempt one of those fancy asynchronous XmlHttpRequests, you can't just sleep/wait until your request finishes, because it will *never* finish until you completely return from your current thread. Only then will the interpreter begin working on the next item in the event queue.

    That means, among other things, that it's impossible to wrap an AJAX request in a "try/catch" block:
    try {
          doRequest();
          waitForRequestToFinish();
          assertRequestWasSuccessful
      } catch (e) { // do something }
    Because this will never work, JsUnit's strategy of emulating JUnit or the other *Unit frameworks is fundamentally unsuitable for testing AJAX in multiple browsers.

    If you *are* interested in testing AJAX applications in multiple browsers, I recommend looking into Selenium [openqa.org], which basically works around the problem by constantly scheduling timers to re-invoke itself every 10ms... that gives the interpreter enough time to do other work, and allows Selenium to implement a simple "pause" action that actually works.

  • By using some pretty basic innovations to current technology, browsers can now deliver content in ways unimaginable only a few short years ago.

    Wha? I happily admit that we've seen some pretty cool uses of the available technology in recent times, but I've personally been doing what is now known as Ajax for at least 5 years.

    Would people please stop taking all the fun arcane stuff and wrapping up in media-friendly (and code monkey friendly) parcels?

    Now a good chunk of my fun work will be replaced by some co

Slashdot Top Deals

For God's sake, stop researching for a while and begin to think!

Close