timdown
timdown on Hacker News
I'm not convinced. I think not knowing that apply() and call() exist would lead to unnecessarily clunky code, but even after over a decade of using them occasionally I still sometimes have to look up which is which. My use of them tends to end up deep in library code rather than everyday functions.
The first thing I tried to do (in current Firefox) failed: select text over two paragraphs, change text colour. The selection then changes. Not a great start.
Obviously your decision to implement feature detection in jQuery was your own, but you're doing a disservice to the comp.lang.javascript regulars who laid this out for you. Describing David Mark as a troll is also unfair: I concede he has been rude to you and others, but his knowledge was and is extensive and, like it or not, was something that at the time you could learn from.
The module pattern has its place and can be used alongside prototypes, as you know, but I absolutely agree.
Why is IE < 9 support a low priority? Adding support would be pretty simple and wouldn't add much code, and IE < 9 is still used by a significant proportion of users.
You can't remove all the craziness in JSLint. The warnings about using == instead of === and not having your var statements at the top of the function, for example.
Whether the property/attribute distinction is necessary for jQuery users is one question (I strongly believe it is), but if not, the correct move would be to remove the prop() method entirely, because according to the release notes it nows seems pretty much completely pointless.
This release is a fudge, and a partial backwards step. The jQuery team seem uncertain about what the prop()/attr() change is trying to achieve (an uncertainty that probably stems from the uncertainty underlying the whole attr() method in the first place). The result is that the situation is even more confusing than ever, judging by the release notes: a list of properties for which you can only use prop() and then a recommendation that for everything else you should use attr(). Really?? Then what the hell was the point of this change? Having gone as far as acknowledging that properties are not attributes and supposedly separating how they are dealt with, they then continue to recommend using attr() even though properties are almost always what you actually want and there is now a dedicated prop() method for dealing with them? I'm now genuinely baffled as to what this change was supposed to achieve, and average jQuery users are going to be seriously confused by the messages coming from jQuery on this.
Generally not bad, but there are some errors and oversights in here:
- At the end of the "Always Use === Comparison" section, the example will throw a ReferenceError if (as is suggested) the variable `bar` has not been declared. If you're testing a variable that may not have been declared, you either need to use a `typeof` check or declare bar using `var bar;`, which will be essentially a no-op if bar exists and declares it with a value of `undefined` otherwise.
- The comments example is demonstrating unnecessary comments. The check and the call in
if (zeroAsAString === 0) {
doHeapsOfStuff(param1, param2)
}
... are self-explanatory to even the an inexperienced developer and do not require comment. What may require comment is why the code performs this check and this call.
- Your array in the "Loop Performance - Use ‘break;’ & ‘continue;’" section has one element. I know it's just an example, but it would be better as an example if it worked. You could instead use
var bigArray = new Array(1000);
- Chaining has downsides, the main one being it makes debugging much harder. You might want to mention this.
No. forEach() being native doesn't prevent it from generally being slower than a foor loop, because it still has to do a function call on every iteration.
The difference between attributes and properties is not an inane detail. It's fundamental, and if you don't understand it then you can't work reliably with the DOM, either with or without jQuery.
Bottom line: use prop().
That's quite a simplified explanation which sidesteps the issue of properties that correspond to attributes, which is where most of the confusion is going to be. And I totally disagree with your description of things like Boolean attributes/properties as "weird edge cases": their behaviour in most browsers is well-defined, consistent and not really at all weird, particularly if you limit yourself to using properties rather than attributes, which is almost always the correct approach.
Saying that it probably won't affect existing applications is just misleading. 1.6 fundamentally changes the behaviour of attr(), which is a very complicated and commonly used method. Furthermore, there's really no point in this if you're not going to encourage people to move to prop() rather than attr().
The messages coming from jQuery about this change seem very vague to me. If you're going to spring this kind of change on your users then they need to understand what it is that you've changed and why it's a good thing (I think it is, by the way), which one documented example and a hand-wavy assurance that it might probably be mostly OK doesn't do.
In the case of attr(), the convenience jQuery was adding was an enormous fudge and attempted to gloss over the fundamental difference between attributes and properties, which has directly led to vast confusion and misunderstanding among developers. It was impossible for even jQuery core developers to explain what attr() was supposed to do. The pre-1.6 attr() was a design mistake that 1.6 is attempting to rectify, which must be a good thing (provided it's been done sensibly).
For that specific case, the more verbose version is definitely better, since the undefined property of the global object can be altered. For example, this silently redefines it for the whole page:
if (undefined = someVar) {...}
The typeof check cannot be broken in this way.
The good side of David Mark: I have read plenty of his stuff on comp.lang.javascript over some time, and my own JavaScript is good enough to tell that his understanding is deep and his code intelligent and thorough. I would say his knowledge of the DOM and how to code for it is significantly deeper than John Resig's, lending weight to his criticisms. He has been working on Dojo and I am certain his input will improve it significantly.
The bad side: he consistently antagonises people, has what seems to be a personal vendetta against jQuery and declines to publish useful, constructive critiques, instead posting ill-formatted, snide rants dressed up as code reviews on comp.lang.javascript. His behaviour towards John Resig has resulted in Resig claiming to have turned his back entirely on comp.lang.javascript, which is great shame because I think there is a lot he could learn there to improve jQuery. If David Mark's attacks are turning people away from comp.lang.javascript, then that is unfortunate because he is by no means the only expert on there and others experts on there will have less of an audience for their insightful posts.