Tonight I've been to a free talk at Skillsmatter by Dave Crane, all round Javascript guru and co-author of my favorite Ajax books: Ajax in Action.

I missed the start of it, thanks to the usual high standard of service on the underground, but I was there for most of it. The talk was an extension of some the topics covered in his book, I made some notes, which probably don't reflect the full value of the talk, just what I got out of it:

1. Don't fight the browser: Work with the DOM, work with the layout engine, work with the browser. The DOM (and HTML) are structured hierarchically and recursive, matching your code and processing to this model generally leads to more efficient code. In simple cases, the DOM can be the data structure. Also, the browser has a very complex engine designed for laying out content, let it do the work, don't try and position all your elements in code.

2. Models which work on the server can also work on the client: MVC is a common pattern in traditional web development, but that pattern can also be applied to Ajax applications. Replicating some of your server side model in the browser (in a simplified fashion) can lead to a simpler and more efficient application, especially when a single item of data is reflected in multiple visual components.

2.a Repetition leads to simplification: As an extension of the above, Dave discussed the method of invoking Ajax requests on the server. Often requests will be made using GET or POST, passing variables in simple fashion and data will be sent back in XML or JSON. The disadvantage here is that the server has to know about de-constructing HTTP request variables into objects, and then constructing XML or JSON out of the objects, and vice versa on the client. Why not use a simple library on each side which translates client-side business objects in the browser to JSON and sends them to the server which translates the JSON into server-side business objects. Sending data back uses the same library on the server side to translate objects back into JSON, and then the browser uses its library to convert the JSON into objects. The whole symmetry of it appealed to me You can pass the JSON around in an HTTP header - X-JSON. Prototype has built in support for this, and it is therefore leveraged by other libraries - here's some discussion of it in Scriptaculous and symfony.

3.Don't estimate, measure: There's a lot of discussion around the internet about the relative merits of 'Ajaxifying' your web application in terms of performance and server load. Dave pointed out that most of this talk tends to be unsubstantiated, and the best way to figure out the performance implications for your application is to build some prototypes and measure their performance. He then showed us some graphs he'd made by analysing the network traffic for three versions of a particular web app - 'standard' HTML pages, Ajax sending HTML to the browser and Ajax with XML data transfer. His measurement tools were liveHTTPHeaders and a custom rolled Python script, and a proxy server setup for IE which I didn't catch the name of.

In the questions there was some discussion of javascript frameworks, Dave said he'd heard 'good things' from 'some people' about jQuery and mootools. You heard it here first