The key is to keep the page as useable as possible. Loading and response need to be well balanced, for example: implementing a function may increase response by 1ms, but if that saves on memory.

I haven’t gotten any publicity for it, but I’ve been working on a gaming page for some time…It may be worth taking a look at, I’ve made many small sacrifices for overall improvements. Decreased both overhead and response time, I still have much work to do, but the concept is there.
http://www.sentertainment.net/new3/

i’d say: doh…go home and really optimize that app. in the meanwhile please shut up about web-development.

I understood from the slide that the big gains are to be had by the use of innerHTML, and then the event attaching via DOM level 0 is necessary to hook the events up because the alternative is some kind of dom traversal to find the node….

The thought that toolkits/libraries should be used as for “scaffolding” is a nice way to think of where these things fit in. Toolkits should slowly progress from where you are, rather than replace all your previous work.

Joseph and the Plaxo Team, thanks for sharing!

p.s. IE + XHTML = HTML 4.01 transitional, save yourself some cross-browser CSS headaches and always use HTML 4.01 Strict + good syntax. I guess 2001 still lingers with us until all users are finally using XHTML compliant browsers. ref: Ian Hickson’s “Sending XHTML as text/html Considered Harmful”

I guess there’s a trade-off we need to make between improving speed and improving coding standards.. Some may argue that it is better to be safe and accessible.. But in the end, it’s the result that really matters..

It’s important too, not to overload the pages with a lot of js cool effects or ajax interactions. Page flow must be consistent, and the server-side model should do the hard work for themselves. Don’t forget the only purpose of client side scripts (js) is to INCREASE the usability, which is optional and totally subjective.