Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Bad is DOM Interaction Really?

andyshora.com

Post reply on HN
Print view View original

11–20 of 38 posts

Re: How Bad is DOM Interaction Really?

#11

Post by PavlovsCat »

oscilloscope wrote: post #7
pcunite wrote: post #2

After 10+ years as a performance leaning C++ desktop app developer I'm looking for any and all tips to make JavaScript (jQuery too) work in perceivably faster ways. I'm use to threading database calls, using message queues, and views updating themselves from caches. It’s a new world for me and feels somewhat like a step backwards. Here I come html5!

You can use queues when creating a large number of elements. Use requestAnimationFrame and each frame pop some elements off the queue to render them. This will help prevent the page from locking up during render events.

Also, when adding many elements (or not so many, but over and over), add them to a DocumentFragment [ http://developer.mozilla.org/en-US/docs/Web/API/DocumentFrag... ] first, and then attach that to the DOM in one piece (one big DOM update is better than many small ones).

Re: How Bad is DOM Interaction Really?

#12

Post by kellegous »

I mean no offense to the author, but speaking of the DOM as if it is uniform in terms of performance seems silly. Pretty much every piece of API in the DOM has its own semantics and performance expectations (even if it's presented as a JavaScript property). Reading Element.offsetLeft, for instance, is a whole different world from reading Node.nodeType.

Just looking at their implementations in WebKit should tell you why:

https://github.com/WebKit/webkit/blob/master/Source/WebCore/...

https://github.com/WebKit/webkit/blob/master/Source/WebCore/...

Re: How Bad is DOM Interaction Really?

#14

Post by eagsalazar2 »

TL;DR: Writing is slower, debounce resize event handlers, cache references to dom nodes or jquery selections.

Really the resize thing is sort of bs also because it is such an incredibly rare thing to handle (99% of all apps will never ever require handling resize except to test responsive designs)

Re: How Bad is DOM Interaction Really?

#15

Post by esailija »

kellegous wrote: post #12

I mean no offense to the author, but speaking of the DOM as if it is uniform in terms of performance seems silly. Pretty much every piece of API in the DOM has its own semantics and performance expectations (even if it's presented as a JavaScript property). Reading Element.offsetLeft, for instance, is a whole different world from reading Node.nodeType. Just looking at their implementations in WebKit should tell you w…

Also, the code doesn't call into DOM directly but uses jQuery .html() for "reading" and .html(Math.random()) for "writing".

The case is extremely misrepresented indeed.

Re: How Bad is DOM Interaction Really?

#16

Post by ivanca »

pcunite wrote: post #2

After 10+ years as a performance leaning C++ desktop app developer I'm looking for any and all tips to make JavaScript (jQuery too) work in perceivably faster ways. I'm use to threading database calls, using message queues, and views updating themselves from caches. It’s a new world for me and feels somewhat like a step backwards. Here I come html5!

For performance any platform is a step backwards, the leveling for easier/broader access is never free.

Re: How Bad is DOM Interaction Really?

#17

Post by bdg »

bkjelden wrote: post #3

Caching jQuery selectors may result in a speedup, but as with all caching systems I've run into nasty, hard to trace bugs that were the result of stale cached jQuery selectors. So I'd add the caveat to caching jQuery selectors that standard premature optimization rules still apply.

Caching them in local fucntion scope should be harmless. For instance: grabbing #x, using it inside a decision structure and iterator. Caching #x as a global constant is probably setting you up for some fun debuging later.

Re: How Bad is DOM Interaction Really?

#20

Post by AsymetricCom »

esailija wrote: post #15
kellegous wrote: post #12

I mean no offense to the author, but speaking of the DOM as if it is uniform in terms of performance seems silly. Pretty much every piece of API in the DOM has its own semantics and performance expectations (even if it's presented as a JavaScript property). Reading Element.offsetLeft, for instance, is a whole different world from reading Node.nodeType. Just looking at their implementations in WebKit should tell you w…

Also, the code doesn't call into DOM directly but uses jQuery .html() for "reading" and .html(Math.random()) for "writing". The case is extremely misrepresented indeed.

The DOM is a failed institution trying to grab on the the ledge before it falls into the abyss. W3C should be disbanded and HTML5 abandoned. JavaScript and it's ilk should be boycotted by users as well. This kind of complexity should exist on the server, not in the browser. I understand that people want to run complex apps in the browser. It's a bad idea in general but where it's needed, it should be PLATFORM DEPENDENT, implementing the tools that keep that platform safe. ie iOS, Windows, whatever. We are still in the browser wars, why are we so keen to adopt standards that aren't standard?

DOM Lvl 4 even features GC! Can we not see why this is a bad idea?!? Keyboard bindings also do not belong in a "standard". I wish this would get more attention by serious developers, but I think that most people who know better wouldn't care and aren't interested in understanding and digging into a lame standard. It's a land grab, only enterprises can and will ever be able to implement it correctly and completely, as the standard spreads to consume more of the user's space.

Here are some people who agree with me:

http://www.adamcrume.com/blog/archive/2009/12/23/the-java-do...

http://programmers.stackexchange.com/questions/147451/whats-...

Post reply on HN