OK – just dumping links to my talk – AJAX @ localhost (PDF), Latency demo (apologies to the script.acul.us guys but it was a good example) and sync == bad demo.
Related posts:
- Are You Violating the Eolas Ajax Patent? It's true: Eolas has an Ajax patent and is filing...
This entry was posted
on Friday, February 10th, 2006 at 2:20 pm, contains
50 words, 6 images, and is filed under PHP.
You can follow any responses to this entry through the RSS 2.0 feed.
Both comments and pings are currently closed.
The views and opinions in this blog post are those of its author.
The “Starbucks Facor” hehe..
February 10th, 2006 at 2:39 pm
for some reason i can’t download that pdf.. Nothing happens when I click it, firefox, safari. Too lazy to view source.
February 10th, 2006 at 3:38 pm
Regarding latency problems, perhaps we should be checking the results coming in before we apply them? Take the auto completion exmaple: if the current text doesn’t match the latest AJAX response it is simple enough to ignore the response.
Also would love to read your PDF if the link can be fixed, you have a habit of raising the right questions.
February 10th, 2006 at 3:43 pm
AJAX : Could someone tell me how this term “AJAX” is pronounced!! Coz some of my friends call it as “yezacks” and some “iacks”
February 10th, 2006 at 3:48 pm
I think Its “Yejacks” :)
February 10th, 2006 at 3:50 pm
http://www.phppatterns.com/lib/exe/media.php?delete=ajax_at_localhost.pdf
Where’s the pdf?
take a closer look at the url
media.php?delete=ajax_at_localhost.pdf
Roo(u)ts back to a couple of posts ago.
February 10th, 2006 at 4:02 pm
;) the big question is: why cant most ajax frameworks not bundle calls in INE reqest. maybe ot for this kinda application, but more important when it comes to real applications ;)
February 10th, 2006 at 4:04 pm
I found the pdf at:
http://www.phppatterns.com/lib/exe/fetch.php/ajax_at_localhost.pdf
Regards
February 10th, 2006 at 4:06 pm
How would it be “yejacks”? Where does that y come from? I’ve always said it “Eh-Jacks”, as in pronouncing the A alone then JAX.
What did you use for those demos, Harry? They’re pretty cool.
February 10th, 2006 at 4:15 pm
Excellent talk Harry, thanks! Nice to see an injection of sanity into the current hype. I think AJAX is interesting and will certainly be investigating what can be done with it.
During the talk, Harry said that the demos were done using Wink (http://www.debugmode.com/wink/)
February 10th, 2006 at 4:25 pm
Thanks akrabat. The PDF was definitely an interesting read.
February 10th, 2006 at 4:28 pm
AJAX, in the United States, is pronounced A-JACKS.
February 10th, 2006 at 5:07 pm
Thanks Alex: just discovered by blunder
February 10th, 2006 at 6:10 pm
It’s “ayax”, as any Dutch would tell you.
February 10th, 2006 at 6:54 pm
I thought “AJAX” was Greek: http://en.wikipedia.org/wiki/Telamonian_Aias
February 10th, 2006 at 7:38 pm
exactly … its “ayax”
Don’t you guys watch Dutch football??! :)
February 10th, 2006 at 8:56 pm
“Open fire. All weapons. Dispatch war rocket ‘Ajax’ to bring back his body.”
:)
February 10th, 2006 at 9:32 pm
Was a great talk, although I somehow ended up winning the AJAX book – which Harry kindly wrote ‘Ajax Rocks Man!’ inside ;)
Jee
February 10th, 2006 at 9:55 pm
Don’t you think I didn’t see you preaching REST there, Harry!
February 11th, 2006 at 6:12 am
What Ajax book would that be? And is it available in the US or on AMazon?
I thought the demos supplied by Harry above just rocked and would have loved to have been at the conference… I wonder how long before video podcasting catches on and becomes affordable…
February 11th, 2006 at 7:23 am
The seminars were video recorded, so i assume that they could be ported to a ipod video format. I don’t have a video ipod to test, but could do the conversions… I’ll have a look.
The book in question was http://www.amazon.co.uk/exec/obidos/ASIN/1590595823/qid=1139661763/sr=8-2/ref=pd_ka_2/026-5426694-6962049
Its not an exceptionally good book from the start. Actually, i’ll re-phrase. If you know zip-all about ajax, it will teach you. What it doesn’t teach you is the downfalls of ajax that Harry mentioned – those points he mentioned need to be preached a bit more :)
Jee
February 11th, 2006 at 8:43 am
Ditto, the talk was excellent. I specially enjoyed to see someone that after 5 hours of programming talk analyses things in the business context as well as acknowledging end users. Technology is not about 5 minutes of limelight, or “buzzword mashups” but ultimately making things work.
However I would like to think there is some room for some sort of AJAX to exist. Perhaps in the context of intranet applications? I agree a big percentage of existing AJAX apps are pretty useless, perhaps is not mean to be replacing GET or POST but as a complement? providing feedback?
February 11th, 2006 at 11:18 am
Just wondering if this couldn’t be easily fixed
just a simple count in the javascript sending.
and disregard data with a lower number then the last one processed.
wrong?
February 11th, 2006 at 11:58 am
Hey Harry -
Nice article. And you choose a good library to demonstrate it (as I was using scripaculous in my applications :).
I just had one question / suggestion – what if we handle this problem using a request queue? We hold all requests inside a queue and only when one request is completed will we fire the next one.
Prototype library (which is used by scriptaculous) gives us something which we can use to build such a request queue.
Let me know…
Thanks,
Mandy.
February 12th, 2006 at 7:12 am
Just a quick comment on script.acul.us – the solution for the problem I highlighted is in fact very simple: make sure that only one HTTP response at most is every outstanding – i.e. as you’re pressing keys, if the HTTP response to any given key press has not arrived by the time the user presses another key, simply abort that request. Google Suggest effectively does things that way, so doesn’t have this problem. Meanwhile I made almost exactly the same mistake as script.acul.us here: http://jpspan.sourceforge.net/examples/autocomplete.php (also the HTTP auth in that demo is broken). script.acul.us is actually some great code – other than the latency issues, the way the autocomplete “widget” works client side is excellent. And I checked impact of a variety of network issues ont the shopping cart – essentially it works well and behaves in an expected and reliable manner.
The general point I was trying to make, regarding AJAX, is “it depends” – depending on what exactly (application-wise or feature-wise) you’re doing with AJAX, some things will “work” and are suitable for AJAX and other things require thought or should be avoided. I’m actually not saying “AJAX sucks” but that we need to be more careful when using it.
Where I get concerned is where we have frameworks which are effectively discouraging developers from using their brains – the simplicity and immediacy of some AJAX toolkits, does more damage than good, IMO, at least while they don’t offer solutions for some of the harder AJAX issues like latency effects. Anyway…
The talks were videod and it may be they get published online over the next few weeks. The conference organisers were talking about this – will update if/when I know more.
Otherwise a big thanks to the PHP London crowd – for a first conference this was a tremendous success, in terms of attendance and organisation. Not everything went smoothly – expected technical gliches – but I’d strongly recommend they do this again, and perhaps broaden the subject matter beyond just PHP.
February 12th, 2006 at 11:27 am
Glad to see you are unable to spell script.aculo.us correctly as well as being unable to pronounce it… scriptalicious?
Might I also suggest that at a “developer” conference, 20 minutes giving a consumer guide to latency was a bit much. Maybe save that for a PHP Consumer Conference?
February 12th, 2006 at 2:43 pm
I pronounce it as “Zae-Jack-Ey”. Im from Poland.
February 12th, 2006 at 9:23 pm
Wao Guys Now here is the Summury I got For the “AJAX” Pronounce:
In Poland its : “Zae-Jack-Ey”
ikeo Says: exactly … its “ayax”
Trent Reimer Says: “AJAX” was Greek:
My Duct friend BerislavLopac Says: It’s “ayax”,
My United csi95 Says: A-JACKS.pronounced it as A-JACKS.
someonewhois says : “Eh-Jacks”
So The Conclusion may be : Whatever We pronounce , Its going to work like AJAX only!!!!
AJAX will Rock in any Form !
February 12th, 2006 at 11:27 pm
Huh? See the domain name: http://script.aculo.us/ – it’s a play on “fabulous” and “spectular”, not “delicous”.
Hmmm… sense axe to grind. Were you actually there? If so why not have collared me directly in the conference or after?
But I’ll address your point anyway. 20 minutes? Perhaps though I doubt it. The “Consumer Guide to Networks”, up to the point of illustrating the script.aculo.us problem, was only five slides. At two minutes a slide (about what I averaged I think) that would make 10 minutes. But it could be the video of the talk will be published, in which case you’ll be able to time it.
Was it relevant to talk about it? Well only in that it’s one of the major AJAX issues that is largely ignored right now. The word “Consumer” was used in the sense of distilling the problem into it’s clearest form, so we could focus on it.
And misunderstanding latency is not limited to AJAX – you need to read this, for example – there are common misconceptions.
February 13th, 2006 at 5:11 am
I don’t think it hit quite 20 mins. Although I understand latency, and could’ve skipped over that segment of the talk, it was a god idea to provide some brief information on it. It helps to provide a common foundation that everyone is on before talking on. Without such, more questions are expected, and can interfere with the flow of the talk.
Jee
February 13th, 2006 at 7:50 am
Fair point. Actually spent the last week trimming bits off the talk, which is harder than it seems. As a speaker it’s a balance of what you think is important to say against what is actually useful or conveyable to people listening to the talk. Particularily with technical talks it’s easy to get bogged down in details. Anyway… with experience it gets better.
February 13th, 2006 at 8:07 am
One other thing – emailed Thomas Fuchs, the script.acul.us developer by way of explaination. Just dumping it here as I feel there’s a certain wrong in pointing out problems in other peoples code in the way I did;
Reply:
February 13th, 2006 at 8:34 am
[...] Harry Fuecks has posted his slides from the recent PHP Conference UK 2006 with some of his perspectives on the popular technology. [...]
February 13th, 2006 at 10:33 am
I believe its pronounced A-JAX i.e. “ae jacks”
February 13th, 2006 at 1:38 pm
[...] So i just saw a great piece by Harry Fuecks on how latency can effect AJAX requests. Its one of his demo’s from the ajax@localhost presentation he gave at the PHP Conference Uk. [...]
February 13th, 2006 at 6:55 pm
I thought you were spot-on Harry. I was almost jumping off my chair most of the way through dying to wave my hand up and say “have you heard of Tibet?” But you had that too.
It was very worthwhile to watch you step by step explain in depth what the Tibet page just about says.
Clever, succinct and well delivered – new batteries in the microphone maybe helped too… I 2nd your comments on a great day in London, bravo and thanks to all the organisers.
February 13th, 2006 at 7:38 pm
Many thanks – much appreciated. Agree the batteries helped – Pavel had a really hard time of it with his dependency injection talk which is a shame – had an advantage there being sat at the front and he convinced me to check out what they’ve done at codehaus.org (just got to find it now ;)).
Meanwhile saw some more thoughts by someone who attended: http://www.jellyandcustard.com/2006/02/11/ajax-is-evil/
February 14th, 2006 at 10:41 am
Harry -
Thanks for the mention in your great talk. And to paulyG and others, thanks for your support.
We’re not that far off from providing what we think is a world-class toolkit. One of our challenges in communicating the entire scope of the product is to try to describe what several of our early access customers have termed “AJAX times 100″. To do this, we’ve coined a term “Client/SOA”, to describe what we’re trying to achieve with TIBET. The definition can be found here:
http://en.wikipedia.org/wiki/Client/SOA
We’re currently planning on shipping our final release at the end of Q1.
Thanks again to all!
Cheers,
- Bill
William J. Edney
Product Evangelist
Technical Pursuit Inc.
February 14th, 2006 at 3:19 pm
So Harry … you still in for a request queue ?
February 15th, 2006 at 4:00 am
Let’s say I’m for AJAX frameworks providing APIs that help solve latency issues.
Queues are probably part of that, although there may be smarter ways to go API-wise (e.g. what Tibet does with workflows).
The thing is a “request queue” and a “response queue” (if those are the right names) would have to work in different ways;
A “request queue” would need to make sure that no additional requests are sent while any active request is still in progress (no response seen from server), to be able to guarantee that there’s no chance “message Y” arrives at the server before “message X”. That’s likely to hurt, performance-wise.
A “response queue” would be more about sequencing responses and making sure response callbacks fire in the right order that matches the sequence of outgoing requests.
There’s more to it than that though and what you need will depend largely on the feature you’re trying to build. Have this in head and may blog some other time.
February 15th, 2006 at 4:49 am
[...] Think this needs stating clearly, following the comment from Bill Edney on of technicalpursuit (Tibet), and because I think it reflects experiences people are having with AJAX. [...]
February 15th, 2006 at 6:41 am
Hi!
Here is a solution for controlling network latency in Ajax (this is done in the data model inside the storage adapter that does the ajax.request call). There is an event system that informs the view when the model’s data has changed. So if the data does not change, the view will not be updated.
see:
http://www.z3lab.org/sections/blogs/jean-marc-orliaguet/2006_02_15_controlling-network
February 15th, 2006 at 9:39 am
I respect dat shorty. Feel me?
February 15th, 2006 at 10:09 pm
[...] Harry Fuecks heeft een interessante post op z’n SitePoint blog geplaatst. Het gaat over hoe je (bijvoorbeeld) zwaar kekke live search gaat reageren op het moment dat er netwerk latency optreedt. Tuurlijk, we hebben allemaal kabel of ADSL tegenwoordig, maar dat houdt niet in dat er nog vaak een X aantal routers tussen jouw browser en een website zitten. [...]
February 16th, 2006 at 4:52 am
here is another demo:
http://www.z3lab.org/sections/front-page/design-features/typewriter-demo
in my experience so far, network latency must be combined with some latency on the server (one request takes 1 second, the other takes 2 seconds) for the problem to arise.
Running the same demo without the Ajax Proxy or without the latency on the server gives totally different results, so I’d agree with Thomas that practically it may not necessarily be a problem.
February 16th, 2006 at 6:12 am
[...] Think this needs stating clearly, following the comment from Bill Edney on of technicalpursuit (Tibet), and because I think it reflects experiences people are having with AJAX. [...]
February 16th, 2006 at 3:12 pm
Think you need to be very careful there. AJAX proxy is meant to simulate network effects that do happen. For example after the talk, someone listening told me they experienced more or less the same problem using the conference WLAN (that many people were using and many packets dropped through collisions).
Another network where you see really bad latency is mobile networks (not that AJAX is a good idea there anyway).
But this could effect any network. Even @localhost if you generate enough traffic, you may occasionally get requests and responses out of order.
In general, I see this something like bank systems – there it’s not acceptable that any transactions get lost or processed incorrectly. To me “it works most of the time” isn’t enough, particularily because the tendency with AJAX is to couple the UI straight to the network.
Although this autocomplete example may not seem serious, long ago I used to work at a courier company where users were entering data at intense speed via a DOS application (Joel Spolsky goes on about these type of apps from time to time), and “autocompletes” were essential to what they were doing. They trusted the autocomplete and moved so fast, when entering data, that I expect they would not have noticed “bogus” completions. If there had been “bogus” completions, that would typically have meant packages being sent to the wrong address.
February 17th, 2006 at 1:27 pm
Yes, I think it depends on the application. For an RSS feed reader it is OK that feeds get displayed in a random order. For every that involves transactions (bank system, …) there must be a transaction manager that enforces rules for how data is accessed.
I am not sure that that the solution given for the autocompleter which consists in blocking newer transactions until the previous one has been completed is a good solution, since this is basically doing synchronous calls.
I have experimented with stack sequences (LIFO) with a queue size of 1. It guarantees that only the latest action of the user will be displayed (the other ones are discarded).
for instance if you type:
1 – 2 – 3
in one sequence, only ‘3′ will be displayed
If works fine, the only problem is that there must be a timeout so that requests do not block the entire sequence, indefinitely.
February 18th, 2006 at 6:27 am
Guess it really needs trying. You brought up those magic words “it depends” like I’ve been trying to. Agree in general this is something like synchronous calling but for autocompletion, it may be the most effecient way. We also need to bear in mind that browsers place restrictions on the number of concurrent XMLHttpReqeusts (plus it costs resources).
The other issue there is also think sometimes a synchronous style is needed – if you want to make sure that requests arrive at the server in a given order, a simple approach is to have the client only send one at a time.
Been looking at what you’re doing and like it.
February 20th, 2006 at 6:34 pm
[...] Via Keith—here’s a problem I’m kicking myself for not covering explicitly in AJAX@localhost—Troubles with Asynchronous Ajax Requests and PHP Sessions by Marc Wandschneider. Normally, when you write web applications in PHP, this is really not an issue, as each page request gets their own execution environment, and a user is only visiting one page at a time. Each page request coming from a particular user arrives more or less sequentially and shares no data with other page requests. [...]
February 27th, 2006 at 8:27 am
[...] AJAX@localhostSitePoint, Australia - Feb 10, 2006… links to my talk AJAX @ localhost (PDF), Latency demo (apologies to the script.acul.us … You can follow any responses to this entry through the RSS 2.0 feed. … [...]
March 3rd, 2006 at 5:02 pm
asdfghj
February 21st, 2007 at 10:51 pm
zelmonoloac
November 23rd, 2008 at 7:08 am