
I'll sue you if you use my common-sense JavaScript tests - Rauchg
http://groups.google.com/group/jquery-dev/msg/b8079000b547df15
======
tlrobinson
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...](http://groups.google.com/group/comp.lang.javascript/msg/17994a9a6f8f96e3)

(for the record, YES and NO are there for compatibility with Objective-C, and
we benchmarked the math functions, used in graphics routines which needed to
be highly optimized, and found a significant performance improvement, in IE if
I remember correctly, by aliasing them to eliminate the Math object property
lookups)

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

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

~~~
thaumaturgy
I don't really disagree with you, however:

\- minifying and gzipping the javascript files is considered standard practice
now, and the code I posted as-is is actually shorter than David Marks' case [*
I lied! It's not, by 100 chars. Even shortening the object references kept it
a bit longer. I don't think this defeats the rest of my points though.]. It
could further be shortened, a lot -- to the point that for all practical
purposes it's as small as a non-memoizing version.

\- I tend to use a camelCaser in much more than simple animation loops -- any
time for example that the style attributes for any element are referenced.
i.e., it qualifies as an inner-most function.

\- Although it's true that in animation loops you just have to beat the frame
rate, let's keep in mind that there are a wide variety of processors and
systems in use, and not everyone is using the latest dual-core Intel system
with 3 gigs of RAM.

As a point of personal style, I much prefer to take the shortest, fastest,
least-resource-intensive path for any given task, even if it's not strictly
necessary to do so. As an end-user, I'm disgusted beyond description with the
mindset that has become so prevalent among programmers, where efficiency is
something that should be solved in hardware. It's absolutely frustrating that
there are sites where the programmers have made so many concessions to speed
in the name of rapid development that I can't even get the site to load in a
few seconds on a 1.5 ghz G4.

So, yes, you're right, but I think the bit from David Marks' code is still
naive and still does not make best use of the language:

    
    
        camelize = function(name) {
          var m = name.match(reCamel);
          return (m)?([m[1], m[2].toUpperCase(), m[3]].join('')):name;
        };

~~~
thaumaturgy
Actually, I take some of it back!

You had a good point about total size of the code being downloaded, so I went
back and tried to see if I could shrink mine a bit without pulling any dirty
tricks -- when I realized that a chunk of his code is 'hidden' in the
reference to the regular expression object he's created elsewhere.

With that added, and matching my code style to his, my version is less than 20
characters longer than his -- and that's without doing anything sneaky.

But, maybe there just isn't a big difference in speed? So, I set up a quick
test. Again, I wanted to be fair, so I could understand what was going on. The
two tests are identical, I didn't advantage mine in any way or disadvantage
his.

The results?

Given a list of 11 valid CSS properties to "camelize", some with dashes and
some without, my code can camelize the set 20 times over in 1 to 2
milliseconds.

The non-memoizing version can camelize the set 20 times over in ... 1034 to
1212 milliseconds.

That's a significant difference, IMO.

Tested on Firefox 3.5/Mac.

...all that said, thanks for reminding me about function size and download
speed. I try to keep my own library at under 1000 source lines of code, but
there are definitely some areas where I can sacrifice a few lines to lose a
chunk of text. (Like, wrapping "typeof object != 'undefined'" into an
"undef(object)" function.)

~~~
cloverfield
You missed the point. Well, several points. My Library was written years ago
and the idea was to support "ancient" browsers like Safari 2 as well as all
future browsers. As the fairly torturous test page still works in IE8 (all
modes), Safari 4 and Chrome it would seem a rousing success. In the meantime,
jQuery has been virtually rewritten to get rid of the browser sniffing. Guess
where they got the ideas (and figure they botched their implementation).

Yes, memorizing camelized styles would be more efficient, but then the library
doesn't deal with hyphenated ones in the first place. It's used in exactly two
places and neither has anything to do with styles. Instead, it deals with
(very rarely encountered) hyphenated _attributes_ (you should have guessed, or
God forbid read the code you were criticizing).

And aren't you just picking one (tiny) bit that you can sort of relate to and
mouthing off without any real clue about what you are talking about?
<whine>And why didn't _you_ report it to the author to be constructive, build
a community, etc. What an awful jerk!</whine>

BTW, your version will blow up in Safari 2 due to the function passed to
replace. Good luck with that!

~~~
thaumaturgy
Hi, welcome to HN! I sincerely hope that you will bring a different tone here
than you do on comp.lang.javascript.

People tend to measure the "success" of their libraries or other code based
upon whether or not it accomplishes their goals. If your goal was to simply
build a set of abstractions, continue support for ancient browsers, and ensure
that it continues to work for future browsers, then you've accomplished it and
that's great.

However, you fail then to recognize the goals of other frameworks and
libraries which differ from your own. That is, they sacrifice compatibility
with very old browsers for the sake of improved performance and support for
newer browsers; or they sacrifice strict correctness for improved rates of
development; or they sacrifice other aspects of Javascript-specific techniques
for the sake of readability or establishing patterns familiar to novice
programmers.

The authors of other frameworks can no more be criticized by you for failing
to meet your goals, than we could criticize your library for failing to meet
our goals.

Indeed, you're correct that I did not read every one of your more than 9,000
lines of code (almost 330K!) for the complete library. Rather, given your
penchant for reading a few lines of some framework, critiquing them, and then
declaring them to be no longer worth your time -- I thought I'd try the same.

...Actually, I'm being needlessly rude there. The truth is, I did attempt to
review portions of code inasmuch as I had time for. Much of it was simply not
notable; I picked out the camelization for one point because I had been tuning
my own just a few nights ago.

Thanks (seriously) for pointing out the Safari 2 incompatibility. I'll
consider whether adding support for Safari 2 is worth re-working that line.
(Probably not, but maybe.)

We could continue to dicker back and forth on the relative merits of one bit
of JavaScript versus another, but I'd rather keep working on mine, other
people would rather start writing their own obvious unit tests, and you would
hopefully rather update your library or something.

~~~
cloverfield
You don't get it. See the examples I posted recently in CLJ (at the end of
that jQuery thread, for example). It does anything you can imagine, including
a jQuery-like interface if you really like bad interfaces. :) Or you can write
your own OO interface.

