Comment on “A Study of Ajax Performance Issues”
This study shows performance issues of native javascript APIs on multiple browsers.
I think this is definitely a good read for all DOMers who work closely with client scripts.
I just want to point out couple things.
1. innerHTML vs. appendChild(dom)
I use innerHTML when I do not need to get a reference back for later use from the operation or generate many HTML elements. When I need to manipulate the HTML element that is created through DOM object, I usually cache the object to a global variable or a object’s property. Also when many elements need to get appended to a DIV tag or something else, innerHTML gives faster performance over appendChild method. If you look at the tv.yahoo.com/listings_setup page, channel rows are created through innerHTML and it’s quite quickly rendered even if there are over 500 rows. If I injected more than 500 rows using appendChild way, it would have been very slow and eventually locked up a browser for a bit during the process.
2. Let’s not focus on numbers too much.
It’s good to know the detail number of each process. However, even if one process took 30 or 100 milli seconds, it would have not been noticed by a regular user. If one tasks got involved with multiple procedures and ended up taking up 1-2 seconds, I’d call it “design problem”, not a performance problem. With DHTML manipulation and Ajax, possible things you can do with them seem endless, but you do not want to push the line too hard. Especially in ajax application, design/architecture matters more than API/scripting.
3. Learn the limit.
Knowing the limit is very important. There are limits in any scripting languages. The role as a developer/engineer is to play around the limit and still produce a nice product for users. Of course, there will be requirements from product people that may hit the limit and cause performance issue, but as a developer/engineer you should put your efforts to change the requirements or be creative to do workaround on the limit.
Again, the numbers on the report give a real nice overview of what API to use and not.
