AJAX@localhost

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.

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

  • fenryr

    The “Starbucks Facor” hehe..

  • bartb

    for some reason i can’t download that pdf.. Nothing happens when I click it, firefox, safari. Too lazy to view source.

  • Trent Reimer

    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.

  • Anonymous

    AJAX : Could someone tell me how this term “AJAX” is pronounced!! Coz some of my friends call it as “yezacks” and some “iacks”

  • http://www.saumendra.com saumendra

    I think Its “Yejacks” :)

  • willthiswork

    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.

  • sebs

    ;) 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 ;)

  • Alex
  • http://nathanwwong.com someonewhois

    I think Its “Yejacks” :)

    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.

  • akrabat

    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/)

  • http://nathanwwong.com someonewhois

    Thanks akrabat. The PDF was definitely an interesting read.

  • http://www.chameleon-systems.com csi95

    AJAX, in the United States, is pronounced A-JACKS.

  • http://www.phppatterns.com HarryF

    Thanks Alex: just discovered by blunder

  • http://www.lopsica.com BerislavLopac

    It’s “ayax”, as any Dutch would tell you.

  • Trent Reimer

    I thought “AJAX” was Greek: http://en.wikipedia.org/wiki/Telamonian_Aias

  • ikeo

    exactly … its “ayax”
    Don’t you guys watch Dutch football??! :)

  • Ren

    “Open fire. All weapons. Dispatch war rocket ‘Ajax’ to bring back his body.”

    :)

  • Jeewhizz

    Was a great talk, although I somehow ended up winning the AJAX book – which Harry kindly wrote ‘Ajax Rocks Man!’ inside ;)

    Jee

  • http://www.phpism.net Maarten Manders

    Don’t you think I didn’t see you preaching REST there, Harry!

  • Sojan80

    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…

  • Jeewhizz

    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

  • Gonzalo

    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?

  • lajkonik86

    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?

  • Mandy Singh

    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.

  • http://www.phppatterns.com HarryF

    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.

  • scriptalicious?

    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?

  • Anonymous

    I pronounce it as “Zae-Jack-Ey”. Im from Poland.

  • http://www.saumendra.com saumendra

    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 !

  • http://www.phppatterns.com HarryF

    Glad to see you are unable to spell script.aculo.us correctly as well as being unable to pronounce it… scriptalicious?

    Huh? See the domain name: http://script.aculo.us/ – it’s a play on “fabulous” and “spectular”, not “delicous”.

    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?

    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.

  • Jeewhizz

    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

  • http://www.phppatterns.com HarryF

    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.

    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.

  • http://www.phppatterns.com HarryF

    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;

    Hi Thomas,

    Just wanted to offer a quick word, in case you were wondering, with
    what’s going on here
    http://www.sitepoint.com/blogs/2006/02/10/ajaxlocalhost/ and here:
    http://www.phppatterns.com/stuff/latency.html

    Want to point out that I’m not trying to belittle what you’re doing.
    In fact picked script.acul.us _because_ it’s a good project but
    illustrates well some of the problems that haven’t been well solved
    with AJAX yet. There are many other examples of AJAX online which
    suffer similar problems, having failed to consider network issues
    fully, and the purpose was to try to focus attention so we can fix
    these problems.

    I hope what I wrote in a later comment
    (http://www.sitepoint.com/blogs/2006/02/10/ajaxlocalhost/#comment-13886)
    serves as some consolation (there’s also my opinion on how to fix the
    problem there);

    “script.acul.us is actually some great code—other than the latency
    issues, the way the autocomplete “widget” works client side is
    excellent.”

    Anyway, hope there’s no hard feelings and that you understand this was
    done in the general interest of betterment of AJAX-style applications.

    All the best,

    Harry

    Reply:

    Heya,

    I find the example a bit over-constructed, but you’re probably right
    on the latency
    issues in general.

    I’d say that it’s a bug that should be fixed, but nothing special, as
    it works fine most
    of the time and autocompletion is an add-on to text input fields, not
    an essential
    functionality. Plus the autocompleter only issues requests to the
    server after a specified
    delay (with a reasonable default), so it _doesn’t_ call the server on
    each keystroke.

    So, latency really is a non-issue most of the time (at least with the
    autocompleter),
    but yes, it could freak out users when certain specific conditions
    are met (in this
    case strange proxy behaviour meets slow typing).

    Can you file a bug on the ror trac?
    http://wiki.script.aculo.us/scriptaculous/show/BugReports

    And no, no hard feelings, good to see that Ajax (and thoughts on it)
    are evolving
    to make web apps better. :)

    -Thomas

  • Pingback: Ajaxian » Ajax@localhost Talk (Harry Fuecks)

  • that_weasel

    I believe its pronounced A-JAX i.e. “ae jacks”

  • Pingback: There and Back Again » Blog Archive » AJAX and Latency

  • paulyG

    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.

  • http://www.phppatterns.com HarryF

    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.

    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/

  • bedney

    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.

  • http://www.primacognos.com bigduke

    So Harry … you still in for a request queue ?

  • http://www.phppatterns.com HarryF

    So Harry … you still in for a request queue ?

    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.

  • Pingback: SitePoint Blogs » Two kinds of AJAX: HTML++ vs Client / SOA

  • jmo

    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

  • Bling Bling

    I respect dat shorty. Feel me?

  • Pingback: Scriptorama » How many ticks does it take to get the data of it?

  • jmo

    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.

  • Pingback: Tech2All.Com » Blog Archive » Two kinds of AJAX: HTML++ vs Client / SOA

  • http://www.phppatterns.com HarryF

    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.

    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.

  • jmo

    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.

    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.

  • http://www.phppatterns.com HarryF

    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.

    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.

    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.

    Been looking at what you’re doing and like it.

  • Pingback: SitePoint Blogs » AJAX and Session “Race Conditions”

  • Pingback: RSS SCRIPT » A swipe at Advani, a nod to Left, Manmohan plays safe

  • http://test.net Luk

    asdfghj

  • baspasboacel

    zelmonoloac