The DOM isn't slow

The point the author is trying to make is perhaps a reasonable one, but what an inappropriate communication style. I don't know if the author realizes the tone is so off-putting, but I've found that supportive feedback and constructive criticism goes a lot further in professional environments than name calling and insults. Put another way, if someone on my team at work communicated like that I'd have a conversation with them about more effective approaches less likely to alienate or offend colleagues.<p>There appears to be an uptick of hyper-agressive technical posts over the past several years. I'm not sure where it started, but I'm hoping it burns itself out soon.<p>(If you're the author, I apologize for calling you out on this. Nothing personal at all, I just wanted to make the general point about tone.)

It would be more accurate to say something along the lines of: "it's often possible to get the DOM to perform a lot faster than it currently is for you", or even: "speed probably isn't the biggest problem you'll face with the DOM; inconsistency and weird browser quirks are".<p>That said, the following things irked me:<p>&#62; Abstraction is more likely to increase speed, because someone smarter than you has written the bit that needs to be fast.<p>That's a very sweeping statement that doesn't really describe the situation. It obviously depends on what you're doing, who wrote the abstraction and how much is being abstracted.<p>&#62; First: ignore pretty much anything Facebook has to say about DOM performance. They really have no idea what they are talking about. Sencha was able to make a version of the Facebook mobile app with their framework, and it was FASTER than the official, native app, and Sencha isn’t even particularly fast.<p>If you create an app that has half the feature set of another app it will likely be easier to make it go fast.<p>&#62; Second: Stop using DOM libraries out of habit! If your target browser is IE8 or above, jQuery hardly provides any features that aren’t shipped on the host object anyway. document.querySelectorAll will pretty much do everything you need. jQuery is a tool, not a framework. Use it as such.<p>jQuery provides a clean sensible API. Something that is currently still lacking from the DOM (despite all the improvements). document.querySelectorAll will definitely not do "pretty much everything" you need out of the box.

I stopped reading when he said that he thought 10000 divs in 200 milliseconds was impressive.<p>That was impressive on a 486 SX. The things that make people go "woa!" in a browser are, barring WebGL demos entirely made in shaders, completely not-impressive when compared to doing the same outside a browser. This is fine. The browser is expected to handle so many wildly varying use cases at once, it can't be top speed at all of them. But don't go around telling us that something that Firefox does on a 2Ghz quad core PC is amazing when the same has been done on an Amiga 500.<p>The DOM <i>is</i> slow. It can be used to be <i>fast enough</i> for most purposes.

I was a little surprised to hear "use document.createElement, it's faster than innerHTML" since the conventional wisdom was exactly the opposite a few years ago.<p>Someone has already written a decent JSPerf to test this out: <a href="http://jsperf.com/innerhtml-vs-createelement-test/16" rel="nofollow">http://jsperf.com/innerhtml-vs-createelement-test/16</a> (see also <a href="http://jsperf.com/innerhtml-vs-createelement-test/4" rel="nofollow">http://jsperf.com/innerhtml-vs-createelement-test/4</a> for a slightly deeper dive)<p>Based on the Browserscope results (and my own testing), it seems that document.createElement is faster in Webkit but slower in everything else (Gecko, Trident). So, a bit of a wash there unless you're targeting mobile.<p>That said, in my experience HTML (template) parsing isn't the main bottleneck to getting an app to that smooth 60fps feeling. Usually the big targets you want to focus on there are avoiding cascading reflows/repaints, using smoother animation technologies such as requestAnimationFrame or CSS transitions/animations, understanding how to trigger hardware acceleration and what its limits are, and keeping careful control of your CSS special effects (border radius, box-shadow, gradients, etc). I recommend checking out <a href="http://jankfree.com/" rel="nofollow">http://jankfree.com/</a> (especially the I/O talk) if you're interested.<p>(edit: I don't really like the original article's vitriol, but he's right about a couple things. Manipulating your nodes outside of the DOM <i>is</i> much faster, although you don't need to be inside a DocumentFragment to do this (don't get me wrong; DocFrags are pretty useful). Also, yes, please don't keep running those jQuery selectors over and over again. Store the jQ object that the selector returns to you and just reuse that)

