By Simon Willison

A9 and Google Local

By Simon Willison

If you want proof that remote scripting has hit the mainstream, look no further than the recent launches of both Amazon’s search engine and Google’s new Google Local service. Both make extensive use of remote scripting, a technique whereby JavaScript is used to refresh content from a server without requiring a refresh of the whole page.

In Google Local’s case, the technique used is the increasingly popular XMLHttpRequest. To see it in action, try zooming or recentering the map on this results page. The JavaScript is a pretty ugly mass of browser detection scripts but it works just great in the browsers I tested it in. Meanwhile, uses an interesting variant on the old hidden iframe trick. Once the iframe document has finished loading, it calls a function to copy its own innerHTML in to a div contained in the parent window that loaded it. View source on this page for an idea of how it works.

Web applications have long been written off as inferior to native desktop applications due to the requirement of a full page refresh to load fresh data from the server, but now that techniques such as the above are becoming more widespread that criticism is losing its relevance. I don’t think we’ve even begun to scratch the surface of the possibilities that remote scripting opens up.


  • Adagio

    Bah – just look at the code. No DOCTYPE, pure TABLE design. *sigh*

  • I don’t think we’ve even begun to scratch the surface of the possibilities that remote scripting opens up.

    Second that!

  • Once the iframe document has finished loading, it calls a function to copy its own innerHTML in to a div contained in the parent window that loaded it.

    I know that for my application I do something similair. What I generally do, is when the iframe loads, call a function on the main javascript window. This window can then access the data from the iframe that has now loaded.

    Part of the reason for doing this is I have a sort of switch back. I use the iframe for automatic checking, e.g. lets say checking for new emails to arrive so it reloads itself. When some remote server call is made, i reuse the iframe to call that page, and then reset it to the auto reload of the email check page, so far it works pretty well; I have functionalised it and linked into my html/content functions.

    I don’t have demo online but will currently; I have begun to realise how useful this is going to be for our app, unfortunatly that was a bit late in development stage so it is going to have to be next version to start fully using it, but the usefulness is so there.

    One major thing I have been considering is pre-form submit validation. You can now remove all that js validation; validate using the PHP you will do the validation with anyway and save the rewrite of validation code in two languages.

  • On that validation, I am wondering if you can:

    i) Someone enters form data. Press the Submit button
    ii) Make a remote script call to server
    iii) If not validated, some javascript wizadry to explain this to user. Page is already there etc.
    iv) If validated, perhaps do whatever we where going to do, then send back a call to the browser to redirect to the page you where going to anyway.


    i) no js validation functions
    ii) no need to even consider writing the PHP to handle creating forms to handle a failed form submit, e.g. handling difference between editing a form and redoing a form etc.
    iii) Much quicker, no browser reload for a failed form submit.

    Cearly, this would completly break the app if you disable javascript, but in apps where you have some control over the environment, that should not be a problem.

  • padders: I love the idea of validation against your server-side PHP logic using remote scripting. I’ve implemented dual validation (client- and server-side) several times and the duplication of validation logic in two different languages has always bugged me.

  • Tooting my own horn though it may be, this is sort of what I was trying to get at in

    For full-strength validation, the technique would need to be taken further, but there’s no reason you can’t specify your validation in one xml document residing on your server, and have both your javascript and server side language reference that file to validate forms.

  • MH

    Gmail seems to be doing something similar, though their code is quite obfuscated.

    The question I have is, does this scripted switching of content sit well with screen readers? Do they somehow get notified of the change?

  • I doubt screen readers cope very well with remote scripting – it relies on JavaScript support for one thing, and I doubt that the hooks for understanding that new content has been loaded are particularly useful even in screen readers that have JavaScript support. Creating accessible tools with remote scripting is definitely an interesting challenge, as it requires a “fall back” mode for non-JavaScript browsers.

  • Surely posting an entire form back to the server for validation is giong to take just as long whether done via a hidden iFrame or with an old-fashioned POST/GET of the entire page. If all of the elements of the page have been cached by the browser where is the advantage (especially if you have to write in extra code to handle accessibility)?

  • omnicity,
    Posting the entire form isn’t really as huge a concept as it sounds, because all you’re sending is a bunch of string data. Then if we’re doing validation you can load the results into the page elements that display your message or reload the form fields etc…

    This is great. I’m more partial to the XML HTTP Request method becasue it seems a whole lot cleaner, but either way it’s so much better without a full page refresh.

  • chili

    Shouldn’t the hidden iframe trick work with opera? A9 does a page refresh instead when viewed from opera. Why?

  • awasson: You missed my point – either method sends the same amount of data to the server, give or take a few bytes, but where is the advantage in returning XML that the client must manipulate, compared to returning pre-formatted HTML? WE’ve all spent a lot of time seperating content from presentation recently, to good advantage, but this seems to be going backwards, by now intertwining content, presentation, code and an additional markup language.

  • francis

    all this things sums up to one thing. the guy who has the most time to develop and tweak his web application will definitely have the best user interface. users dont care in what way it was implemented. they only care if it’s usable or not.

  • Ben Curtis

    The focus on form validation for this technique is an error. The point of javascript validation is to avoid the request and response lagtime of communicating to the server; remote scripting does not avoid this problem and is therefore not a solution to it.

    The true benefit of this technique is that you can refresh portions of a page without downloading the whole interface again. Remote scripting is useful during form submission only if the response does not affect the whole page — for example, a poll that displays the results once submitted, or a content management system that redisplays the content after having been saved in the database.

    One thing we use it for is we dynamically retrieve select-lists of names and addresses from the database as the first few letters are typed. The advantage here is that the select-list allows instant recognition as to whether the person has already been entered, and with peculiar spellings it reduces inaccurate entry.

    I can also see more complex applications that need fast response times being done on the web now. For example, a hotel reservation system could dynamically update the availability of rooms on a calendar based on user input of room type, date range, etc. Only after all the information is settled on would the actual submission take place; until then, only the relevant changes would shuttle back and forth between the client and server.

  • SchizoDuckie

    I’ve built something like this too, but then purely JS based…

    If you use the ‘target’ attribute of a hyperlink, and fill in the ID of any existing div on the page, the link will automagically be loaded into the div through a hidden iframe.
    It could be very easily expanded to catch form tags too, but i haven’t needed that yet so not implemented :P

Get the latest in JavaScript, once a week, for free.