Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Book Reviews Books Media

Ajax in Action 270

Posted by samzenpus from the read-all-about-it dept.
Simon P. Chappell writes "There's always a danger when a new technology buzzword hits the ground running. The danger is that when it finally slows down enough for us to take a good look at, it'll be found to be empty hype with less value than a mime performance on a radio show. This time the buzzword is Ajax and it's moving so fast that you can almost hear the sonic boom. The authors of Manning's new Ajax in Action have managed to catch up with Ajax long enough to take a look at it for us. Their book explains what Ajax is, how to use it and how, for once, the hype may be underselling the prospects for this new buzzword." Read on for Simon's review.
Ajax In Action
author Crane, Pascarello with James
pages 650 (16 page index)
publisher Manning
rating 9/10
reviewer Simon P. Chappell
ISBN 1932394613
summary If you want to create dynamic web applications, get this book.


The majority of the book is for programmers engaged in the development of web applications; especially those who are interested in taking their applications beyond the traditional ``click and wait for the response from the server'' model that we've become accustomed too.

The first section, and particularly the first chapter, would be suitable for anyone who is curious about Ajax. The first chapter answers the questions of what it is, and why it deserves all of the positive press that it's received. If you're introducing Ajax at work, this might be the chapter of recommended reading for your managers and software architects.

Alright, enough introducing the book, now let's take a look at just what Ajax is. Ajax itself is an acronym created by Jesse James Garrett in his, now classic, article Ajax: A New Approach to Web Applications. Ajax, we are told, means Asynchronous JavaScript and XML. This is our first clue that Ajax is not a single, new thing. Ajax actually turns out to be a combination of existing technologies mixed up in a fairly new way.

The fundamental ingredients in Ajax are in-browser JavaScript, Cascading Style Sheets, the browser's internal DOM model and asynchronous HTTP requests. Ajax, the technology, is the amalgam of these individual technologies. Thus, Ajax is both new and well proven at the same time.

Perhaps it's also possible to view Ajax as the natural resting place of the pendulum of application development. Programmers, since the beginning of application development have been trying to balance user experience and ease of installation and maintenance. First we had mainframes with their centralized usage model. Next we got the PC with it's entirely disconnected usage model. This was followed by the Client/Server model that tried to be connected yet offloaded it's processing to the client. The world wide web came next and browsers as the ultimate thin clients forced all of the processing back onto the server again. Finally now, with Ajax, we have what seems like a good balance of server side processing, with responsive clients that provide the rich user interface that users want. The pendulum of centralized versus decentralized has found it's rest point.