jQuery is _downstream_ from My Library. If you go back a couple of years in
CLJ, you'll find that I'm the one who tirelessly argued with Resig and co.
until they dumped UA sniffing. And yeah, they copy code and ideas from me to
this day. But that is _not_ why I point out the botched implementations of
those (and other) ideas. I point them out because the code is bullshit.

All of that stuff about improved development time and readability and support
for whatever browsers misses the mark (no pun intended) as well.

* The others are not more readable * The others are not more advanced (despite my Write Once, Do Nothing strategy). * The others are not more compatible (not even close) * The others do not perform better * The others do not have better support (the authors are too confused about what they are writing or copying)

The only thing the others have going for them is that they actually
(disingenuously) market their projects. I don't have the time or need to do
so.

The library is only 330K if you select _everything_ in the builder, which is
the equivalent of jQuery + 100 plug-ins. It's got easily the best Flash
module, a unique audio module, "sidebar" widgets, a CSS selector query engine,
animations (including DirectX), etc., etc. And it all works going back a
decade or so and continues to work going forward (I rarely touch it). And
contrary to the laughable comment I saw in here, it perfectly suitable for use
in the "Real World". That expression is so tired (and meaningless usually) it
is in a coma. I sometimes wonder if the people who write things like "Real
World" and "snark" actually talk like that. :)

I don't know what you mean by "simply not notable". On technical, usability
and compatibility merits, it's the most notable blob of cross-browser JS ever
published. But I never really called attention to it other than as a way for
others (e.g. Resig) to learn. When it came out, all of the frameworks were
doing crap like this:-

if (isIE6) { } else if (isSafari || isIE8) }

...and about to collapse under the weight of all of these flaky forks. You
can't maintain BS like that.

Read your history, you will get an extreme sense of Deja Vu (and perhaps a
laugh or two).

