Live data from Hacker News

I'll sue you if you use my common-sense JavaScript tests

groups.google.com

51–60 of 82 posts

Re: I'll sue you if you use my common-sense JavaScript tests

#51

Ah yes, David Mark. This guy trashes other JavaScript frameworks (usually quite pedantically) in order to promote his own "My Library". Not a good strategy if you ask me. We were the target of a highly superficial "review" by him soon after Cappuccino was made public: http://groups.google.com/group/comp.lang.javascript/msg/1799... (for the record, YES and NO are there for compatibility with Objective-C, and we benchm…

What's even more hilarious is the code in his "My Library".

I'm far too much of a generalist to consider myself a JavaScript expert. However, even I can pick out a number of items in his lib that shouldn't have been handled the way they are:

- He declares $ in a global context without first checking for its existence;

- He uses RegExp objects constantly -- in 50 different places in his full "mylib.js" -- including in cases where a simple indexOf would be better, and, best yet, he doesn't bother to cache them in any of the dozen or so cases that I examined. Wasn't that one of his criticisms of someone else's code?

- His treatment of camelCase is truly embarrassing, relying on an ugly RegExp every time it's called. Try something like this instead:

    _camelCases = {width:'width', height:'height'};
    _camelCaser = function (p) {
        return typeof _camelCases[p] != 'undefined' ? _camelCases[p] : _camelCases[p] = p.replace(/\-(.)/g, function(x, y){return y.toUpperCase()});
    }
There, now you only need to camelCase the property for anything once. JavaScript's object handling makes caching this kind of stuff soooo easy. And, if you do have to have a camelCasing function, try to do it with as little overhead as possible -- use the tools that JavaScript gives you, instead of capturing the string parts in a match and then .join()ing them and all that other nonsense.

His library doesn't demonstrate any of the kind of specialized language knowledge that he accuses other library developers of lacking, and it has at least some of the same weaknesses that he criticizes others' works for.

Re: I'll sue you if you use my common-sense JavaScript tests

#52
I'm completely unqualified to tell whether this guy has valid points. But Resig has led the charge on a Javascript library that makes my job dramatically easier and more fun. To gain the respect I have for Resig, Mr. Mark would have to do likewise, or contribute significantly to jQuery.

Or, to put it in more childish terms, "if you're so smart, let's see you do it."

Re: I'll sue you if you use my common-sense JavaScript tests

#53
post #2

Some other gems by David Mark http://groups.google.com/group/comp.lang.javascript/browse_f... http://groups.google.com/group/comp.lang.javascript/browse_t...

"Near as I can tell, [John Resig] has never written a competent script in his life (or written anything useful on the subject.)" That's quite a brave statement from David Mark.

If Resig is incompetent, then 99.99% of Javascript coders should quit immediately. Maybe 100%.

Re: I'll sue you if you use my common-sense JavaScript tests

#54
post #46

Earlier quoted context omitted.

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?

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…

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.

Re: I'll sue you if you use my common-sense JavaScript tests

#55
His latest, on a bug report I filed against google closure: http://groups.google.com/group/comp.lang.javascript/browse_t...

I'd like to see him write cross browser key-event handling code without doing UA sniffing. Honestly, I would like that. He committed an attempt to a branch of Dojo but it's not in service and doesn't actually work.

Re: I'll sue you if you use my common-sense JavaScript tests

#58
post #41

Earlier quoted context omitted.

It's basically the same. comp.lang.lisp and Erik Naggum may've been worshipped by a non-trivial community, but it was still a small community. The rest of us still hated it. I'm sure there're people out there that enjoy comp.lang.javascript too.

And as a simple perusal of threads that David has posted in shows, he has he fair share of 'you're absolutely right David, jQuery, mootools and all the rest suck' style worshipping. For some reason (which I could make guesses at) Usenet attracts this type of kookery, and when kooks gather, they tend to create this appearance that people actually value their rants and conspiracies. As a result, you get the perceived '…

Basically every community has their heroes, people that from the outside look like cult leaders but from the inside look like wise sages. Hacker News and Paul Graham. Joel on Software and Joel Spolsky. StackOverflow and Jeff Atwood/Joel Spolsky. FictionAlley and Cassandra Claire. Haskell and Oleg Kiselyov. Google and Jeff Dean.

Their popularity outside the community seems to reflect the popularity of the community itself, which in turn reflects how much it does for the world at large and how similar its values are to the "mainstream". I'm kinda curious why such cult followings develop, but it seems to be a near-universal feature of communities of sufficient size (basically anything over Dunbar's number, where not all members know all other members). I've got a few hypotheses on this but no answers.

Re: I'll sue you if you use my common-sense JavaScript tests

#59

Ah yes, David Mark. This guy trashes other JavaScript frameworks (usually quite pedantically) in order to promote his own "My Library". Not a good strategy if you ask me. We were the target of a highly superficial "review" by him soon after Cappuccino was made public: http://groups.google.com/group/comp.lang.javascript/msg/1799... (for the record, YES and NO are there for compatibility with Objective-C, and we benchm…

What's even more hilarious is the code in his "My Library". I'm far too much of a generalist to consider myself a JavaScript expert. However, even I can pick out a number of items in his lib that shouldn't have been handled the way they are: - He declares $ in a global context without first checking for its existence; - He uses RegExp objects constantly -- in 50 different places in his full "mylib.js" -- including in…

There's a tradeoff between download time and execution speed there, and download time usually wins. I wrote the camelCaser in Google Websearch (basing it off Closure), and I used a simple regexp without memoization. You can burn a lot of cycles in the time it takes to download a hundred bytes over 56.6k, and often a camelCaser is used in situations like an animation loop where speed doesn't matter as long as you come in under the frame rate.

Re: I'll sue you if you use my common-sense JavaScript tests

#60
post #47

Earlier quoted context omitted.

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.

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.

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.

Post reply on HN