Comment by bengillies | Hacker News Reader

Comment by bengillies | Hacker News Reader

Parent Full thread

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.

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

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

Don'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.

I'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".

I like what you're saying, but in some cases (ie. the good cases) "someone smarter than me" is a euphemism for more meticulous.

Save me from unrolling loops and implementing hash maps. I can do these things, I just do not want to.

Of course, I've seen programmers use the term "someone smarter than me" quiet literally. I'd agree with them, because what usually happens is a horrible anti-pattern.

The idea of wilful self-blinding and going, "I'm dumb and so are you! Only those 1337 guys know how to do it" pretty much fills me with rage when I hear it.

I'm not that stupid, and I'm not that smart - I can figure out pretty much anything out there given time and effort.

There's also a few other things wrong with it in this context.

Firstly, the assumption is that the "smarter" person has been focused on performance, rather than for example stability or flexibility. And more specifically, on performance for my particular use case.

Secondly, when I'm writing a native app, regardless of platform, I'm also using a set of OS libraries that have been written those "smarter" people.

And thirdly, if I'm looking to do something where speed is likely to be an issue (e.g. game development) I've got OS- (and use case-) tuned libraries, such as Cocos, that will have also been written by smarter people.

"Someone smarter than you" is perhaps a bad term. Better would be "Someone who had more time and resources dedicated to this than you do". API developers tweak for performance all the time, specifically for the sake of performance. You often can't do this in your code that uses the APIs: you've got other things to worry about. In that case, it's better to leverage the work of a dev who didn't have other things to worry about.

I assumed he was talking about document.querySelectorAll in the context of selecting elements, not for additional functionality such as jQuery's fadeIn()

It'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).

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

You can, the MDN article has an entire section on it: https://developer.mozilla.org/en-US/docs/DOM/NodeList

Yes, 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/

Reply on news.ycombinator.com