Thursday, May 11th, 2006

Ajax Experience Day 2: Thomas Fuchs’ on the Enhancing the User Experience

Category: Ajax, Presentation, Prototype, Ruby, The Ajax Experience

Notes from Thomas Fuchs’ session on Ajax and Javascript/DOM techniques to build a better user experience. Thomas is the creator of, a member of the Rails core team, and has his own blog at

Why use tools and frameworks?

  • Don’t reinvent the wheel
  • Javascript gives you a ton of power within the browser
  • Use a framework to write less code
  • Let the framework take care of the browser bugs
  • Javascript can be written very similiar to Ruby, due to dynamic, high-level nature


  • at version 1.5, bundled with rails 1.1
  • ajax support – no XML support – HTML/javascript snippets only
  • behaviours – generate javascript on the server and send back as content-type:text/javascript to be automatically executed
  • hooks for easy integration with effects
  • extensions ot built-in objects: String, Number, Array, etc – example:

    1. [1,2,3].each(function(n) {
    2.         alert(n);
    3.     });
  • $ and $$ functions – $ is shortcut for getElementById, $$ is shortcut for CSS selectors ex:

    1. $$('p.hint').each(Element.hide)
  • events without cross browser pain

    1. Event.observe('some_input', 'blur',
    2.             function(e){ alert('clicked me!') });

  • at version 1.6, Thomas Fuchs the creator
  • easy visual effects, can combine effects for more advanced cases
  • drag and drop support – sortable lists demo
  • real time search, autocomplete, inplace editing, slider control
  • extras: javascript unit testing, DOM builder
  • look at the unit tests to see good examples of how to use
  • baked in to a ton of frameworks
  • resourceswiki, Rails spinoffs mailing list, irc channel – #prototype on

Visual Effects

  • advanced engine for effects – time based so you can control duration
  • more then eye candy – provide visual feedback
  • make your app feel snappy, make loading times “feel shorter”
  • can help you move away from certain proprietary plugins
  • yellow fade, fade in and out, sliding panels, puff and shakes
  • very simple example: new Effect.Appear(‘message’);
  • Nice usage of panels, fades done at – looks like Flash, but pure javascript
  • Fuchs has an article on creating your own effects at Vitamin

Activity Indicators

  • available at local and global level
  • can queue up indicators for time-based appearance or for execution in parallel
  • build your own indicators at

Lessons learned

  • not all browsers are equal
  • learn CSS, get a CSS expert on your team
  • DOM api can be slow – Firefox is the slowest, esp. on Mac – IE and Safari are better
  • cache element references in javascript variables for things you access frequently
  • innerHTML is good and fast
  • use Venkmann for profiling


  • an ajax request is the same as any other HTTP request
  • so -> don’t trust it
  • always verify data, clean input
  • take normal web security precautions

Data formats

  • for trivial stuff: HTML
  • complex updates: javascript with css selectors
  • use proper HTTP caching, only send the js libraries to client once
  • don’t over-engineer – keep it simple and lean


  • don’t use display:none in external CSS
  • browser cannot determine original, built-in display value because you overrode the default
  • use inline style instead
  • IE doesn’t hit the cache when HTML fragments are loaded via ajax that have images
  • bugs with reserved ids and IE – don’t use “length”, “item”, “namedItem”, “tags”, “urns” as ids – see Eric Meyer’s entry on this
  • watch our for trailing commas in javascript anonymous function creation
  • debugging – get Firefox, get the extensions
  • Firebug is fantastic, Venkmann for debugging, etc, etc

Q & A

  • learn the libraries – look at Prototype and source code so you know whats going on
  • plans for the future of P/S? – no concrete plans, follow what the community needs and what contributions happen – use extractions for existing apps
  • browser support – full: IE6, Safari, Firefox. Partial: IE5.5, Opera. None: Netscape 4, HotJava, Lynx

Posted by Rob Sanheim at 12:10 pm

4.4 rating from 50 votes


Comments feed TrackBack URI

So earlier in one of the other sessions people are saying how evil innerHTML is and now Thomas swears by it. I’m really confused what the deal is with that.

Comment by Brian — May 11, 2006

innerHTML is faster than straight DOM and in most cases makes it easier to read. Those that hate innerHTML may be a little green in this field.

Comment by Mario — May 11, 2006

Just getting started with AJAX, so more articles like this one with the current state of the art please!

Comment by Tom — May 11, 2006

Just want to point out that innerHTML is faster for you, not for the user. Straight DOM renders faster. Extensive string concatination slows down browser script processing. So when you say faster, you mean faster to type.

Comment by Roy — May 12, 2006

@Roy – straight DOM is way, way, slower than innerHTML. Brian’s “faster” does indeed mean “executes faster”. Look it up.

Comment by jt — May 12, 2006

oops: “Brian’s” above should read “Mario’s”

Comment by jt — May 12, 2006

all speed aside, for me it comes down to the limitations that innerHTML imposes, if I’m building a html control w/ js and i want to attach a call to a specific instance of an object via the onclick of an html object, you have to do that with element.onclick = …, and you cant do that with innerhtml :(

Comment by Allen — May 12, 2006

We initially plowed ahead using innerHTML on an Ajax research effort at my job after digesting some of Thomas’s experiences with it. However, we discovered that onmouseover and onmouseout events on a container div were firing whenever we modified its contents with innerHTML (I believe this happened in both IE and FF). This wreaked havoc with the event handlers we’d developed. Using the DOM insertion method fixed the problem and made the events behave more predictably.

Comment by Lee Fastenau — May 18, 2006

I am having an issue with using innerHTML

I am using AJAX request/response functions to dymanically update a div tag. The output string is HTML and is composed in a backend Java class (so no parsing of XML is done).

All HTML tags like TABLE (and its subsets), INPUT etc work fine

1. If the output contained a SCRIPT tag to do alerts or update FORM variables, these are not effected. If there are other tags also, the repsone correctly outputs these other tags – only the SCRIPT tag is not recognized.

2. If FORM variables contain event handlers like:

the event handlers are not effected

What am I doing wrong?

Comment by Nitin Uchil — June 13, 2006

Nitin, Look here for an explanation of your problem with script tags:

Seems you need to define the functions as variables…

Comment by Peter — October 16, 2006

Leave a comment

You must be logged in to post a comment.