[http://groups.google.com/group/comp.lang.javascript/browse_t...](http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/415949d1bcce6e6a/03c4d326340e7f7d)

And I never said anything about Resig co-opting my "obvious unit tests".
There's a lot more than tests on that page. Nor do I have to update My Library
(that's the main point of feature testing).

Here's some more reading for you:-

[http://peter.michaux.ca/articles/feature-detection-state-
of-...](http://peter.michaux.ca/articles/feature-detection-state-of-the-art-
browser-scripting)

<http://thinkweb2.com/projects/prototype/>

Seriously, you just might learn something. This is why I speak loudly (and
carry a big script). :) Otherwise, all of you "hackers" might have remained
oblivious to the fact that jQuery, Prototype, MooTools, etc. are Z-grade
scripts at best. It's not always a poor use of the language, but more often a
poor grasp of cross-browser scripting techniques, which leads to endless Beta
tests, wholesale substitutions, etc. It's a relatively hard way to go, despite
what the commercials (blog posts) tell you. ;)

------
Rauchg
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_frm/thread/3d90e8b8a8301462?pli=1)

[http://groups.google.com/group/comp.lang.javascript/browse_t...](http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/2232c2e46e200cde/)

~~~
nzmsv
Wow! After reading these, and the replies, I definitely agree with John Resig
about that newsgroup: don't read. Or risk losing your hope for humanity.

~~~
ubernostrum
And yet I can't help drawing a parallel: comp.lang.lisp was famously full of
the hateful spewing of an intolerant contributor, and for that both the group
and the contributor (Erik Naggum) were basically worshipped by a non-trivial
community. Why did Lisp produce that outcome, while JavaScript produces this?

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

~~~
NikkiA
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 'Erik is god' views of comp.lang.lisp,
whereas people that try to read, or contribute, consider(ed) him and his ilk
as a deterrent to useful discussion.

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

------
stephenjudkins
Everything I've read by this guy is more or less the same bilious, angry
screed. His monomaniacal obsession with John Resig is a little alarming.

Therefore, I'm sad to admit that, in this case, he almost has a point. The use
of attr('height') to mean not the height attribute in the DOM but as an alias
for height() smells wrong to me. However, it's clear that he has absolutely no
intention of becoming a productive contributor to jQuery or helping in any
way.

By contrast, let's take a minute to appreciate this Matt Kruse fellow. He has
apparently strong objections to something in jQuery's design and is taking it
to John Resig. He seems ready to engage in a real dialogue. The end result? He
probably ends up a little happier and jQuery ends up a little better.

The real question is: how can we have more Matt Kruses and fewer David Marks
in the world? Do the David Marks of world drive off the Matt Kruses? (I think
they almost certainly do.) Why are there so many sociopathic personalities in
circles such as this, and how do we mitigate the damage they cause?

~~~
kroo
In my experience perhaps the only way of dealing with characters like David
Marks is by completely ignoring their contributions.

He does, I agree, almost have a point. However, his lack of respect for those
who spend time and energy contributing to these projects could (and will
likely) drive away many useful contributors. "Feeding the trolls" is a
dangerous game, much more so than avoiding the advice of a few David Marks.

The problem with this strategy lies in the fact that most open-source projects
are large, open communities, where experts in a particular area useful to that
project are likely not to be ignored. John Resig's response to the situation
(in which he condemns the entire comp.lang.javascript usenet group) seems an
extreme (but perhaps appropriate) response to this -- he's sending a very
strong message to those who contribute to jQuery: "no more feeding David
Mark".

(I would also agree that this Matt Kruse fellow seems to be going about things
in an excellent sort of way. His response to Resig <
[http://groups.google.com/group/jquery-
dev/msg/e93f9484cd5246...](http://groups.google.com/group/jquery-
dev/msg/e93f9484cd524625) > was, in my opinion, spot on)

------
julio_the_squid
David Mark is an anti-jQuery crusader. He is known for speaking ill of people
who use the library as well as the developers (John Resig in particular). He
insists that jQuery is responsible for all of the sites across the internet
that have JavaScript errors.

See
[http://www.reddit.com/r/programming/comments/7vul9/some_tech...](http://www.reddit.com/r/programming/comments/7vul9/some_technical_criticism_of_jquery_code/)
[http://www.reddit.com/r/programming/comments/8ndyw/jquerys_l...](http://www.reddit.com/r/programming/comments/8ndyw/jquerys_latest_stab_at_competence/)

~~~
tibbon
What I don't understand is why he doesn't work to help jQuery to be better
then and contribute a bit? If its causing errors and bugs then certainly he
could help some instead of complaining?

Resig +1 Mark -1

~~~
chrischen
Ego?

------
yesimahuman
Another reason not to participate in comp.lang.javascript: Thomas
'PointedEars' Lahn.

~~~
boucher
You are absolutely right.

------
babyboy808
Seems like this David Mark is mad at the world:

[http://sixrevisions.com/javascript/promising_javascript_fram...](http://sixrevisions.com/javascript/promising_javascript_frameworks#comment-22465)

[http://sixrevisions.com/javascript/promising_javascript_fram...](http://sixrevisions.com/javascript/promising_javascript_frameworks#comment-24056)

<http://stackoverflow.com/users/88658/david-mark>

[http://help.wugnet.com/bravenet/webmaster/Great-Examples-
cod...](http://help.wugnet.com/bravenet/webmaster/Great-Examples-code-
ftopict33846.html)

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

------
furtivefelon
I think this is "his" javascript library (can't find his name mentioned
anywhere though): <http://www.cinsoft.net/mylib.html>

~~~
chrischen
It was in his stackoverflow profile right? So I guess it's a safe bet that
it's his. Plus the description sounds like him.

~~~
ErrantX
It is.

It's not all that usable ITRW.

------
compay
The worst kind of trolls are the ones that are knowledgeable and articulate,
but arrogant, dogmatic crusaders.

Many programming mailing lists I've been on ended up acquiring somebody like
this, at which point I usually have to unsubscribe in order to resist the
temptation to get into pointless flamewars.

~~~
pg
Actually, the worst trolls are the ones that are knowledgeable and articulate,
but are more dedicated to trolling than to any particular beliefs. Dogmatic
trolls are at least somewhat constrained by their dogmas.

------
chrischen
He (David Mark) isn't going to get much support with his attitude.

~~~
overgard
I wish that were the case, but often it seems being controversial is a more
direct path to popularity than thoughtfulness is.

~~~
thaumaturgy
He is not more popular than jQuery, however. (Or Resig for that matter.)

...Not that this should be reduced to a popularity contest.

------
kprobst
Hmmm. There used to be a "David Mark" back in the day that trolled the
Microsoft VB newsgroups when they were very active. Trolled hard. This guy's
demeanor seems very similar.

------
mpk
I actually had to go and google the person in question. After about five or so
newsgroup messages from him badmouthing other people I gave up.

Still no idea who he is.

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

------
sh1mmer
There is always some guy, I've never heard of, being an asshole on any given
topic on the Internet. I'm sorry that he's picking on John/jQuery but it's
really not that surprising.

I think John is being pretty pragmatic though just to exorcise the whole deal
and attempt to enforce a clean room environment for the affected code
branches.

------
boucher
His latest, on a bug report I filed against google closure:
[http://groups.google.com/group/comp.lang.javascript/browse_t...](http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/44bb4805cc4d9cf8)

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.

~~~
cloverfield
And you don't know what you are talking about either. To save time, responses
are aggregated here:-

[http://groups.google.com/group/comp.lang.javascript/browse_t...](http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/f829f23962c72d35#)

~~~
boucher
His response is typical. He denies saying things which can easily be
disproved. He makes basic factual errors and in the same sentence validates
most of the criticism in this thread:

"Cappuccino. That's something built on top of Sproutcore, right? No need to
get any deeper than that."

Of course, Cappuccino isn't built on Sproutcore, but even if it was this
sentence illustrates the fact that David has long ago made decisions about
what he perceives to be the state of javascript frameworks, and isn't
interested in anything other than those opinions, however baseless those
opinions may be.

~~~
thaumaturgy
"cloverfield" is David Mark, FYI -- it seems someone went and pointed him
here.

I noticed in several parts in his response, he's trying to claim credit for
aspects of jQuery's development -- something that I think most people would
find patently ridiculous. Given David's recent threats, if I were Resig, I'd
be tempted to start using the word "defamation" and tell David to put up some
evidence or shut up.

Fortunately, I'm sure Resig's more level-headed.

------
Sensible
It would be useful that instead of praising one person and denegrating
another, supporters of jquery, capucinno et al addressed each of the many
concerns that have been raised about those libraries in a manner that can be
objectively evaluate.

~~~
boucher
It's difficult to have a rational discussion with someone who has already
staked out an extreme position and offered little to no evidence to support
that opinion.

Also, it's spelled Cappuccino. And since David's superficial review contained
virtually nothing of substance, there isn't much to objectively respond to.

Example:

    
    
               <script src = "Frameworks/Objective-J/ObjectiveJ.js" type = "text/javascript"></script>
    
         > Nice markup. 
    

Yes, one file in 280 Slides (not Cappuccino) has spaces between the attribute,
equals sign, and quote. We must be incompetent.

    
    
        > Yeah, I guess "false" is harder on the fingers. 
    

Or, maybe, we're going for an easier transition for people from an Objective-C
background...

    
    
        with (new prototype_bug()) 
            member = true; 
    
        > Ugh. 
    

How insightful. Hilariously enough, this is actually doing real feature
detection to detect a real bug in real browsers.

    
    
        > I've seen enough.
    

So, in other words, he made no substantive evaluation. If you ask us
questions, and aren't a dick about it, we're more than happy to give answers.
We readily admit our own faults, and we're vocal about what our framework is
_not_ designed to do.

~~~
Sensible
Your post reads like an attack on a person rather than anything else. I've
read tons of posts by David Mark and I've found little wrong with them
technically so describe his position as extreme does not mean he is
automatically wrong on everything.

Why pull things out of context and not provide a reference to the original?

You complain about the tone of his posts (someone called it snarky) and then
go on to post your own snarky comments, why?

~~~
boucher
The original was referenced above, an additional reference didn't seem
necessary. I don't believe the quotes are out of context, that was the
majority of his post. Just so you don't have to search for it, here is the
link:
[http://groups.google.com/group/comp.lang.javascript/msg/1799...](http://groups.google.com/group/comp.lang.javascript/msg/17994a9a6f8f96e3)

~~~
Sensible
I put mootools and jquery through jslint.com and jslint found so many things
it didn't like that I wonder if the cristicism is indeed valid. Will you now
publicly lambast Douglas Crockford for daring to indirectly criticise these
so-called frameworks?

~~~
boucher
Doug readily admits that JSLint is opinionated. For example, it considers
omitting a curly brace on a single line conditional to be an error. It
considers fall through switch statements an error. It even considers differing
opinions on whitespace to be an error.

It's absolutely fine to have an automated tool to enforce style guidelines.
But code which disagrees with that tool isn't necessarily bad. We have
published style guidelines for our project, and they differ from Doug's. Those
projects may very well have their own published guidelines.

Doug has never said that code which fails JSLint is obviously retarded, or
written by fools. He's never publicly insulted individuals because he didn't
agree with their design decisions, or written mailing list posts saying
someone has "never written a competent script in his life."

So, what's your point?

~~~
Sensible
You can easily dismiss the numerous non-style related errors that JSLint finds
because of the claim that JSLint "opinionated". And you can dismiss the
numerous non-style related errors that one finds because you can claim a flaw
in poster's personality.

The point being that I'm tired of reading responses that only focus on an
insulting comment a poster makes in order to dismiss all valid technical
criticism.

~~~
boucher
Then why not stop including insults with your technical criticisms?

If you include insults, purely stylistic criticism, and valid technical
criticism all in an orgy of excited and angry words, people aren't going to
take the time to dissect the actually interesting bits.

And, let's not forget, you're the one who claimed that jQuery and Prototype
fail horribly on JSLint without providing any information on the actual
errors, so the burden to prove they are not just style errors is still on you.

------
jorsh
Here is the actual David Mark post in question:
[http://groups.google.com/group/comp.lang.javascript/msg/071f...](http://groups.google.com/group/comp.lang.javascript/msg/071fb5f5c6c6fe90?dmode=source&output=gplain)

------
jorsh
Dude has some decent points but has the chronic usenet disease of not being
able to put them forth in any manner even approaching tact or class.

------
TNO
Why is this even being posted to HN? Is it buzzword compliant or something?

