5 ms·

Thanks for digging these up. His tone and his arguments are two different things; I find his tone hard to take, but can any JS coders weigh in on his arguments?

boucher 17y ago
His arguments are nonsensical. Are there bugs in jQuery? To be sure. But he has absolutely no clue what real developers are looking for in a library. Many of the complaints in his critiques center around the fact that jQuery does things which will break browsers like Netscape 4 and IE 5. Not only does jQuery not claim to support those browsers, there are literally no web developers using jQuery who care about support for those browsers.
- mmastrac 17y ago
  Exactly. I would never pretend my code would run on anything less than IE6 or any brand of ancient Netscape. I'd love to know which browsers shipping today fail on: window.blah === undefined and require the more verbose equivalent I've seen pushed on c.l.j: typeof window.blah === "undefined" There's simply no market left for this sort of paleo-Javascript.
  - timdown 17y ago
    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.
    - mmastrac 17y ago
      Sorry, that one wasn't the most effective example. 'undefined' is read-only in the ES3.1 specification and at some point you'll start to see code like the above failing. 15.1.1.3 undefined The value of undefined is undefined (see 8.1). This property has the attributes { [[Writable]]: false, [[Enumerable]]: false, [[Configurable]]: false }. It's true that it can be broken today by unintentional assignment at the global scope, but you're basically skating on thin ice as soon as you redefine undefined or one of the many built-in global object types or global mutable values anyways (Array, Element, Object, NaN for example). Ditto for adding anything to Object.prototype. I wouldn't blame a framework for wanting to place at least some burden on the user to follow a set of basic guidelines to ensure the library functions correctly. Ideally you'd ship your development-time, unminified version of the library with a bunch of startup-time assertions to ensure that the user isn't accidentally walking over core JS objects. Alternatively, you could workaround the mutable nature of some of the globals by defining your own in-scope. When these values are eventually made read-only, these assignments should become no-ops: var undefined = void 0; var NaN = 0/0; var Infinity = 1/0; This is comment is rambling a bit, but I think I can justify the position that at least some of the recommended practices of the c.l.j folk are wordy, unnecessary and out-dated.
thaumaturgy 17y ago
shrug There is some shred of validity to them. However, most JS coders are too busy using jQuery or Prototype or something to Get Their Project Done and then move on to the next thing to be bothered by this guy.
- boucher 17y ago
  It's hard to find much validity, especially when it starts to boil down to comments like "As I recall, it seemed needlessly complex." He long ago formed the opinion that all libraries were shit, and apparently made that basis on how complex the code seemed and other superficial reasons.
pmichaud 17y ago
I remember reading one of his rants from a while back, and it actually caught me off guard. I know quite a bit about javascript, but the way he was talking made me think I was perhaps missing the boat. I looked into what he was saying, and some of it was sort of accurate, but not really relevant. I think he just has angry-hyperactively-perfectionist-armchair-developer syndrome. Case in point: where is his brilliant contribution to the JavaScript ecosystem?
yannis 17y ago
One of his quotes 'Every time a new browser version is released, anything built on them has to be re-tested due to an inexplicable reliance on the user agent string'. Not really most libraries use feature testing, especially jQuery and John advocates feature testing in quite a few of his writings.
- DougBTX 17y ago
  His point is more subtle - you can do browser detection based on user agent strings, feature detect, conditional script inclusion, even css hacks which set styles that can be read from javascript. His point (such that it is) is that these are all bad ideas. Instead of detecting which browser you are using based on which features you support, the script should check to see if the features it wants to use exist, and if so use them. So, instead of: var isIE = !!document.all; function doSomething() { if (isIE) document.all.whatever(); } You do: if (document.all) { function doSomething() { document.all.whatever(); } } Even closer to the point, he means that these are both bad form: var isIE = navigator.userAgent.ssubstr...; var isIE = !!document.all;
  - thaumaturgy 17y ago
    And this is fine in theory. I agree, as I think most other Javascript programmers do now. However, I have a challenge for you: calculate the browser window's width in pixels, before the page is done loading, and return the correct value without doing any browser sniffing. Enjoy. :-)
nl 17y ago
He's a perfect example of a troll: somewhat accurate, errors in the details. To explain them requires deep engagement in the argument - exactly what the troll wants. The scary thing is that I don't think he actually is a troll. I could be wrong, though.
timdown 17y ago
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.
- boucher 17y ago
  There are so many better outlets, anyone who's feeling trapped on comp.lang.javascript should just go somewhere else. I think it's a bold claim to say that David's understanding of the DOM is "significantly deeper" than John's. Especially considering that the DOM is not a particularly complex set of APIs. One can only hope that he does actually improve Dojo, instead of destroy their community or credibility with his rants.

