The Price of Ajax

...

I was under the impression that most browsers cache <head> references to Javascript and CSS files. Is that actually the case?

But I hear 'ya! I have an admin page with 100 rows of drap-and-drop + in-place editing -- not only is it a lot of HTML, Safari runs like its legs are cut off at the knees.

Scott

Regarding the cost of inline javascript, I have come up against the same issue recently (and I’ve never liked inline javascript all that much anyway). Now that they’ve
solved the onload woe
it’s easy to make suckerfish-like solutions. For your delete example, you could do something like this:

  • Create a single function that accepts dom element, parses the text appropriately and makes the ajax call (using prototype if you wish)
  • Create a separate function that loops through all of the links on the page that have a certain class (which prototype makes easy) and add an onclick event handler that passes the link to the function
    For those that hate writing javascript, you can take advantage of the rails helpers and get the benefit of external js files by dynamically creating the js files. Rails recipes has a good description of this under “Lightning Fast Javascript Autocompletion” - since it’s just a view, you can use all of the remote_function helpers and wrap them in function names.

You should be aware (and someone please correct me if I’m wrong) that using UJS can significantly slow down performance for pages with large numbers of elements.

Granted, I can’t speak from experience for UJS, but I can with Behavior (http://bennolan.com/behaviour/), which uses the similar technique of using CSS selectors to apply javascript. The slow down occurs because to selectively apply the javascript the library has to scan (and rescan, upon each redraw) your entire DOM to identify those elements it should add the JS to.

On most pages, it won’t be a problem. But in our case, we had a page with many, many elements, and the slow down and CPU usage was painful.

Again, I could be wrong, but something to consider.

Jake

Steve Bergman wrote:

BTW, anyone know why the image src is set to /images/delete.png?1156712862 instead of just /images/delete.png?

Actually, I'm surprised that this wasn't pointed out... as far as I know, rails automatically adds a random-ish number to the name of items that usually get cached (images, stylesheets, javascript files) to prevent them from being cached by the browser in DEVELOPMENT mode. This makes the development process easier and less problematic.

You shouldn't see that in production, so it should be fine!
Cheers
Mohit.

To further reduce the file size, you could insert the image tag dynamically as well. Which will reduce your html to :

BTW, anyone know why the image src is set to
/images/delete.png?1156712862 instead of just /images/delete.png?

the stuff after the ? is based on the timestamp of the image file (or other resource like javascript, css etc.). These resources are usually cached by browsers. When you change your image (or css) this number changes which forces the browser to reload the image. Helps with cases where you’ve upgraded your css but the users are still using the older version.

Hammed

I agree that using UJS and a lot of css selectors could lead to poor
performance. However, if you are using some sort of predictable
scheme for the id's and classes of your elements, you could do some
optimization if things get bad.

For example, if you have a table of 500 rows that all need an onclick
event attached, you can give them all the same class and then try out
some of the different "getElementsByClassName" functions to see what
performs the best. The css selector stuff is powerful, but it can be
slower then a simple function that only takes a css class and a root
node (for where to start the search). A mix of both would probably be
necessary for a page with a lot of events being attached.

- Rob