I call linkbait/trollbait.<p>&#62; People often throw around the statement “The DOM is slow”. This is a completely false statement. Utterly stupid. Look: <a href="http://jsfiddle.net/YNxEK/" rel="nofollow">http://jsfiddle.net/YNxEK/</a>. Ten THOUSAND divs in about 200 milliseconds.<p>How is that even an argument? Just because you can insert a fragment containing 10k &#60;div&#62;s in 200 milliseconds doesn’t mean that the DOM is not slow compared to other operations in JavaScript.<p>DOM operations are still the slowest operations you can perform using JavaScript in a web browser.

I went to a meet up a few weeks ago on Sencha Touch and how they did the Fastbook (<a href="http://www.sencha.com/blog/the-making-of-fastbook-an-html5-love-story/" rel="nofollow">http://www.sencha.com/blog/the-making-of-fastbook-an-html5-l...</a>) project to prove that HTML5 is, indeed, ready to provide host an application as complex as Facebook a few weeks ago and it opened my eyes in a few ways.<p>This article is correct, and provides an example, in saying that the DOM can easily create thousands of elements in milliseconds. However, the problem is that events and interactions with it all happen on a single process. Things load and block the thread, an event happens and blocks the thread, etc.<p>The Sencha guys did something really smart. They used an object pool with one object: requestAnimationFrame, as the core of their mobile platform and sent EVERYTHING to it. That way events, loading, or whatever, didn't block, but happened in a FIFO manor. They also kept the number of dom elements static and just reused them when needed, so an object pool of dom nodes -- no creating or destroying nodes.<p>The things that make working with the dom slow isn't only creating nodes, but applying styles, listeners, and destroying them -- basically creating an application.<p>I do agree with the overall premise that a lot of developers do not know the best methods/practices/patterns to utilize when creating complex applications. I learn new things daily and I hope that our community continues to teach itself and provide tools to make getting things done easier.

&#62;If all you are doing is making HTML elements, DO NOT USE JQUERY.<p>That's pure premature optimization. I don't understand how people can still be making blanket statements about performance costs like this. Using jQuery to create HTML elements is <i>fine</i>. It's convenient and succinct, and it keeps your code consistent. Otherwise, you'll have two ways of creating HTML elements: one for when you are just creating an element, and another for when you need to use jQuery on it afterward.<p>But if you <i>do</i> hit a point where creating HTML elements with jQuery is slow, you optimize that point and leave a comment explaining why you're doing it that way.<p>People get these ideas in their heads that somehow they're going to be able to code everything super fast from the very start, and it's nonsense. All you're going to do is make it harder to maintain your project.

&#62; Second: Stop using DOM libraries out of habit! If your target browser is IE8 or above, jQuery hardly provides any features that aren’t shipped on the host object anyway.<p>Nope, sorry, 9 times out of 10 the provision is theoretical and the interface is garbage. querySelector is pretty much the only one which does not suck — hence it being used as an example every single time.<p>* Querying or altering elements? Verbose shit.<p>* Binding events? Verbose shit.<p>* <i>Delegating</i> events? You've got 2 different specs, the most recent one is unimplemented and the older one is prefix-implemented everywhere (and useless as far as I know).<p>* Inserting elements in a DOM tree? Oh boy you're going to have a fun time manually traversing crap until you can reliably use insertBefore.<p>* Creating a node with text in it? You're in for 3 different statements, and that's if you're not trying to add attributes as well<p>* Manipulating classes? Hello broken regex search&#38;replace. Oh you're targeting IE9 anyway? Well fuck you still, because Element#classList is IE10+.<p>* Playing with data-* elements? I hope you like getAttribute, because Element#dataset is MIA in MSIE.<p>* And bulk operations? What, you think querySelectorAll or getElementsByClass is going to return an array? Dream on, you <i>may</i> get something array-like in DOM4 if you're lucky. That means IE15, <i>maybe</i>.<p>Every single time I tried to get by with raw DOM, I fell back on zepto or jquery, life's too short for shit APIs and the DOM is exactly that. I don't code in raw DOM for the same reason I've stopped coding in assembly: I value my life more.<p>Now there are issues with jQuery, but these issues are generally that jQuery makes it easy to do the wrong thing (it's important to note that it <i>also</i> makes it easy to do the right thing, and improves that all the time, the "ease of doing the wrong thing" is just a side-effect of making things easier in general, the library does not specifically drive the user to the wrong thing) (except for animation maybe) e.g. keep doing noop work on empty selections, repeatedly select the same elements over and over again instead of caching the selection or not realizing you're doing a batch operation of adding a class or event on hundreds of DOM nodes in a single line.<p>The DOM itself does not fix this, it just makes these things so incredibly and obviously painful you look for other ways to do it to try and slightly alleviate the pain.<p>You get the same result out of <i>thinking</i>, and not blindly using jQuery.each and the like.<p>edits: formatting, classes manipulations, data-* attributes, matches/matchesSelector.

No, the DOM is slow. I've worked on mobile projects that didn't use a single 3rd party library, no jQuery no underscore, the most I've used is polyfills for stuff like Function.prototype.bind etc.<p>It doesn't matter. When you have a non-trivial thing to render in a list, not just a div with text content, and you start to scroll the browser stutters. Even if the list isn't particularly long (&#60; 50 items).<p>CSS animations are also rather slow in mobile browsers although this is getting better with every release.<p>I actually find it a little bothersome that so much browser development these days is focused on JavaScript performance and JavaScript alternatives whether it is Dart or asm.js or whatever... when the DOM is the primary reason lag exists.

The reason native is better for mobile apps is not that the browser's rendering engine isn't fast. It's that the browser is yet another turtle on top of an already bloated stack.<p>He argues that the developers working on these browsers are optimizing them, and that we are not intelligent enough to trump their obviously superior coding skills. Well, I'm going to disagree outright on that point. Many of us are very talented.<p>Add Webkit on top of the Dalvik VM and android SDK, and fragmented device ecosystem, and we're talking <i>major</i> disparities between the way your HTML5 app is going to run on different android devices. I have seen HTML5 apps that work great on phone a and b, but not on <i>c</i>, because well, <i>c has a different webkit version</i>!<p>It's bad enough to have to write code for different browsers. It's <i>really</i> bad to have to write code for different browsers that will run on hundreds of different android devices.<p>Back to the point you made about optimization: don't you think the developers of the native SDKs are making optimizations, too? And the lower level means we're way closer to the metal, lower on the stack, and ergo: less complex.<p>I'd use HTML5 for a trivial app, like, a business's mobile website. But for anything serious, GO NATIVE!<p>Note, my answer is for mobile browsers, specifically android. Even iOS should be marginally better on this, but really I've only seen HTML5 kicking ass on desktop browsers. I've yet to be impressed by it in mobile.

What is a good resource for understanding the DOM/query selectors and their performance (JS and CSS selectors)? All that I know about it is just through word of mouth and it would be great to look at a resource that covers these things. Also, is document.createElement('div') really much faster than $("&#60;div&#62;&#60;/div&#62;")? Just checked and a lot of well-respected JS libs use (including Backbone) use the jQuery version.<p>EDIT: typo

I find myself constantly trying to fight the urge to be lazy with JQuery, since I tend to forget the performance hit it entails.<p>For some concrete numbers, I updated a JSPerf that I found to include a raw JS implemention.<p><a href="http://jsperf.com/creating-dom-elements/8" rel="nofollow">http://jsperf.com/creating-dom-elements/8</a><p>I was caught off-guard by the results - it appears that (even after multiple runs) the raw JS implementation is ~100 times (times, not %) faster. Definitely surprised at the drastic difference, although someone please correct me if I missed something in these simple test cases.<p>This was with Chrome on Windows, by the way.

Meh. To be honest I'll take the 800ms jquery approach and get home quicker rather than using plain old javascript to shave of 600ms off a function.<p>For 99% of the projects out there, jQuery is fast enough and it's productivity boosts outweigh any performance costs.

"Sencha was able to make a version of the Facebook mobile app with their framework, and it was FASTER than the official, native app, and Sencha isn’t even particularly fast."<p>It was really laggy on Android, so no.

There are some points that I'd agree with in this post, but the framing is all wrong. The author begins the article saying that abstractions are fast (the DOM) and ends the article saying that abstractions are slow (jQuery).<p>The native vs web argument has been beaten to death. It comes down to this: there is no perfect solution and everything has trade-offs (speed, quality, and cost). Use your brain and pick the solution that works best for the problem you are trying to solve. As much as web apps have replaced many things that may have previously been implemented as native apps on the desktop, there is still native development being done.

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.<p>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.<p>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.

I was curious about the speed of jQuery selector versus querySelectorAll so I made a jsperf test. I realized people have done it already when trying to select a slug. When looking at the results, I noticed opera having a massive edge over the rest so I assumed it was doing some caching. Therefore, I created a random DOM for each test using the setup/teardown.<p><a href="http://jsperf.com/jquery-vs-queryselectorall-scragg" rel="nofollow">http://jsperf.com/jquery-vs-queryselectorall-scragg</a>

I have had similar experience. Skipping jquery and calling native DOM methods directly can be surprisingly fast.<p>Still I am curious in what the benchmarks actually say. The native DOM methods appear to return <i>before</i> rendering is done (at least in webkit). So when we get a 200ms benchmark for 10,000 divs I suspect there it is taking a longer than that to fully render.

Prediction: Since jQuery2 is dropping support for IE &#60; 9, it will never be as popular as its predecessor. We all owe John Resig a debt of gratitude for getting querySelectorAll into modern browsers.<p>The next missing piece is the ShadowDOM/Templates stuff coming down the pipeline, but sadly that will probably take just as long for mass adoption.

Hi there, I'm Kory.<p>I'm not surprised to see a large amount of disagreement and anger, partly because it threw this post together pretty quickly and i probably didn't explain things as well as i could have, and partly because, well, a lot of people really just cant write fast web apps.<p>In no particular order i would like to address a few things (most of which were addressed in the article if you read to the end..):<p>1. I never said "don't use jQuery". What I was trying to convey was "don't use jQuery stupidly". 2. I never said the DOM was the fastest part of the platform, obviously it isn't, in fact it is one of the slowest parts. But then, I wasn't comparing its speed to the rest of the platform, but rather to human perception. It doesn't matter if DOM manipulation is orders of magnitude slower than object manipulation, because it is easily fast enough to do pretty much anything, on pretty much any device, <i></i><i>if you know what you are doing</i><i></i>. 3. The fact that you read hacker news is a good sign that this post wasn't aimed at you. The post was a vent from the frustration of hearing 'The DOM is slow' as an excuse by people with no idea what they are talking about. It's a belief that is just accepted by many who have had difficulties with web development in the past, without any investigation as to what the actual issue is.<p>One think I see people doing a LOT is DOM selection. I find the pattern poor generally. Think about the standard case for developing 'web apps'.<p>1. Build objects in a server that describe the application. 2. Build a massive string from said objects. 3. Send it over the intertubes. 4. Give it to a browser, which then parses said string, fixes any errors you almost certainly made, then creates DOM elements. 5. Insert said DOM elements into the document. 6. Wait untill all of this is done, then use a tree searching algorithm to find said objects using jQuery/querySelectorAll/whatever. 7. Manipulate said object.<p>WAT. This seems a pointlessly convoluted pattern.<p>Alternative:<p>1. Build some objects on the server that describe the application. 2. Send it over the intertubes (Which will be faster, because a description of an app is going to be smaller than every little bit of it being sent) 3. Let JavaScript create DOM directly. No parsing, just pure DOM API calls. &#62;&#62;&#62;Keep a reference to important elements.&#60;&#60;&#60; 4. Insert DOM into document. 5. Work directly with the DOM elements. No selecting, no string manipulation, just normal object manipulation.<p>I look forward to the argument that ensues.

So what would be an appropriate response to "What are your thoughts on jQuery?"?

Site seems to be down. Mirror from Coral cache: <a href="http://blog.korynunn.com.nyud.net/javascript/the-dom-isnt-slow-you-are/" rel="nofollow">http://blog.korynunn.com.nyud.net/javascript/the-dom-isnt-sl...</a>

Maybe the DOM isn't, but browsers still are for more complex &#38; animated UIs. And worse of all it rally depends on the browser. I was surprised that safari is still a lot better than chrome with smooth css animations, Chrome just chokes when there are larger images: <a href="http://stackoverflow.com/questions/15323228/css-transition-in-chrome-stops-or-is-jerky-while-an-image-is-being-rendered" rel="nofollow">http://stackoverflow.com/questions/15323228/css-transition-i...</a>

It's strange you blame jQuery outright for slowness of the DOM, and reference the jsFiddle as your reference point of speed.<p>Writing this utilising jQuery for DOM manipulation ( <a href="http://jsfiddle.net/YNxEK/7/" rel="nofollow">http://jsfiddle.net/YNxEK/7/</a> ) is getting me consistently faster results than the original fiddle ( <a href="http://jsfiddle.net/YNxEK/" rel="nofollow">http://jsfiddle.net/YNxEK/</a> ) on Firefox and Chrome.

&#62;Look: <a href="http://jsfiddle.net/YNxEK/" rel="nofollow">http://jsfiddle.net/YNxEK/</a>. Ten THOUSAND divs in about 200 milliseconds.<p>You call that impressive on 2013? My laptop can <i>sort</i> a million numbers in the times you can create a mere 10k objects.<p>&#62;using JavaScript, render the whole thing in about 100 milliseconds.<p>That's not fast enough. 100ms is perceptible. Websites should render instantly, and 100ms is on top of everything else.

A simple comparison of Dom selection vs Jquery selection[1]<p>When selecting one DIV by id, I'm consistently getting:<p>DOM - 0.08ish ms<p>Jquery - 0.2ish ms<p>I do have an app where every millisecond is critical. For this app I'm using raw dom selectors. However, most of the time, the convenience of jquery selectors outweigh these performance gains.<p>[1] - <a href="http://jsfiddle.net/tolmark12/9R39R/" rel="nofollow">http://jsfiddle.net/tolmark12/9R39R/</a> (open console)

Not to be a grammar Nazi, but here are some corrections:<p><pre><code> Paragraph 1, sentence 2: Capitalize "I" in "i would say" Paragraph 2, sentence 3: Capitalize "Chrome" Paragraph 2, sentence 4: Capitalize "Firefox" Paragraph 3, sentence 1: Should be "you're" in "your coding against the Dalvik"</code></pre>

Your page IS slow: <a href="http://i.imgur.com/Avqw4L5.png?1" rel="nofollow">http://i.imgur.com/Avqw4L5.png?1</a>

FYI, browser profilers can't evaluate the efficiency of your jQuery selectors, which can be a bottleneck aswell depending on what you do. I personally use this: <a href="https://github.com/osteele/jquery-profile" rel="nofollow">https://github.com/osteele/jquery-profile</a>

This rant is just the latest incarnation of "Real Programmers don't use Pascal".

"I have use cases different from yours. You must be wrong and/or stupid."

I'm not sure what the guys attitude is, but I appreciate him pointing out those sweet JS functions that I'd been using jquery for!

I'm personally not a fan of the author's writing style; it comes across a arrogant. For a junior to mid level developer, one should be a bit more mild mannered. I poked around the resume.js file and was also taken aback by the very last line:<p><pre><code> //Yes, this is fully valid JavaScript. Run it in the Chrome Web inspector, Firebug or similar. </code></pre> Those who care to know if JS is valid already know at a quick glance. The preferred method of validation is JSHint or JSLint.

<i>HTTP Error 503. The service is unavailable.</i><p>Maybe not, but...

Let me guess. Your site isn't unavailable... I am?

The DOM isn't slow, your website is. Zing!

Worst. Writing. Style. Ever.<p>So condescending.

the web isn't down you are