I wouldn't go that far. The DOM really is slow, due to a number of tradeoffs made in the API design. But the DOM is meant for working with HTML (and XML) docume

I wouldn't go that far. The DOM really is slow, due to a number of tradeoffs made in the API design. But the DOM is meant for working with HTML (and XML) documents -displaying them, updating the display, and getting input from the user- and it's fast enough for that. If you're using the DOM for anything else, you're almost certainly doing something wrong. One of the first rules to being fast in a GUI of any sort, Web-based or otherwise, is simple: don't abuse the runtime. Objective-C's runtime isn't very pretty for performance either, which is why you use the provided APIs when you can. When you can't, you get the data out of the objects and into a more suitable format, work with them there, and put the result back into the objects for display. There were some truly egregious cases of runtime-abuse in the old days: the first OSX versions of OmniWeb come to mind. But the dev community eventually caught up. It's the same with the DOM. That's the thing about jQuery-abuse. jQuery is a very, very good hammer: an awesome tool for working with the DOM. The problem comes when people start to think that every problem looks like a nail: they start using the DOM for everything, including things that it's just plain not designed for. And it works, more or less; it just doesn't work well. That's not a problem with the framework. It's a problem with the user.