boucher 17y ago

His arguments are nonsensical. Are there bugs in jQuery? To be sure. But he has absolutely no clue what real developers are looking for in a library. Many of the complaints in his critiques center around the fact that jQuery does things which will break browsers like Netscape 4 and IE 5. Not only does jQuery not claim to support those browsers, there are literally no web developers using jQuery who care about support for those browsers.

mmastrac 17y ago
Exactly. I would never pretend my code would run on anything less than IE6 or any brand of ancient Netscape. I'd love to know which browsers shipping today fail on: window.blah === undefined and require the more verbose equivalent I've seen pushed on c.l.j: typeof window.blah === "undefined" There's simply no market left for this sort of paleo-Javascript.
- timdown 17y ago
  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.
  - mmastrac 17y ago
    Sorry, that one wasn't the most effective example. 'undefined' is read-only in the ES3.1 specification and at some point you'll start to see code like the above failing. 15.1.1.3 undefined The value of undefined is undefined (see 8.1). This property has the attributes { [[Writable]]: false, [[Enumerable]]: false, [[Configurable]]: false }. It's true that it can be broken today by unintentional assignment at the global scope, but you're basically skating on thin ice as soon as you redefine undefined or one of the many built-in global object types or global mutable values anyways (Array, Element, Object, NaN for example). Ditto for adding anything to Object.prototype. I wouldn't blame a framework for wanting to place at least some burden on the user to follow a set of basic guidelines to ensure the library functions correctly. Ideally you'd ship your development-time, unminified version of the library with a bunch of startup-time assertions to ensure that the user isn't accidentally walking over core JS objects. Alternatively, you could workaround the mutable nature of some of the globals by defining your own in-scope. When these values are eventually made read-only, these assignments should become no-ops: var undefined = void 0; var NaN = 0/0; var Infinity = 1/0; This is comment is rambling a bit, but I think I can justify the position that at least some of the recommended practices of the c.l.j folk are wordy, unnecessary and out-dated.

thaumaturgy 17y ago

shrug There is some shred of validity to them. However, most JS coders are too busy using jQuery or Prototype or something to Get Their Project Done and then move on to the next thing to be bothered by this guy.

boucher 17y ago
It's hard to find much validity, especially when it starts to boil down to comments like "As I recall, it seemed needlessly complex." He long ago formed the opinion that all libraries were shit, and apparently made that basis on how complex the code seemed and other superficial reasons.

pmichaud 17y ago

I remember reading one of his rants from a while back, and it actually caught me off guard. I know quite a bit about javascript, but the way he was talking made me think I was perhaps missing the boat. I looked into what he was saying, and some of it was sort of accurate, but not really relevant. I think he just has angry-hyperactively-perfectionist-armchair-developer syndrome. Case in point: where is his brilliant contribution to the JavaScript ecosystem?

yannis 17y ago

One of his quotes 'Every time a new browser version is released, anything built on them has to be re-tested due to an inexplicable reliance on the user agent string'. Not really most libraries use feature testing, especially jQuery and John advocates feature testing in quite a few of his writings.

DougBTX 17y ago
His point is more subtle - you can do browser detection based on user agent strings, feature detect, conditional script inclusion, even css hacks which set styles that can be read from javascript. His point (such that it is) is that these are all bad ideas. Instead of detecting which browser you are using based on which features you support, the script should check to see if the features it wants to use exist, and if so use them. So, instead of: var isIE = !!document.all; function doSomething() { if (isIE) document.all.whatever(); } You do: if (document.all) { function doSomething() { document.all.whatever(); } } Even closer to the point, he means that these are both bad form: var isIE = navigator.userAgent.ssubstr...; var isIE = !!document.all;
- thaumaturgy 17y ago
  And this is fine in theory. I agree, as I think most other Javascript programmers do now. However, I have a challenge for you: calculate the browser window's width in pixels, before the page is done loading, and return the correct value without doing any browser sniffing. Enjoy. :-)

nl 17y ago

He's a perfect example of a troll: somewhat accurate, errors in the details. To explain them requires deep engagement in the argument - exactly what the troll wants. The scary thing is that I don't think he actually is a troll. I could be wrong, though.

timdown 17y ago

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.

boucher 17y ago
There are so many better outlets, anyone who's feeling trapped on comp.lang.javascript should just go somewhere else. I think it's a bold claim to say that David's understanding of the DOM is "significantly deeper" than John's. Especially considering that the DOM is not a particularly complex set of APIs. One can only hope that he does actually improve Dojo, instead of destroy their community or credibility with his rants.