DOM Performance

[00:00:00]
>> [MUSIC]

[00:00:03]
>> Douglas Crockford: So performance is a huge problem in working with the DOM. Every time you touch a node, you pay a huge time penalty. Restyling has a big cost. Reflowing has a big cost. Repainting has a big cost. Random things like node lists can have a huge cost. A node list looks like an array except every time you touch it it can repeat the query that caused it to come into existence which can be wildly expensive.

[00:00:30]
And it turns out in most applications JavaScript has a very small cost. So if you took all the time that's being spent in the browser and say, this much as parsing, this much as marshalling, this much as rendering and so on. JavaScript will be like that much but I see people going after their code, trying to shrink it down more, and more, and more when it's all this other stuff that's taking the time.

[00:00:52]
Trying to optimize that, if JavaScript engines were infinitely fast most web applications would run about the same speed. No one would notice any difference. So you can't optimize for performance unless you have good tools. Unfortunately, we now have some good tools. For example, there's speed tracer on Chrome.

[00:01:14]
It records micro dense as your application is running in the browser. And when it's done, you can then do a post-mortem analysis and it will show you all the hotspots in the code and what is consuming time. And with that information it is possible to them optimize the application.

[00:01:32]
Microsoft has a similar thing called performance dashboard which I think starts becoming available on IE 11. Optimization without good performance data is a waste of time. It turns out that a small amount of JavaScript can transform the DOM just one of the world's awfullest APIs into something pleasant and productive.

[00:01:55]
So Ajax libraries are fun and easy to make which is why there are so many of them. Any apps should be using one. They provide portability because the browser is how, are hugely inconsistent. And so you need a library that will deal with those inconsistencies for you so you can be working with a much better model.

[00:02:18]
They provide correction of errors that are in the def specification of the DOM. They provide a much higher programming model, something where you can be much more productive. And they also provide sets of widgets, which can simplify your development work. So how do you choose? There are so many libraries out there.

[00:02:36]
It would take longer to do a complete evaluation of all the existing libraries than to build a new one from scratch. I don't recommend that anybody build a new one from scratch. So some years ago the Ajaxians suggested throw a dart cuz just picking one at random they're all pretty good and they're all much better than talking to the DOM directly so you can't lose, just pick one at random.

[00:02:59]
The problem with that is that each one is a trap, that they are all extremely incompatible with each other. In fact some are incompatible with themselves from one version to another. That point one of something might be completely incompatible with point two of something, and once you get into one of these things you are stuck.

[00:03:19]
It's made of tar and everything you write is gonna be dependent on this thing and getting loose from it and onto something else is extremely expensive and painful. So how do you decide what to do? Some years ago I predicted that the market could not tolerate having so many of these libraries around that there is gonna have to be a shakeout.

[00:03:39]
And I predicted that they'd would all disappear the be maybe two winners. One of them was probably gonna be Microsoft, because one of the winners is always Microsoft. And one would be something else, PlayWire, Dojo or jQuery or something. That turned out to be completely wrong. The number of libraries has only increased since then.

[00:04:00]
And the first library to fail and completely leave a market was Microsoft's Atlas which was so bad even they couldn't use it and they switched to jQuery. So how do you decide? And it's a really hard problem and I do not have a solution. And we find more libraries coming online all the time, more platforms, more ways of doing stuff.

[00:04:24]
And I thought I can't keep up with the stuff. So how do you choose? I have no good advice except this for what it's worth. Ask JSLint, take any candidates that you're considering run through JSLint. That's an objective measure of code quality. It will give you same indication how well the things written.

[00:04:44]
Maybe that's meaningful to you.