Slashdot Mirror
Ajax in Action
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.
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.
I'm not buying a book written by Jon Stewart.
God spoke to me.
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!
8 .html
http://www.cleansweepsupply.com/pages/skugroup106
Paul Graham's got an opinion on Ajax in his Web 2.0 essay.
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.
This could just be more hype...
I guess we are in for a much cleaner internet?
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.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
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.
Forgot to close the ITALICS tag. I wonder if I can do it for them...
"Speaking the Truth in times of universal deceit is a revolutionary act." -- George Orwell
I'm afraid this ajax will suffer the same fate as the original and be speared in the nipple, by the Next Big Thing (TM)
When the seagulls follow the trawler, it's because they think sardines will be thrown in to the sea
I'd like to have the following, all of which have been cumbersome and refreshy to implement in a web browser so far:
I ordered it recently from 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.
Also, a very interesting resource is available through Pragmatic Programmer, 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!
This sig donated to Pater. Long live
I mostly noticed how my PC (2.8ghz and doing nothing else) paused for a moment as the Ajax component started to do something. Excellent!
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 is consuming, but it dramatically decreases in importance. Further, your application tier code can devote itself to modeling your business logic, and not get distracted by trying to simultaneously serve the right stylesheet to Mac IE5 users while calculating shipping to uzbekistan...
The alarm bell ringing in my brain is that all of this is structured around a fairly blunt tool in javascript. It does a great job at what it is designed to do- but it seems to require coercion to handle some more sophisticated needs. When I start building a large, complex application, I really prefer to have namespaces to compartmentalize things. It seems like you need to use tricky external libraries to gain the features needed for external support- with the classic issues around leaky abstractions that this causes.
The book has been a good read so far (I'm halfway through)- but already, it seems like they are bending over backwards to get around the lightweight nature of the language. I'm not arguing for strong typing- but encapsulation would probably help people write better bug-free code. Anyone out there know if there's any reasonable prospect for these structural issues in javascript being addressed at the language level instead of the library level?
What a strange bird is the pelican, his beak can hold more than his belly can.
the hype may be underselling the prospects for this new buzzword
I'm pretty sure the way hype works is someone says that the current level of excitement about a product is underselling it- this is no different. Particularly, saying that something isn't hype and exaggerating it even further are not good ways to stop hype. It is by definition overselling something. If it isn't hype, just say it isn't hype.
And this is before I even add in my opinion that AJAX is indeed hyped way beyond its usefulness already.
XMLHttpRequest isn't very intuitive.
:(
The other better technologies which have been in development will now have an impossible time getting ground to stand on. I fear we will never get out of this now
"The fundamental ingredients in Ajax are in-browser JavaScript, Cascading Style Sheets, the browser's internal DOM model and asynchronous HTTP requests." DOM Model = Document Object Model Model This is just like NIC Card and PIN Number.
Nothing But Coupons - Your no-frills site for online coupons and discou
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 has been posted.
.NET book pretty soon as well.
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
Happy reading.
"A diplomat is a man who always remembers a woman's birthday but never remembers her age." -Robert Frost
If that lame mime reference is any indication of how this book is written, I'll take a pass on it. ;-)
If you are having mime problems perhaps this will help?
I Am My Own Worst Enemy
testing testing 123
AJAX is great, but it only really comes into its own when married with another brand new technology:
HAHA - ("HTML And HTTP Applications")
Keep your eyes peeled - AJAX + HAHA is going to be huge!
Surely you mean 8/10?
Quidquid latine dictum sit, altum sonatur.
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.
GetOuttaMySpace - The Anti-Social Network
Want to "import" a namespace? Include this function in one of your base .js files
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.
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.
Um, dummy editors - the entire page is in italics because you forgot to close your markup...
Can someone insert an [/i] tag after the bn.com link up there?
Do not meddle in the affairs of sysadmins, for they are subtle, and quick to anger.
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.
gasmonso http://religiousfreaks.com/"Mr. Chappell, Ajax seems to have the momentum of a runaway freight train. Why is it so popular?"
With the Holosonics Audio Spotlight, you can now make people think God is talking to them! Range from 20 to 200 meters. And the speaker is just a flat black disk about a foot in diameter.
It's really clever. It works by projecting audio as two ultrasonic signals, which produces a very narrow beam. You can't hear the ultrasonic components, but the difference between them becomes audible some distance from the speaker, because air isn't entirely a linear medium. Some museums now use these things, so that the recorded message for a display is only audible in a small area. We're going to be seeing more of these very soon; the price is about to drop.
So if you hear voices in your head, start looking around for 1' diameter disks pointed in your direction. Move around a bit; the beams are very narrow.
Someone wake me up when there's a cross-platform graceful-degrading _standard_ for javascripted web apps.
In the meantime I've got another buzzword for you: HTML5.
Ajax is not new. It is also not limited to JavaScript or XML. As long as scripting languages have been able to talk to embeddable controls (small "c"), one has had the ability to make calls to embedded objects that can make asynchronous transactions and return the results to web pages. My colleagues and I have been doing "AJAX" since 2001.
Chris
"You can drive out Nature with a pitchfork, but It always comes roaring back again." - Tom Waits
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.
C17H21NO4
If it has Java in the title anywhere... I'll pass. It probably has a PDF plugin as well.
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 change issues, we designed the system to load initial state values on page-load, then update page elements dynamically with AJAX. This cuts down on travel time to/from the server, and if the user hits the "Refresh" button, the state isn't broken.
...it's on an article about web development. Go figure!
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 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. (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?
I just picked up Foundations of Ajax, 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:
007: "Who are you?"
Pussy: "My name is Pussy Galore."
007: "I must be dreaming..."
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/ 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/ - 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?
Horns are really just a broken halo.
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:
Tuesday, November 22, 2005 Posted: 2159 GMT (0559 HKT)
AMSTERDAM, Netherlands (Reuters) -- Ajax reached the Champions League knockout phase as two second-half goals by substitute Nigel de Jong gave them a 2-1 win over Sparta Prague in Group B on Tuesday.
De Jong struck after 68 minutes with a powerful close-range header and grabbed his second in the 89th when he struck a low 16-meter drive past keeper Jaromir Blazek.
Sparta captain Martin Petras got a late consolation for the visitors who battled until the end but lacked the firepower up front to trouble the Dutch side.
With one match left Ajax have 10 points from five games and will finish second behind Arsenal, who have 15 points after beating FC Thun 1-0 with a late Robert Pires penalty.
http://edition.cnn.com/2005/SPORT/football/11/22/c hampions.groupb/
So aren't the main attractions to Ajax that it has Lotus Notes type of functionality, but without that pricetag?
Maybe he deserves some credit for giving it a name. Maybe. All I know is that every time someone mentions Ajax as the "next big thing" (and maybe even puts up a link to that horrible article again) it sets my teeth on edge.
Ah, arrogance and stupidity, all in the same package. How efficient of you. -- Londo Mollari
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.
Sitting right here on my desk right now. I highly recommend it.
"hey, could you pass me a paper towel? er.. I mean... DEPLOY ABSORBTION PANEL!"
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 what it is without experiencing it for themselves, taking a red pill, and learning everything there is to know about CSS, JavaScript, XML.
Based on the appliications, it's multithreading and it's just as hard to see entire companies revolving around it today as it was in 1997.
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.
did it work?
Top 10 Reasons To Procrastinate
10.
(and I am almost afraid to ask this) ...what is...what is Ajax?
We seldom regret saying too little but often regret saying too much.
Can You Imagine a Beowulf Cluster of These? Err... no wait...
From the webpage:
Welcome to
Ajax in Action
This is a pleasant Ajax-style diversion from the main web page for our book. We hope that you enjoy it.
[...]
For those who didn't notice, this was all written in a horribly obtrusive pop-up, that greedily filled up all my precious screen-estate, just after moving the mouse cursor over a small image. How on earth can we trust these people with reviewing AJAX for us? I know I can't.
On the serious side, AJAX seems to have the potential to bring lightweight[1] applications straight to your browser, with all the advantages and disadvantages that follows.
[1] (with the option of having heavyweight applications behind the lightweight curtain, of course)
It's difficult to make predictions, especially about the future, but I'll try anyways:
We have dynamic times ahead when it comes to web-applications, and I'm sure we haven't seen the last of AJAX.
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.
"You're using cold fusion as middleware- I'd suggest that this is a fine strategy for a one or two developer site, but that you may wish to look to a more maintainable / suitable language for middle tier development- but that's just my $.02."
Like Scheme for example.
let's try a /i tag
Thanks for the links. I was just working on a small app that snowballed into a large app and allowing object associations via the UI (form submit) without refreshing was the next thing I hoped to add.
Now, I thought I'd read somewhere that this reqest only occurs under http, not https. So that even if the page itself is https, the info travels to and from the client via http, thus unsecured. Is that the case or is it possible to use AJAX securely?
Just because something is innovative, it doesn't necessarily follow that it is in fact progressive. It's as sad as getting a black-and-white plasma TV and thinking you've got game.
/.ers' and leave the RIA work to us misdirected Flex developers!
AJAX is just a collection of workarounds in a fancy box. Sure, it might be good for tiny apps where you want to spare your users a few page refreshes, but unless your company name ends in *oogle or *ahoo, you'll be hard pressed finding the resources to design/develop/cross-browser-debug/maintain anything complex. It has no dedicated IDE, no modern component set, no state management (iframes == workaround), no rich media tools, no cross-browser compatibility...and that's just off the top of my head.
But hey, I love that AJAX exists, and I think everybody should use AJAX!
After all, the more anachronistic web developers who use AJAX, the fewer who will use Flex, meaning there will be that many fewer *truely* bleeding edge web applications to compete with.
All I can say is 'fight the power, you anti-proprietary, anti-flash
--------
Cynicism is just arrogance wrapped in distain.
I under stand this is flamebait but ...
... 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 no 'skip' button. (let's see AJAX do THAT)
...
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
As this is slashdot, we may soon approach Goldwin's Law. Gentlemen, start your flamethrowers
Physics is like sex: sure, it may give some practical results, but that's not why we do it.
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 download the content. Even content that is not currently in use is downloaded and only used upon demand. How then does this minimise the total size of the page? It doesn't. A user will wait about 3 seconds for a page to load at max. Once you begin getting past that point for the page-load time, you are risking losing that visitors interest. AJAX is a good approach for dedicated traffic use. Examples being: allowing a user to dynamically design their profile page with drag-n-drop features, permitting a logged in visitor to manage their blog entries through drag-n-drop and dynamic category creation with real-time folder image representation, and other such user-specific features. These features are handy and a visitor is seeking the interaction that allows for a little extra page-load time. But to require all users to wait for your AJAX aproach to load an interactive calendar that half your traffic will not use is bloat.
Take it from top websites which understand this. Yahoo! is a prime example. Visit their page and browse around. Do you see DHTML/AJAX heavy feature-bloating? Not at all, instead you see simple CSS, minimum graphics and fast page loads. The only location you do see those heavy features is in user-specific areas.
This aproach though has been around for several years that I am aware.
My Thoughts, Kyndig
There actually is a technology called HAHA. I'd link to it, but unfortunately it's a rather difficult acronym to search for. Basically the idea is to use XmlHttpRequest to get HTML and dump it straight on the page (rather than processing XML or JSON with Javascript to get the final HTML). I think the idea (of calling it HAHA) originated with one of the microformats guys.
Personally I think the idea (of getting HTML from the server) is too bloody obvious to need an acronym, but what do I know?
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 install half a dozen things in order to get some sample code going. It seems the book is not so much about AJAX as it about "The software development process." It drones on about design patterns and MVC. The book is also very verbose saying in 100 words what could be said in 10. Good software engineering discipline is needed of course (especially with Javascript), but this book beats it to death where it should just relate it to AJAX and move on.
All the excitement about AJAX is warranted considering the stupidity of webapp development heretofore. It's really dumb to have to regenerate an entire web page when you just want to return some additional data or reflect a state change. How many production, revenue generating web pages have I seen where the mere click of an HTML select input causes the entire page to be redisplayed? Zillions. This stupidity is overcome by asynchronous part of AJAX. Do you know asynchronous JAX shit? That's the salient improvement over mere DHTML. There's a ton of websites desperately needing richer UI's and people who know asynchronous JAX shit will be in demand.
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
Funny, that.
Standen Eredividie.
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....
Save yourself some money by buying the book here: Ajax in Action. And if you use the "secret" A9.com discount, you can save an extra 1.57%!
We'd all love to see the plans.
Great to see Ajax in Action out there. It is a nice size volume, and talks about important ideas in Ajax.
There are other books out too, such as Foundations of Ajax, and the new Pragmatic Ajax (http://pragprog.com/titles/ajax) done by the Ajaxian guys (http://ajaxian.com/)
http://jwchat.org/ (what the ... is meebo?)
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 theory about why you'd want Ajax and how an Ajax system might work, Foundations of Ajax actually gets to the point and shows some real and made up examples. Although no CD of source was included, the examples are available from the APress website. Most were so basic, they could be easily implemented in any existing project as a test, or for permanent use.
I haven't finished it, so I can't give a full review, but I recommend giving it a closer look before deciding to purchase either!
-Patrick
"They never stop thinking about new ways to harm our country and our people, and neither do we."
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.
Did you ever notice that *nix doesn't even cover Linux?
Prepare yourselves because within 12 months you will see that for every well-executed, appropriately-applied, ground-breaking AJAX design, there will be a hundred haphazard, broken, ill-conceived sites using AJAX on principle, at the directive of clueless PHBs and excited marketing departments.
Ultimately it does seem quite inevitable that AJAX-style development will forever change the web development landscape, for the better: there are real advantages with enough technical merit to overcome the status of being a fad. Still, I'd like to see some serious evolution of the toolsets available - not merely third party APIs, but full-fledged development environments to get away from the tired old dog that is JavaScript.
I must echo many comments I've seen here and elsewhere by interested programmers who, but for the sake of having to code in JavaScript, would otherwise readily embrace this new paradigm (ok let's just call it a trend for now). JavaScript is about the worst language imaginable for serious development. Sure it's great for image rollovers, form validation, and intermittently grabbing an XML file from the server. But what AJAX is asking us to do is to turn these loose collections of one-off functions into a true, genuine application. Pardon me for being a little concerned about that prospect.
Now if browser makers would just supply a Python interpreter to run client-side code, not only would I buy the book and the T-shirt, I'd swallow the pill, drink the cool-ade, and get "AJAX" tatooed on my forehead.
czep
Dictionaries are for loosers.
"Cool. I love the hype around the reinvention of 30 year old tech, on a new platform"
Have you heard about Linux yet?
Down with JavaScript!
Dictionaries are for loosers.
This is off topic, but I figured that there would be few AJAX-experienced people reading this. I have a question regarding AJAX that I haven't been able to find a definitive answer for. Is it possible to refresh page elements (in an iframe?) from a server-side script or even database trigger? As an example, if the database receives a new uploaded document which matches an end-users pre-defined search criteria, can this document (or at least a notification) be 'pushed' to that user without any action on their part (refresh etc)?
Show me a push technology, and I'll show you a pull technology in disguise. There is no 'real' push in the web. It's either an open connection, or a pull.
"This time the buzzword is Ajax and it's moving so fast that you can almost hear the sonic boom."
uhh, I don't hear any sonic booms... it sounds more like a bunch of IT Marketing kacks' heads exploding from trying to grasp what they are now trying to sell.
AJAX is a buzzword. You can update content in your browser without refreshing your page (woo hoo). You can ruin your site by using these techniques in areas that it should not be used (yay). You can decrease your search engine exposure by polluting your front-end web pages with these techniques (that's right baby!).
Great Stuff!
Anyone who buys a book about AJAX is a brainless tool!
the only permanence in existence, is the impermanence of existence.
I've seen a demonstration of AJAX at a conference, and it has some interesting features, but my concerns about it are:
1. I hate JavaScript.
2. I'm not sure how accessible applications built with it are. Meaning that if someone is blind and using a screen reader, or even someone with a non-standard browser, is trying to use the application, will they be able to?
Anyone with experience with AJAX and accessibility please comment.
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'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 of AJAX. The fact that you do not have to refresh the whole page to update part of the page. I have actually been told by several web surfers, that when a FULL page refresh occurs they get confused as to where they were. Mostly because they have a slow connection and notice it alot. Using AJAX one can refresh this part of a page without a full page reload.
The other advantage is bandwidth savings. Instead of having to send ALL the page data, you only need to send part of the page data. The part that needs to change. This saves web server load as well as browser and network traffic.
I like the technology, lets hope it does not get sucked into a patent dispute and screw up the acceptance in apps.
Only 'flamers' flame!
Does slashdot hate my posts?
i?
Fight Frist Psoting!
Browse Slashdot with 'Newest First'!
So now you're writing browser-dependent code, an utter waste of time. The next browser bug in IE will crack open any security you have[Microsoft will make sure of that]. Browser upgrades kill your site.
Best lose the JavaScript. Then you can write once and it runs forever.
This is even more true now that Microsoft has decided AJAX is theirs.
If it is so "simple", why did Microsoft call it "Rocket Science" :-)
c le.jhtml?articleId=174400424
http://www.governmententerprise.com/news/showArti
"... the most important part of our strategy with Atlas is to the take the rocket science out of Ajax and make it easier for our customers to create more compelling experiences on the Web."
If it isn't Rocket Science, does that mean Microsoft thinks its developers are simpletons?
I created a little Java applet that is called from JavaScript....this little applet does nothing than act as a Socket Proxy (both UDP and TCP) for "Push" type of interaction....it is *very* small and add very little to the overall bandwidth...also, once downloaded is cached and used by all my AJAXey applications without a problem....works rather nicely....has allowed me to access data through a legacy, developed in-house message passing system based on UDP that obtains data from Mainframes via COBOL and crud like that.....
Over-the-top Response Guy! Giving "Over-the-Top Responses" since 1970.
I'm a former dickhead who moved up to full-fledged asswipe. Anyway, good to see you used the word 'paradigm'. Shades of 1999.
I work for the large online division of a famous global broadcaster...
The people who are refusing to give any budget to rework our core templates to make them web standards compliant... are the same people who suddenly keep using the phrases "Web 2.0" and "AJAX" in every meeting.
Any developer worth their salt has known about this kind of hack* for a long time. We're pleased we can finally deliver it AND be able to point at our browser support matrix and show most people will get the benefit. But only IF it is actually a beneficial piece of tech to employ on a specific project.
The only people getting excited are trouser-wearing geeks** - and those foolish enough to listen.
* It is a hack. The whole Web 2.0 concept is a hack. XHTML is not designed to deliver GUIs. It's designed to deliver documents. Sure you can do some cool stuff. But it's still a shonky big hack. People seem to think because we can ditch for layout that everything else is fine and dandy.
** They say they're geeks, but they also always wear the latest branded clothing and when questioned firmly appear to know very little about technology. But they're Geeks(tm) man - at least, that's what the Execs think. Five years ago the fuckers would have been in Marketing.
Here's how I create classed in JavaScript....(using the power of closures)
/* Private Properties */
/* Inherit */
/* Public Methods */
/* Public Properties */
// Displays Alert with "Hello World"
// Displays Same thing
var create_class = function() {
/* Private Methods */
var methods = {
method1 : function( self, pp, p ) {
/* Self = This */
self.prop1 = p;
/* pp is the Private Properties */
pp.pp1 = p;
},
method2 : function( self, pp, p ) {
alert( pp.prop1 );
}
}
var constructor = function ( parms ) {
var pp = {
pp1 : null,
pp2 : null,
pp3 : null
}
this.uber = my.parent.constructor;
this.uber( parms );
delete this.uber;
this.method1 = function( p ) { return methods.method1( this, pp, p ); };
this.method2 = function( p ) { return methods.method2( this, pp, p ); };
this.prop1 = null;
this.prop2 = null;
}
return constructor;
}
var myClassConstructor = create_class();
delete create_class;
var instanceOfMyClass = new myClassConstructor( { p1 : val1, p2 : val2, p3 : val3 } );
instanceOfMyClass.method1( "Hello World" );
alert( instanceOfMyClass.prop1 );
instanceOfMyClass.method2();
Over-the-top Response Guy! Giving "Over-the-Top Responses" since 1970.
The situation is broken? Not at all. It's just that people can't apply their shiny dream paradigm (whether the Windows/Mac GUI, or objects, or whatever) to the distributed / networked world. Most of your points are, at best, half-truths.
The fundamental reasons for all of these quirks come down to two observations: concurrency is hard to get right & distribution is hard to get right.
1. HTTP doesn't throw away connection state and hasn't for 6+ years since HTTP 1.1 KeepAlives & pipelining
2. "objects" still matter. But they were designed for single user systems. Multi user systems imply concurrency. That changes things. Object oriented people wanted their hammer to make everything look like a nail -- well sorry, it doesn't work that way. Yes, OO is still useful, just in certain contexts (like, a request or session scope).
3. Stateful v. stateless objects are somewhat of a red herring. it's really always been about shared vs. local data. shared data can be a concurrency bottleneck. If you want shared data objects, that's what an RDBMS or ODBMS is for.
4. GUI's were not designed with the network in mind. The first client/server GUIs that did deal with a network tended to suck, as they didn't make it clear to the user what a request and a response was. So you'd get bizarre brain freezes, lags, cryptic errors, etc. The browser sucks less because it makes the network apparent to the user.
Transparency can be a useful goal, but it doesn't work with distributed systems. Distribution is fundamentally different from local computing, and should be treated as such. Abstractions yes, transparency no.
-Stu
Ports have very little information about the intent of a request. It's just a number, and there only are so many available for TCP/IP. A URI, on the other hand, is much more descriptive. By relying on higher level protocols such as HTTP, you have a lot of metadata about the request and the ultimate target resource. This can then lead to finer grained audit and access control.
-Stu
Seems to me, this was the concept of a Java applet as well: write a mini-application that can be launched from a web browser, giving all the advantages of distributed client server type processing without the headache of application installation on every machine. Of course a well written java application would make use of threading to fetch data in the background as well.
What are the pros and cons of each approach?
Am I wrong - is AJAX something really new? Or is it just substituting Javascript for Java, and manipulating the DOM rather than constructing your interface with Swing components? (Both AJAX & Java can use XML as a data interchange format).
Word! If you use firefox and want this fixed, vote for bug 312418 or add a comment to it.
1 8
https://bugzilla.mozilla.org/show_bug.cgi?id=3124
Hyperlinks are disabled from slashdot so you'll have to cut and paste this link to a new browser window.
Don't get me wrong, AJAX has greatly improved web applications.
But how sad is it that we've finally approached some level of responsiveness and interactivity in web applications through the desperate accumulation of hacks, when there are many great technologies and languages out there that could accomplish the same thing in a reasonably well designed environment. At this advanced stage of modern languages and development practices, we have resorted to hacking an ill-conceived scripting language on top of a bloated layout language to become the standard of client/server interaction.
Here we have the developers and users just drooling over being able to click on a button and get an instant response. And it takes this giant hack to get there. Does this cause anyone else to let out a big sigh?
There is obviously nothing new about what AJAX does, only the widespread platform on which it can easily run and the free as in speech nature of the technology. Other than that, it sucks donkey balls. There is nothing inherently good about the AJAX way of doing things.
In the debate over whether Ajax is hype (it is) or the next best thing since sliced bread (it is that too) many are forgetting this simple fact: most people are interested in computing (i.e. the power of applications that computers provide us) not computers (i.e. being a sysadmin in order to get computing facilities). Yes it is true that AJAX in particular and the Web in general are implementing technological ideas that are decades old and in a worse way than some of the older alternatives. But all the older alternatives require people to "have" computers which means that on some level they need to be sysadmins. All the crap that is happening now in terms of internet security problems etc. starts and (mostly) ends with the fact that, through no fault of their own, non-technical people are forced into the role of sysadmin against their will.
The promise of the Internet in general and the Web specifically, is that it gives people access to computing without having to be a sysadmin, and most importantly in a distributed environment - pervasive access to data and applications wherever you happen to be. The computer will fade away into the background - no one will know there is a computer there at all. They would just have computng service devices. The hype is only that we are promised it would be here yesterday, when it fact it is still many tomorrows away. But AJAX is one more step down that road and it works now. Sure in ten years we will think it is way primitive. But think of the World Wide Web in 1995 and look where it is now. Was it hyped in the dot com era? You bet. Is it revolutionary in the context of computing? Yes, because the way people work and play with computers has fundamentally changed in the past ten years because of the Internet and the Web.
For example, take this object, which has some services I want public, and one I want private:
Now, pray tell, how do I make that private method truely "private" using a closure, while maintaining it's scope within the object correctly? You can't. If you define it inside a closure, it is private to that closure only, and it's scope will no longer include the object, so you can't access the object's members.
Closures do not create private members, they just ar ea way of scoping things. You can do the exact same thing in C or Java by wrapping things in { }.
But they do not create private members. The fact that you have to pass the object instance in as the 'self' argument illustrates this fact. All you have there are some generic private functions, they are not within the object scope of the object you constructed, so they aren't private methods.
All they are is privately scoped static utility methods that operate on objects that are passed into them. It's not the same thing.
> I guess we are in for a much cleaner internet?
Why do you call more browser alert's about bad coded javascript poping up every time you move the mouse a "much cleaner internet"?