5 ms·
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 eve
by bengillies 14y ago
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".
That said, the following things irked me:
> Abstraction is more likely to increase speed, because someone smarter than you has written the bit that needs to be fast.
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.
> 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.
If you create an app that has half the feature set of another app it will likely be easier to make it go fast.
> 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.
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.
- michaelwww 14y agoI assumed he was talking about document.querySelectorAll in the context of selecting elements, not for additional functionality such as jQuery's fadeIn()
- bengillies 14y agoIt's the extra functionality that makes it useful though. document.querySelectorAll doesn't even support event listeners or forEach loops. I wouldn't call that extra functionality, I'd call that a basic requirement. It lets you select elements using CSS selectors. That's good and all but if you want to actually do anything with that you're better off using some sort of library that abstracts the awkwardness away (i.e. jQuery).
- jauco 14y agoI wanted to reply: document.querySelectorAll("td").map(function (elm) { console.log(elm); }) But apparently a nodelist isn't array enough to get the map function. sigh.... you could use Array.prototype.map.call(). But this really underlines the value of jQuery: in jQuery you can predict what will happen, in the DOM you can't.
- MatthewPhillips 14y agoYou can, the MDN article has an entire section on it: https://developer.mozilla.org/en-US/docs/DOM/NodeList https://developer.mozilla.org/en-US/docs/DOM/NodeList
- nilliams 14y agoYes, except as that article shows the traditional for loop somehow ends up more palatable than the awkward `forEach.call()` voodoo you have to do to use it on a NodeList, which is a pretty sad state of affairs :/ (Note: I am aware you can alleviate this with toArray type utils [1] but that does seem to be slightly besides the point). [1] http://jsfiddle.net/AhQPU/ http://jsfiddle.net/AhQPU/
- hackinthebochs 14y ago> Abstraction is more likely to increase speed, because someone smarter than you has written the bit that needs to be fast. Am I the only one that hates this meme? The idea that "someone smarter than me therefore blah blah" seems ultimately to be counter-productive. Placing arbitrary limits on yourself does nothing except prevents you from attempting certain types of "hard" problems because "someone smarter than me will/couldn't figure it out so I shouldn't bother". Perhaps its just hubris on my part but I am completely confident in my ability to fully comprehend any problem or solution that someone has come up with. There are certainly people much smarter than myself, but I will never let that limit me. Whether or not there is actually a limit to what I am capable of understanding is irrelevant, I will never assume before-hand that something is beyond my comprehension or capability.
- ewolf 14y ago"Someone smarter than you" perhaps is a bit too bold of a statement, but generally, it is true that using available code should usually be preferred over writing one's own code. It allows you to focus on your main task and spend less time implementing helper functions that someone with more time (I guess that's a better expression than "someone smarter") has already optimized.
- hackinthebochs 14y agoDon't get me wrong, I totally agree that using pre-existing code in most situations is far preferable than re-inventing things, especially when it comes to incredibly uninteresting "plumbing" code like DOM manipulation. But instead of referencing intelligence, the justification should be something like "someone already spent the time and effort optimizing something I have no interest in doing myself". Just like it has been shown that praising kids for their intelligence leads to worse outcomes, we should not be artificially limiting ourselves based on intelligence.
- LukeShu 14y agoI'd generally interpret "smarter than me" in this context as "has put more brain-cycles into this problem than I will", so with regards the that specific problem, they are "smarter".