The structure of the book is fairly standard. The first section, three chapters, concentrates on imparting the concept of Ajax to the reader. The first chapter begins with the concepts, chapter two takes the reader through some very simple first steps, while chapter three explores how the Model View Controller pattern (MVC to it's friends) applies in the Ajax world and looks at third party, free and open-source Ajax libraries available today.

Part two of the book explores the core techniques of Ajax. Chapter four explores the difference between a web application and a desktop or Ajax application, that of a single page being the entire application. Chapter five explores the role of the server, looking at what resources are available for the server-side coding, including available languages and frameworks as well as ways and means of exchanging data with the server.

Part three looks at what the authors call ``Professional Ajax'', the techniques that make a difference when creating real world applications. Chapter six covers the design of the user experience. The user experience for a major application basically is the application for the user and so getting this right is of fundamental importance. Chapter seven explores security and some of the actions that the developer can take to both ensure access control and protect confidential data. Once the basics of Ajax are mastered, this may well be the most important chapter in the book. Chapter eight covers performance and what can be done to assist application speed and resource usage in practical use. Perhaps the most important measure for an Ajax application is the perceived speed and responsiveness that it delivers. The asynchronous processing is a huge factor in achieving these user perceptions.

Part four shows Ajax by example, with four chapters of example applications and a fifth chapter addressing building stand-alone applications using Ajax.

There is much to like about this book, but top of the fold for me is the clear and concise explanation of just what exactly Ajax is and why it has the power to make a difference in the web application arena. At a time when more people speak of Ajax than actually understand it, this book has the power to bring forth understanding.

This is a very dedicated book. It takes no time to teach the reader the individual technologies that compose Ajax, rather it concentrates on using those technologies. If you do not know JavaScript, or Cascading Style Sheets or do not understand the W3C's DOM model or asynchronous messaging then you would be better served at this time by learning the individual technologies and saving this book for after you've mastered them.

Other than the standard book page over at the Manning website, there is no dedicated book website. This is perhaps unusual, but 30 seconds on your search engine of choice should get you started. Failing that there is a good Ajax page available at Wikipedia.

This is a magnificent book. Not because it's well written and has good example code in it, although it is and it does. Rather, it is magnificent because of the high speed target that they have accurately hit and described in a clear and hype-free fashion; for this the authors are to be commended. If you want to create dynamic web applications, get this book."

You can purchase Ajax in Action 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.

Ajax in Action More

Ajax in Action

Comments Filter:

  • AJAX explained... (Score:5, Funny)

    by nother_nix_hacker ( 596961 ) on Wednesday November 23, 2005 @01:54PM (#14102340)
    No need to buy this book. Just consume one of these and you will awake the next morning know how to use javascript and XML in unison to produce yet another del.icios.us clone!

    http://www.cleansweepsupply.com/pages/skugroup1068 .html [cleansweepsupply.com]
    • ...know how to use javascript and XML in unison to produce yet another...

      The interesting thing is....the X in AJAX which does stand for XML is not all that applicable. You don't need to use XML to be doing pure AJAX. X is just a sexy letter. I think that's the only reason it's in this acronym.
    • "I'm Simon Chappell, bitch! Read my book!"

  • I think I buy into this "ajax" thing (Score:5, Informative)

    by gtrubetskoy ( 734033 ) * on Wednesday November 23, 2005 @01:54PM (#14102343)

    Paul Graham's got an opinion on Ajax in his Web 2.0 essay [paulgraham.com].

    I too initially thought "What's the big deal, it's just JavaScript". But I'm now actually reading the "Ajax in Action" book, and it looks like there is something to it. It's not so much about the tools you use (which are indeed JavaScript and CSS pretty much), it's more about the architectural view of the application, where you think of the browser hosting your application rather than content and the server produces data rather than content and how Ajax coding is not just get-the-javascript-to-work-and-move-on like in the old days, but rather not unlike any other language, requiring same level of discipline.

    Anyhow, the book explains it better, I recommend it.

    • Could we finally get push technology with AJAX?

      I'd like to have the following, all of which have been cumbersome and refreshy to implement in a web browser so far:

      • A news page that I can leave open and automatically gets new stories added to it without refreshing. (CNN that I can leave open and know that stories will apper within a minute of them being posted)
      • A stock ticker that is always up to date. (Yahoo finance that I don't have to refresh)
      • Weather forcast and current conditions that change in real
      • No. AJAX, for all it's hype and buzz and crapola, does not fundamentally change the client/server nature of HTTP and the web. AJAX applications that load data do it by polling, exactly the same as meta refresh tags and timer-based javascript refreshes have been for 10 years.

        • AJAX applications that load data do it by polling, exactly the same as meta refresh tags and timer-based javascript refreshes have been for 10 years.

          Polling... yes.
          Exactly the same way... no.

          Ajax is not the end all of programming technologies, it is, however, very useful. I'm completing a rewrite of an internal project for work using xajax. The user interface is so much better than before it's amazing. It has allowed me to add the little usability pieces that just aren't possible with traditional methods

        • Polling it can do, but AJAX is so much more than that. It enables interactivity much the someway a thick client desktop application does. Whether the execution of the code is being done on a remote location or a local system is really irrelevant. I'd even go so far as saying, if done right, it can make a large portion of thick client desktop applications space obsolete.
      • You really can't do "push" with webpages, or their data. You could make something that looked like push, but in reality is actually just polling. The problem with this is that AJAX is supposed to reduce the amount of traffic to a website. If you have users constantly polling you for information, you're going to increase your load. I guess it would be better than polling and getting an entire page every time. We'd need to change the way AJAX works in order to get something that was truly "push".
        • I imagine a browser querying specific bits of data is a lot less of a load than a user hitting "refresh" on the browser periodically.

          -matthew
          • Polling is ok for somethings, really not good for others.

            What if you had a number of people in a chat room written in ajax. You would have to poll very frequently, every few seconds or so, for each person in that chat room. If your chat room gets any number of users, you going to be pushing a lot of traffic, most of which would be avoided if we could do server side interrupts.

            What if you have a call center, and you have a thing on your page that is showing incoming calls, this is another case where you woul
        • I AGREE!

          I have this book, and I am writing ajax for production use a work right now. If there was an easy way to set up server side interrupts, we could have our pages do much cooler things, and it would actually probably be much easier to write.

          Basically what this means is that along with doing async requests, ajax would have to open a socket, either a plain socket, or sslv2/sslv3 or whatever, and then the client side scripts on the server could write things to this socket.

          The tricky part would be how the
      • Everything except the last is pretty easy, although your websites will of course have to actually implement it, or you'll have to do a lot of work yourself.

        The reason it's easy is that it would work much like old push technology; you'd actually pull the information periodically. You can have some problems with unavoidable memory leaks in the web browser, but other than that it would be easy.

        That last one is interesting, and while it is also possible would require a lot more work by a web-based RSS aggregato

        •   web browsers are mighty big hammers now, but many problems still aren't nails.

          Well said. But still, any variant on the hammer/nail saying requires me to invoke my own version:
          "A sufficiently powerful hammer is capable of transforming any problem into a nail."
          --dgould's First Law
      • Well, no, but what you can do is make your refreshy polling things more lightweight and more invisible, so that they sometimes give the illusion of being a push technology.
      • I think you can do all of these things since you can have javascript in a while loop/sleep or whatever and then every x number of seconds have the javascript call the function to update the page. I don't do a lot of client side programming, precisely because I can't guarantee what's on the client, but javascript should be able to do that.

        The examples you have here though can also be handled by a meta-refresh. Unless you wanted different sections of the page to update at different intervals. So that the s

      • Re:Can AJAX finally bring us "push technology" (Score:5, Interesting)

        by _xeno_ ( 155264 ) on Wednesday November 23, 2005 @02:28PM (#14102649) Homepage Journal

        Nope. Push is dead, NAT killed it. (Well, a whole bunch of things killed it, but essentially you can't connect back to a client any more, and there are a whole host of reasons why you generally don't want to leave connections open.)

        However, you can do what email clients have done for ages: poll. And that's what things that emulate what you're talking about essentially do.

        Essentially, with AJAX, you'll have some JavaScript program that uses the good ol' window.setInterval to poll the server every five minutes or so. It gets back an XML document that contains a list of changes, if any, to the page you're looking at. If the data has changed, it then uses the DOM to alter the page to display the new information.

        Effectively, though, it's just a page that refreshes automatically via JavaScript. Because it can pull back an XML document, it doesn't have to download ALL the HTML stuff to get the data. Because it's in the background, it doesn't have to "destroy" the page to load the new information, allowing it to be added to an existing page in a seamless manner.

        It's really nothing new, exactly, it's just that the most popular browsers (Internet Explorer, Firefox, Opera, and Safari) all support XMLHttpRequest in some form now, making it feasible to use it without cutting out some section of your user base. It's just message passing in JavaScript.

        • NAT didn't kill push. Push technology is very possible using XMPP, rather than HTTP as the presentation layer. You build something like XMPP Publish-Subscribe on top of it, and then plug in a browser. The browser sends your JID to the server (or a proxy JID if you want anonymity) and subscribes to the pub-sub node relating to the page / web app. Every time the server wants to send to some information, it can. You keep a TCP/IP connection to your XMPP server open while you are online, and the web server
          • No he is saying NAT (Network Address Translation) makes conneting to a client without a constant open connection virtually impossible.
            • Push doesn't require you to be able to make a connection to a client. It requires you to be able to send arbitrary data to a client at any time you choose. XMPP allows this, and has no problems with NAT, since the client connects to their XMPP server and remains connected.

              Even without NAT, push technology requiring the server to initiate connections would be broken by things like dynamic IPs and people configuring firewalls not to allow incoming connections.

          • That's what I was thinking too. (not that I have any acronyms for it).

            Basically the client just makes an XML request equivalent of "tail -f", and the server periodically just sends one more packet down the TCP pipe.

            In order to do this over http, you might have to lie about the content-length (make it very large, and then close the socket when done), but that should be ok.

            I'm sure someone must have implemented streaming over http before?
            • This is easy in theory over HTTP, but difficult in practice. The reason is HTTP proxies. Many of them don't forward the reply to the client until the stream is closed, or have other bugs/features that are encountered with open-ended connections like this (such as closing the connection if the data rate drops below a certain threshold to stop people DoSing them by running a large number of slow connections through them until they run out of file descriptors).
          • That whole technology relies "You keep a TCP/IP connection to your XMPP server open while you are online", which is already doable with HTTP. The client makes an AJAX call to the server, and if the server has data to return it sends it back immediately, otherwise it waits and holds the connection open until $TIMEOUT. If $TIMEOUT is hit it sends a "no data" message to the client, and the client reconnects again each time. This is how http://www.meebo.com/ [meebo.com] implements pseudo-push to create the webgaim bridge,
            • There are several differences:
              • Keeping a connection open to every client is not very scalable. You will run out of file descriptors, and if you don't you'd better make sure your TCP/IP stack can handle it.
              • With XMPP, each client needs one connection, not one connection per remote app.
              • With XMPP, each app server just needs one connection per remote user's server.
              • With XMPP, the user can remain registered with the server and be notified of updates without needing to connect directly even when the machine mo
        • You can do push with AJAX using persistant http connections using XMLHTTP. This is very useful and allows you to do basically any type of interactive application.

      • Poll and Pull slowly (Score:2, Informative)

        by jhliptak ( 619614 )
        You can only do one thing with AJAX: change a section of a screen with data from a server without reloading the entire page.

        What does that mean for push? It means that you can't do it. There is no real way to establish a connection from server back to the client.

        So then what's the excitement all about? There are two things you can do with AJAX that a "normal" web app can't do:

        • You can poll a server and update a portion of your web page. This method of polling can provide all four of your requests.

      • Yes and No. One approach is to use have the client initiate an AJAX request to the server but the server does not send data immediately. It delays until there is stuff to push. It can either continue to push as needed (I send Java which gets evaled by the client) or it can close the connection and have the client re-connect. It then goes back to the delayed response.

        This is better than client polling in that it's not so bandwidth unfriendly. It has the downside that browsers only have a limited number of c

      • While I am generally not one to hype AJAX, your first 3 points are nobrainers with ajax. You just set a Javascript timer to periodically poll the server and replace esxiting div's or whatever with new content. Super easy.

        As for gluing them together, I think that is beyond ajax. You'd probably have to design your own webpage that glued them together and hope they don't change the format of the data any time soon.

        -matthew
    • I too initially thought "What's the big deal, it's just JavaScript". But I'm now actually reading the "Ajax in Action" book, and it looks like there is something to it. Anyhow, the book explains it better, I recommend it.

      You make it sound so new and mysterious.

      AJAX is simple. We now have a cross-browser method for making server requests in an asynchronous fashion. Combined with the fact that the demise of Netscape 4 means that we can finally code for the DOM, and you've got a recipe for success. It's not anything magical or mysterious. In fact, you could do it with hidden IFrames long before AJAX even became a buzzword. The key is that it's useful and semi-standard. Which means that we can finally deploy all those cool web apps we've wanted to deploy for years but couldn't.
    • One of the nice things about AJAX is that it just absolutely blows people away. The click, they expect a page load or a refresh. But it's just there. It really breaks the user's image of what is about to happen. It allows web applications to transcend the "toy" level, just a little.

      Imagine Slashdot never re-loading a page. We could watch as posts spring into existence in real time. A little spooky, if you ask me. :)

      • Re:I think I buy into this "ajax" thing (Score:4, Interesting)

        by CastrTroy ( 595695 ) on Wednesday November 23, 2005 @02:33PM (#14102678)
        This is what bothers me a little bit. Sometimes when I'm at a web page that uses Ajax, I'm expecting the page to refresh, or do something else when I, say, click on button. Sometimes you don't even notice stuff happening, and you're sitting there waiting for some page to load, that is never going to load. I know how the web works, so I expect things to happen a certain way. When pages use AJAX, they change the way things are done, and start to confuse those that really know what's going on.
      • >> Imagine Slashdot never re-loading a page. We could watch as posts spring into existence in real time

        Like, say, http://www.digg.com/spy [digg.com] ?

    • where you think of the browser hosting your application rather than content

      And this is where you go wrong, and why AJAX sucks, and will continue to suck - web browers are (fundamentally) shitty application platforms, for very important reasons that will not go away. The future of web applications, the future where they don't totally suck and aren't jury rigged one-of inconsistent half-assed things, is in specialized thin clients.

      • web browers are (fundamentally) shitty application platforms, for very important reasons that will not go away.

        Netscape didn't believe that, and Microsoft was scared enough to kill them off by releasing a free web browser on every platform that Netscape supported, so the Windows revenue stream would continue. In fact, the point of ActiveX is arguably to support applications in the browser.

        Google doesn't seem to believe that it's a terrible platform either.
        • Netscape didn't believe that,

          And they were wrong, too, and so was Microsoft. They were worried that Java appletts, of all things, were going to kill the desktop OS. Wake me up when that starts happening - and it had a much better chance than AJAX does.

          Google doesn't seem to believe that it's a terrible platform either.

          Thats why Google Earth is an AJAX application, right? Except it's not. And Googles applications, while good and certainly groundbreaking in terms of web applications are nothing compared

    • ...it's more about the architectural view of the application, where you think of the browser hosting your application rather than content and the server produces data rather than content...

      Wait... this is like the MVC thing that Smalltalk invented 25 years ago, right? Where you divide your application up into the Model (the thing that manages the data), the View (the thing that takes the data from the Model and organises it for the user interface), and the Controller (the thing that the user actually inte

    • I think the value of AJAX is in combining the asynchronous request technique with cross-browser scripting, and of course packaging it neatly as an entity and giving it a name. The technique itself has been around since IE5, when Microsoft introduced the XmlHttpRequest ActiveX object. I've been using it since 1999, but back then it wasn't very well documented and it never got the attention it deserved.

      Microsoft could have done a lot to promote this, for example adding native support for it like Mozilla has d

  • So.. (Score:5, Funny)

    by PhrostyMcByte ( 589271 ) <phrosty@gmail.com> on Wednesday November 23, 2005 @01:55PM (#14102354) Homepage
    I guess we are in for a much cleaner internet?

  • Intersting book site (Score:5, Funny)

    by smittyoneeach ( 243267 ) * on Wednesday November 23, 2005 @01:56PM (#14102367) Homepage Journal
    My only disappointment was that the popup on mouse-over didn't say "Hello, world", which would've been funny on a couple of levels, and opted for something practical like telling you how to BTFM.

  • Feyenoord Ajax (Score:4, Funny)

    by Anonymous Coward on Wednesday November 23, 2005 @01:56PM (#14102370)
    I have used this idea Ajax and I found the alternative Feyenoord to be superior in every department. However there is worse to be found on the market, after trying out PSV Eindhoven I demanded my money back.

  • The book (Score:4, Informative)

    by dantheman82 ( 765429 ) on Wednesday November 23, 2005 @02:01PM (#14102411) Homepage
    I ordered it recently from Bookpool.com [bookpool.com] and although they claim that it's out of stock, I still ordered it and recevied it not too long after. Otherwise, if you'd rather get it a little sooner, try out Amazon [amazon.com].

    Also, a very interesting resource is available through Pragmatic Programmer [pragmaticprogrammer.com], a beta book which means you can get PDF updates as they are written until it is shipped in hard copy in Feb. 2006. Already a book of 160+ pages, they already had a section on creating your own version of Google Maps (and more relating to SAJAX and other PHP implementations). The beta book, while only a little extra, is highly recommended!
  • The central idea behind Ajax is pretty good IMHO- moving as much of the presentation-tier processing as possible to the client system. It's certainly a cleaner design- separation of concerns means you can get away from some of the nastier (and kludgy) template languages like PHP, Cold Fusion, and their ilk. You can also see a future where JSP, Velocity, and ASPX pretty much go away from the application stack- yes, you still need some templating system to produce the XML or javascript that your application i

    • Re:Good read so far (Score:2, Insightful)

      by RetroGeek ( 206522 )
      The central idea behind Ajax is pretty good IMHO- moving as much of the presentation-tier processing as possible to the client system.

      Which to me sounds like a stab at re-inventing Java applets.

      All the problems you describe (name spaces, libraries, etc) are already solved in Java. In addition, you are not at the mercy of browser JavaScript bugs.

      The only downside is the initial startup time for the Java applet, as the local JVM must be loaded, THEN the applet.

      As for the JVM version, you can check for this in
      • Sure, we could use JWS and applets; I've written quite a few. And there's no doubt that java is a better systems language than javascript.

        But for some reason, the world has pretty much rejected both technologies. It's probably a combination of things- you need some level of skill before you can just start messing around with java (maybe an IDE, but at least an understanding of how to invoke a compiler and all that). Of course, it's also easy to blame M$ for their adopt and extinguish policy- adopt a craptas
      • As for the JVM version, you can check for this in your applet before you start the dependant code, and you can ask the user to d/w the JVM.

        What if the new VM breaks another applet which only works with the older VM? I've seen it happen more than once before. In my experince, applets are extremely picky about the JVM version. Applet interoperability is far worse than javascript interoperability. Plus, applets have the small problem of not interacting with the rest of the page. I'll pass on the applets, than

    • Javascript namespaces (Score:5, Informative)

      by brunes69 ( 86786 ) <slashdot@nOSpam.keirstead.org> on Wednesday November 23, 2005 @02:15PM (#14102538)
      "Namespaces in Javascript are dead simple, because of function scoping:
      window.MyNamespace = new Object() {
      function NamespaceMethodA() {
      // alert('hi');
      }

      function NamespaceMethodB() {
      // do b code...
      }
      }

      NamespaceMethodA() // Causes exception

      MyNamespace.NamespaceMethodA() // works.

      Want to "import" a namespace? Include this function in one of your base .js files

      function import( namespace ) {
      for( i in namespace )
      window[i] = namespace[i];
      }

      You can now do import(MyNamespace) and all it's members will be locally scoped.

      The problem in Javascript is not namespaces - it is the fact that there's no way to mark a method/variable as protected/private. So you need to resort to old C-style crap like appending _ to private members if you want to enforce your contracts.

      • The problem in Javascript is not namespaces - it is the fact that there's no way to mark a method/variable as protected/private. So you need to resort to old C-style crap like appending _ to private members if you want to enforce your contracts.

        It turns out that Javascript really is a cool dynamic language with more features that most people think. protected/private are possible. see http://www.crockford.com/javascript/javascript.htm l [crockford.com]

        --jeff++

      • Private members are also perfectly possible using closures.

        The fact that a lot of people don't understand how, doesn't mean the language has no way to do it.

        Javascript is not C(++) or java. Unfortunately (perhaps) it looks similar enough that a lot of people never go beyond the bits that do look like C/Java.

    • Re:Good read so far (Score:2, Interesting)

      by TWooster ( 696270 )
      Well, if you're running web applications, a good bit of IP is in the code, which is client visible. I suspect the best way around all of this is to develop a strongly typed language which compiles down into javascript. Javascript then becomes the intermediate language rather than first-crack. Additionally, the compiler can name variables and functions things that have no relation to the underlying logic of the code, making it much more painful to reverse engineer. (Much like reverse engineering a .NET progr
    • separation of concerns means you can get away from some of the nastier (and kludgy) template languages like PHP, Cold Fusion, and their ilk.

      What?? How do you plan to produce all that pretty xml if not with a server-side language?

      I use AJAX with coldfusion all the time. I have an AJAX Service (is that what we're calling them?) that returns the answer to a FAQ question. The AJAX app shows the list of questions. When the user clicks one, it calls the service. The service has to query the database to get t

      • Re:Good read so far (Score:3, Interesting)

        by jenkin sear ( 28765 ) *
        Right- that's my point, actually.

        Your cold fusion code is now acting an application tier language- it receives a simple query (give me the answer to my FAQ question number 3), and it queries the DB, formats the result as XML, and goes back to sleep.

        However, a classic cold fusion site handles the page layout, loads in whatever resources are appropriate for that locale (english, german, japanese, whatever), queries the database, formats the results as a bunch of table tags, and outputs everything.

        So you've ef

    • Re:Good read so far (Score:2, Interesting)

      by JulesLt ( 909417 )
      Mozilla hace already started implementing some parts of the next version of the ECMAScript spec into JavaScript, and it looks like ActionScript 3.0 has actually gone from being behind JavaScript to being ahead (support of packages and namespaces). The issue, of course, is with what IE and jScript bothers to do (probably nothing if it undermines the XAML/Windows Presentation layer thingy). I still have that same alarm bell ringing, in that you're definitely using a spoon to slice a steak. The browser was ne

  • Free AJAX T-Shirt! (Score:2, Informative)

    by ChaserPnk ( 183094 )
    OK, I know this isn't much of a deal, but it's still good if you buy a lot of books. If you buy AJAX in Action and another Manning book from major bookstores, you'll get a free AJAX T-shirt. A list of bookstores [manning.com] has been posted.

    I don't work for Manning, but I'm so in love with their books. The Java GUI programming book alone is worth a million to me. I refer to it almost everyday. I've looked at similar O'Reilly books and they don't even come close! I'm about to purchase Manning's .NET book pretty soon as w

  • Read the FAQ (Score:3, Funny)

    by nizo ( 81281 ) * on Wednesday November 23, 2005 @02:10PM (#14102485) Homepage Journal
    ...mime performance on a radio show...

    If you are having mime problems perhaps this [faqs.org] will help?

  • From the review: You will learn how to ensure your app is flexible and maintainable, and how good, structured design can help avoid problems like browser incompatibilities. Along the way it helps you unlearn many old coding habits.

    To quote a famous 900-year old green swamp-dweller, "you must unlearn what you have learned."

    This sounds intriguing. Anything that could help mitigate the problems of interfacing and data presentation on the web would be a blessing.

  • Compatibility (Score:5, Insightful)

    by kstumpf ( 218897 ) on Wednesday November 23, 2005 @02:15PM (#14102540)
    AJAX represents a new paradigm in UI design for web applications. I don't think there's much question about AJAX's value. You will see two problems though: 1) browser compatibility, and 2) bad code and interface design.

    You have to think hard when deciding if your client base is ready for it. The same browser issues exist with AJAX that exist for any other "new" client-side technology. By relying on it, you will exclude visitors.

    As for my second point, get ready for a lot of bad AJAX. People have a hard enough time designing interfaces as it is (think of all the bad ones out there), and building dynamic ones that work like people expect them to will be that more complicated.

  • Italics (Score:2)

    by alta ( 1263 )
    Can someone insert an [/i] tag after the bn.com link up there?

  • If you're fortunate enough to see it in action on Yahoos's new email, you will be impressed. You can take a look here http://www.ajaxian.com/archives/2005/09/yahoo_mail _beta_1.html [ajaxian.com].

    gasmonso http://religiousfreaks.com/ [religiousfreaks.com]
  • "Mr. Chappell, Ajax seems to have the momentum of a runaway freight train. Why is it so popular?"
  • Disclaimer: I use Opera

    Has anyone else noticed that the entire part of this page past the end of the article is in italics?

    How the hell can you miss a closing tag so easily?

    Off-Topic I know, but it's the first really broken HTML slipup I've seen on Slashdot.

  • Real-world usage (Score:2, Informative)

    by m2pc ( 546641 )
    I am a developer for a huge PHP/SQL project and we are creating our 2nd generation system using AJAX. As a server/client developer this technology is allowing us to create a much better user experience.

    I agree that AJAX has its downfalls ("back button" breaking, JavaScript usage, etc.) but most of these issues are present in "web sites" not "web applications". With a real Web Application, you have more control over the user in terms of requirements, etc. than a public web page.

    To get around state ch

  • If it doesn't focus on the technologies being used (Score:4, Interesting)

    by Tetravus ( 79831 ) on Wednesday November 23, 2005 @02:40PM (#14102739) Homepage

    it's useless.
    AJAX is a simple concept. Really, it is. Getting three different coding paradigms to work together harmoniously is not so simple. Throw in available AJAX libraries, JSPs and Atlas pages and you've got layers upon layers of coding cruft that need to be understood before a functional, stable, web-app can be built.

    If this book stays at the architecture astronaut [joelonsoftware.com] level without ever delving into the why of the code structure of the example programs, then it may serve as a cookbook but certainly not as an informative manual that can provide a baseline from which coders can build their skills.

    Perhaps the book is better than the reviewer makes it out to be, but he offers no real justification of the 9/10 score awarded, so it's hard to say. Just for giggles, I should note that when Richard Stevens' seminal Advanced Programming in the Unix Environment, 2nd Ed. [slashdot.org] (being possibly the most comprehensive and useful programming book I've ever read) was reviewed it also received a 9. How do these two books compare?

  • A Shorter, More Direct Alternative (Score:5, Interesting)

    by kimanaw ( 795600 ) on Wednesday November 23, 2005 @02:48PM (#14102798)
    I read the sample chapters of the reviewed book and was underwhelmed. Chapter 4 spent way too much time trying to sound "impressive", with lots of UML diagrams and Design Patterns references. Plus, 615 pages for AJAX ? Unless 400 of those pages are weblinks to online references, I'm afraid its just killing a lot of trees.

    I just picked up Foundations of Ajax [apress.com], and its a good, focused 273 pages, of which nearly half is resources and tools for implementing. I haven't had a chance to download and try out the examples, but the reference links all look like great resources. While I wish they'd skipped the usual Chapter 1 "Here's the history of the web" that any reader of the subject matter already knows, all in all, its a great way to cut thru the BS and get rolling with the AJAX concepts.

    In summary:

    • If you want to learn UML, buy a UML book
    • If you want to learn Design Patterns, buy the GangofFour book.
    • If you already know how to put together a webpage, write some Javascript, and maybe a little CSS, and just want to understand how it all to hangs together in AJAX, then Foundations of Ajax [apress.com] is probably a better choice than "Ajax in Action".

  • AJAX inthe Real World (Score:5, Informative)

    by Heembo ( 916647 ) on Wednesday November 23, 2005 @02:49PM (#14102804) Journal
    In may ways, that book is out-of-date. Here is what is working for me *today*. There are many possibiliites, but my focus is Rapid Application Development - and these tools help me rock and roll, fast.

    Last week I was tasked to replace several standard (but sometimes complex) HTML business forms with an AJAX solution. Here are the best tools I found after lots of research time. This is bleeding edge; but functional in Opera, Safari, IE XP, FF XP, FF OSX, no small feat.

    1) AJFORM - submit a form via Javascript using HTTP post or get without refreshing the page. (next release in a few days, keep an eye on it, its brilliant and easy to use) http://redredmusic.com/brendon/ajform/ [redredmusic.com] 2) YOUR SERVER CODE - I use Java, but anything including ASP, CF, PHP - its all works. (Standard HTTP). Just needs to spit out XML, easy feat. 3) GOOGLES XPATH LIB - those of you who use Sarissa, drop it - she does not support Safari. Google's XPATH lib does, well, on all browsers you need. http://goog-ajaxslt.sourceforge.net/ [sourceforge.net] - this is the best and easiest way to "search into" XML data. You can use native DOM calls, but it takes about 10x as much time to get it right.

    With AJFORM and Googles XPATH lib on the client, I was able to quickly and effectively start making business forms in AJAX that were "scarry fast" and WOW'ed all the folks who are paying the bills! YAY!

    Whats your architecture for AJAX?

  • Reminder about browser abilities. (Score:3, Insightful)

    by dghcasp ( 459766 ) on Wednesday November 23, 2005 @03:11PM (#14102979)
    Don't get me wrong, AJAX is really cool. But if you develop your site using it, you'll be making your site inaccessable to anyone using MacOS9 or older browsers on Windows or *nix.

    From the records of the site I maintain, about 6% of all accesses are from browsers that can't handle AJAX.

    Incidently, from my over-optimistic decision to do all the layout for the site in CSS, those 6% also took 75% of the time and are responsible for 1/2 of the .css file being "hacks." Never again. Tables rule.

    • Re:Reminder about browser abilities. (Score:4, Informative)

      by Bogtha ( 906264 ) on Wednesday November 23, 2005 @03:32PM (#14103148)

      Don't get me wrong, AJAX is really cool. But if you develop your site using it, you'll be making your site inaccessable to anyone using MacOS9 or older browsers on Windows or *nix.

      Nonsense.

      Best practice with Javascript is to develop a site that doesn't use Javascript, and then add the Javascript in such a way as to be backwards compatible. AJAX, being a form of Javascript, is exactly like this.

      Some developers cut corners and write code that isn't backwards compatible. That's their decision, but it's got no bearing on whether or not AJAX itself is backwards compatible. AJAX is definitely backwards compatible. Visit Google Suggest in Lynx. It works fine. If you visit a site that uses AJAX and is not backwards compatible, then it is the fault of the site developers for misusing AJAX. It's not an intrinsic limitation of AJAX.

      All you are doing by saying that AJAX is not backwards compatible is scaring some people off AJAX, and making others give up on backwards compatibility. The former will result in less usable websites, and the latter will result in less compatible websites. Neither of these are good things. Please refrain from saying that AJAX is not backwards compatible. It is. You don't have to choose between AJAX and backwards compatibility, so don't mislead people into thinking that they do.

  • The hype is supposed to be around a small programming technique but it feels like the only reason anyone cares about Ajax is because Google's outstanding advertising uses it in some capacity. But isn't it really advertizing that's big?

    A few years ago multithreading was the next big thing, but no-one starts a company today to specialise in multithreading. Now multithreading is called Asynchronous JavaScript+XML and we're supposed to think it's more substantial than multithreading because no-one can be told

  • Ajax Killed Himself (Score:5, Insightful)

    by laoc00n ( 933461 ) on Wednesday November 23, 2005 @03:17PM (#14103029)
    Take a reliable, stateful transport protocol (TCP) and lobotomize it so that connection state gets thrown away. This is http. Take a platform-independent object technology (Java) and lobotomize it so that dumb xml data structures get passed to "stateless" objects (in other words, procedures), and all processing must happen at one end of the connection. This is Web applications. Take gui technology and lobotomize it so that screens must refresh one page at a time. This is a browser. So: having gone from a world of functional, stateful, distributed applications engineered to a true software model, we are now back (despite all the self-congratulatory rhetoric about "objects") to procedural programming and dumb terminals (meaning Web browsers). In other words, 1970s technology with pictures. Any half-wit can see that this situation is broken. How do we fix it? The Ajax answer is to keep all of the lobotomized bits and build increasingly Byzantine layers on top of the existing mess in order to re-introduce the capabilities that were hacked off in the first place. Brilliant.
    • We'd all love to see the plans.
    • Take a reliable, stateful transport protocol (TCP) and lobotomize it so that connection state gets thrown away. This is http. Take a platform-independent object technology (Java) and lobotomize it so that dumb xml data structures get passed to "stateless" objects (in other words, procedures), and all processing must happen at one end of the connection. This is Web applications. Take gui technology and lobotomize it so that screens must refresh one page at a time. This is a browser. So: having gone from a wo
      • Interesting post. Only, I disagree with what you list as strengths.

        No Installation (false)
        Easy content creation (content is always easy and irrelevant to platform)
        Global hyperlinking system (true, hence URL...)
        Speedy interaction (false)
        True rapid development (so is VB, also bad)
        Standard navigation/bookmarking scheme (reiteration of previous point cause yur out of good things to say)

        Working with Java or RealBasic or any other half-assed language with comparable use/capability makes Web Developers (like me) c

      • * No Installation
        * Easy content creation
        * Global hyperlinking system
        * Speedy interaction
        * True rapid development
        * Standard navigation/bookmarking scheme

        I really take exception with "true rapid development". Web apps are ALWAYS more difficult than the equivalent in client apps.

        Also, there is way too much emphasis these days on web-apps.
    • The Ajax answer is to keep all of the lobotomized bits and build increasingly Byzantine layers on top of the existing mess in order to re-introduce the capabilities that were hacked off in the first place. Brilliant.

      I suppose the reason is, who do you trust?

      e.g. I look at xmlHTTPobject (or whatever it's called) and wonder, "how can they allow that, after all the fuss about ensuring that cookies aren't cross-domain"

      As I see it, AJAX is competing against things like Java, .NET, and ActiveX. Basically, the al
    • Amen. Why people just won't open a freakin' port instead of trying to drive 1,000 angels through port 80 (or 443) I will never understand. Push, even polling, is a beautiful thing if the client can just send you back a little bit of meaningful context in a lightweight way.
  • did it work?
  • "The majority of the book is for programmers engaged in the development of web applications..."

    Well, yeah, because if your application doesn't involve a web browser then AJAX will be about as useful as a screendoor on a submarine.
  • I under stand this is flamebait but ...

    Javascripts' endless browser issues have left me with too many scars. I can avoid this trauma, eliminate XML bloat (or not, as I choose) and write fully functional web aps in ... Flash (!?!). Sticking to Flash 5 I reach most of the nets browsers no problem. For standalone and custom I force the client to install the latest plugin and I can use all my (admittedly hacky but that's my problem) functions. I can even make a really annoying intro with loud bad music and n
  • Ajax is a nice approach at web development; but developers are losing sight of the heaviness that comes with the extra features. While I find the features of drag-n-drop, dynamic tree menus, sliding menus, and interactive one-time-load pages to be nice, it does not justify the additional load time required to include these features.

    How longs does it take to load the web page. That should still be amongst the foremost concern to the webmaster. When you use AJAX (javascript/xml/css) your browser must still do

  • How many replied without even reading the book? I started it a month ago with the pre-release PDF made available before the book was published. (This book was the number 1 seller on Amazon just last week.)

    My complaint is that the book is LONG on theory and SHORT on small, reproduceable code snippets. It's not until chapter 9 that you get into meaningful code and most of that is dependent on technologies you may not care about like SquealServer and VisualBasic. The last thing I want to have to do is instal

  • AJAX... Woo!! After 20 years of toil and effort we have managed to recreate the Client Server application model that held us strong all through the days before the PC. Cool. I love the hype around the reinvention of 30 year old tech, on a new platform
  • it's all i'm hearing about lately... here in Australia (i don't know about ca us or uk) ajax is a cleaning product with some sort of grit in it to make cleaning easier.... i'm having trouble disassociating the word with this powerful cleaning agent....
  • It's funny this review should come up, as I thumbed through this book in BN last night. It took me a minute to find it, because it's on sale for 20% off, and was on a special display.
    However, after looking through it, and comparing it to the only other available title, I went with the other book. That book is Foundations of Ajax from APress by Ryan Asleson and Nathaniel T. Schutta. That book is only about half the size for the same money, but seemed to have a bit more to it. Rather than covering so much the
  • You want to learn the secret of AJAX? Here's everything you'll need to know without buying some technology-of-the-month (year?) book:

    THE XMLHTTPRequest FUNCTION IN JAVASCRIPT DOWNLOADS SHIT

    The rest should be obvious if you are a competent programmer.

  • A"HAX" (Score:3, Funny)

    by XBL ( 305578 ) on Wednesday November 23, 2005 @06:00PM (#14104213)
    AJaX (Asychronous JavaScript for XML) is a Microsoft-originated hack to basically hang open a HTTP connection that receives events containing XML. It is a hack MS invented for web-based Outlook. Unfortunately it is now the hot new thing.

    It takes very smart people at MS, Yahoo, Google, etc to make complex AJaX applications actually work well. It takes only a kiddie to get simple AJaX to work. The middle ground where there are mediocre programmers/web developers building medium-sized AJaX applications is where this will all fail in the end. The only saving grace would be some very smart and solid libraries built into web-apps, but I still have my doubts over the long term.

    Mozilla and Apple worked together to create a element for doing bitmap drawing into web pages. I would suggest that they work together again to create something far beyond what AJaX can do. I am talking about something on the scale of melding Jabber IM, HTTP server (Apache of course), and the web browser together into a smart, extendable, standardized (Jabber is IETF), and revolutionary framework. Apple even supports Jabber already in their OS X Server and clients so they believe in half of the technology that I am proposing already.

    For example, imagine if you logged into Slashdot and the account behind it all was Jabber. The resource would be the web session. You can go across pages and it doesn't matter on what "page" an open socket is created because it's existing at a lower level. Events are sent back to the browser and the browser determines from the XML on what to do with the data. It could update a section of the page to post a new story, a new comment could be added dynamically, a sidebar could be updated, etc. Your account could also integrate with Jabber clients so Slashdot users can IM each other via the same account, just a different resource. That is only a small, simple example of what would be possible.

    Yet, 90% of browsers are still IE. However, don't killer apps fix problems such as this? I believe the web browser + Jabber could be a killer app.

    P.S. It's time for HTML to be upgraded or replaced to make rich web interfaces easier and accessible. How about XUL? About about WhatWG? These things would make our life much easier as developers and users. JavaScript too, needs a kick in the butt. It's time to make some awesome web sites that say "This website requires something other than IE. Here are your options..." Make the tide turn.

    P.P.S. To accomplish the above goals, we may need to think beyond what we know as a website with web pages. Maybe something better thought of as a "web experience".

    Eric
  • I think AJAX has been poorly named. It implies asynchronous, but synchronous is also possible to do. So shouldn't it have been called ASJAX? Or pronounced AssJax?

    I've started adding this stuff into parts of my web app. Why? Because it was a good way to update part of a dropdown menu. Imagine going to a site where you have 4 or 5 dropdown menues. Each menu is dependant on the selection of the previous one. Well that's what I have done, without the full page refresh.

    Which brings us to the real benifit

Slashdot Top Deals

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (10) Sorry, but that's too useful.

Close