third-party libraries

[Matt Kruse]

Aren't we a few posts down stream of code showing a browser sniffing
based test that is more complex than it could have been precisely
because of the browser sniffing

It appears so, but I think we're now discussing the broader issue, not
that specific case.

It also would not be much of an argument in the face of examples of
browser sniffing code that includes and executes 500+ lines just for the
browser sniffing, and regardless of whether or not the results are ever
used.

True, such code exists, but it's also not relevant to jQuery.

Still, to date you are the only person who has mentions this "common
argument" to me. Obviously I must be not taking part in enough browser
sniffing and feature testing related debates.

A few url's:
http://ejohn.org/blog/future-proofing-javascript-libraries/
http://andrewdupont.net/2007/04/04/browser-sniffing/
http://dev.opera.com/articles/view/using-capability-detection/

How would it be "known" that the problem only existed on a single
browser? Logically haven't you got to positively verify that the problem
does not exist on _every_ other browser in existence before you can know
that?

Perhaps if you are seeking logical perfection, yes. Practically,
perfection isn't required. Of all the browsers you claim exist, I'll
bet that I haven't seen hardly any of them visit the sites I care
about. Devoting effort and thought to a fringe user who might someday
visit my site with a browser I don't know about is not something I
really care that much about.

Without that knowledge you are in the area of surmise and assumptions.

Which may be a fine area to be in.

You don't write browser sniffing code because it is imposable to write
such code so that it will accurately identify browsers or their
versions.

And yet the code that exists seems to work just fine for every single
user I've ever cared about, without exception. Believe me, I
understand your theoretical/logical argument. If you're seeking
perfect logical consistency similar to a mathematical proof, you are
absolutely correct in your arguments. But sometimes "good enough"
really _is_ "good enough". Why kill yourself trying to create an
exhaustive and bullet-proof detection algorithm that may not even be
possible? You could instead solve the case for every known user and
every probable future user of your site with some simple code, and
leave open the possibility that a rare case may exist in the future
that may make you want to reconsider your code. Or download the latest
version of your library and find that 20 others have already
investigated the problem and fixed it for you.

Remember that browser sniffing
is predicated on treating something that is not supposed to be treated
as a source of information is if it was a source of information.

Again, perhaps technically true. But in reality, it is a source of
information. And it's correct for almost every single user with the
exception of some people who purposely try to provide inaccurate
information. Personally, I don't care about those people. That's not
perfect, but it sure is practical.

How were you planning on "demonstrating" that no unknown or unrecognised
browser has the issue in question?

You can't prove it conclusively. But, for example, I often code for
apps that support only IE or maybe IE/FF. I can demonstrate well that
there are no known issues outside of my supported browser environment.
And for my case, browser detection (when required) works flawlessly,
without exception.

One of the greatest practical advantages of feature detection tests is
that if you get the test right it keeps on being the right test
regardless if whether the issue being tested for is fixed, crops up
somewhere else, or is accidentally re-introduced.

I agree. And where practical, that approach is always preferred.

Matt Kruse

 

[Richard Cornford]

It's an obvious conclusion, IMO, if you just spend time reading
the web and following the advances in the javascript world.

Isn't your opinion about how obvious your experts' opinion about Thomas'
option is, starting to look like an argument going nowhere?

Only as an alias for jQuery. Using $ as an identifier is
perfectly acceptable to everyone except standards zealots anyway.

That is not true. Generally, if a professional programmer goes to
documentation for a language (including its specification) and finds a
general convention stated, but not imposed by the grammar/syntax of the
language, they will follow that convention regardless of the fact that
they could disregard it if they wanted to. Java, for example, has the
same arbitrary attitude toward $ symbols, and you do not find
professional Java programmers disregarding it.

The use of the $ symbol as the leading character in javascript
Identifiers is exactly as Thomas has described it; symptomatic of
ignorance of the langue being used.

If you can't come up with an argument against using it other
than "a standards document

Not "a standards document" but _the_ standard document for the language.

written by someone recommended it be used for a different
purpose" then you have a weak argument, IMO.

But that is not the argument even in that case. The argument is that
disregarding a pre-existing, well known and clearly stated convention in
a programming langue is not something that a decent programmer should
ever be doing, and certainly not out of ignorance of that convention, or
to no tangible advantage.

Remember that there are over 9000 characters that can be the first
character in an ECMAScript Identifier, so picking on the only one with
pre-implied meaning is very far from necessary.

Still that is not the only argument for not using the character. There
is also the confusion (or misperception) that follows for programmers
familiar with languages where a $ character prefixing an Indenter has
its own meaning, which is never parallel in javascript, even where
mirroring that feature was the purpose of using $ in the javascript.
Much of the really bad Prototype.js code we see follows from its authors
thinking that - $('someId') - is a lightweight, natively supported
language construct, that they can use in every expression at negligible
cost (as they would in the languages they are more familiar with), when
in reality it is a call to an involved function, and precisely the sort
of thing that you would only do once per function call (at most) in
javascript, and hang onto and re-use the result you received the first
time. Where something is chosen precisely because it resembles something
else it cannot be surprising that the result is misperception, but
misperception is not something that should ever be encouraged in
computer code or its authors.

But, the question of $ has been debated endlessly as well,
and there is no need to go further.

It has been debated a bit, and neither necessity nor advantage have been
demonstrated in favour of disregarding the pre-existing convention.

It's obvious that most of the javascript
community

What is a "the javascript community"? It sounds impressive but aren't
you just talking of the weight of numbers in the mass of people whiting
javascript who flood the internet with ineptly written scripts and
mostly could not justify a single statement in their code if you asked
them to? Most of those people are not even programmers, let alone
professional programmers, and doing things that a symptomatic of
ignorance of the language is completely normal and common for them.

has no problem with it, so there's really no reason for me
to argue about it.

And certainly if you cannot do any better than a 'weight of numbers'
argument.

Richard.

 

[Matt Kruse]

That is not true. Generally, if a professional programmer goes to
documentation for a language (including its specification) and finds a
general convention stated, but not imposed by the grammar/syntax of the
language, they will follow that convention regardless of the fact that
they could disregard it if they wanted to.

This is all hypothetical.
Do you know of a single case where a developer went to the standards
to find out what $ meant and was confused by its use in a lib such as
jQuery or Prototype, etc? I can't believe such a situation has ever
existed.

The argument is that
disregarding a pre-existing, well known and clearly stated convention in
a programming langue is not something that a decent programmer should
ever be doing

Presumably because it would cause confusion. But I'm not convinced
anyone has _ever_ been confused. So how does it even matter?

Remember that there are over 9000 characters that can be the first
character in an ECMAScript Identifier, so picking on the only one with
pre-implied meaning is very far from necessary.

There is a pre-implied meaning from the standards, and also a pre-
implied meaning from previous and popular libraries and code. It is
still my suspicion that a JS developer with any experience will be
more familiar with $ as the name of an element-selector function
rather than a convention for machine-generated variable names. Usage
as the former wildly outnumbers usage as the latter, thereby making it
the de-facto standard IMO. In spite of the recommendation in the
standards _documents_.

Standards are a great thing, but by no means perfect. It's the
direction of actual developers that drive the standards. If developers
decide to ignore the $ recommendation, and do so to the extent that
the meaning of $ changes, then surely the standards will be changed to
reflect that.

It has been debated a bit, and neither necessity nor advantage have been
demonstrated in favour of disregarding the pre-existing convention.

And IMO, I've not seen a convincing argument to _not_ use it

What is a "the javascript community"? It sounds impressive but aren't
you just talking of the weight of numbers in the mass of people whiting
javascript who flood the internet with ineptly written scripts and
mostly could not justify a single statement in their code if you asked
them to?

No, I'm talking about the people who regularly research javascript
topics, discuss issues in depth, create frameworks and reusable code,
publish blogs about javascript development, give talks at Google and
Yahoo, etc. I'm not sure who you would place in a circle of experts
about javascript topics, but these are the people that I would place
there. And their opinions differ from that of yours and Thomas'.

Most of those people are not even programmers, let alone
professional programmers, and doing things that a symptomatic of
ignorance of the language is completely normal and common for them.

These are the people writing books and being hired by Google, Yahoo,
Mozilla, etc. Surely they are programmers, and surely they are very
knowledgeable about web/javascript development.

Matt Kruse

 

[Thomas 'PointedEars' Lahn]

It's an obvious conclusion, IMO, if you just spend time reading the
web and following the advances in the javascript world.

You have allowed your reasoning to be influenced, if not controlled, by
emotion, so statements like the above have to appear to you as an obvious
conclusion. As long as you continue like this, you do not deserve to be
taken seriously anymore.

But the library itself defines it, and it defines and uses more properties
that begin with `$'.

Only as an alias for jQuery. [...]

No, there is a $this variable, and an $events and a $handle property. It
turns out that I have reviewed the source; obviously you have not. (What
would your "experts" say about people who state facts about something
and are defending it even if they do not even know about it to make such
statements? Don't answer.)


PointedEars

 

[Matt Kruse]

You have allowed your reasoning to be influenced, if not controlled, by
emotion, so statements like the above have to appear to you as an obvious
conclusion. As long as you continue like this, you do not deserve to be
taken seriously anymore.

Did you take me seriously to begin with? Do I care?

But the library itself defines it, and it defines and uses more properties
that begin with `$'.

Only as an alias for jQuery. [...]

No, there is a $this variable, and an $events and a $handle property. It
turns out that I have reviewed the source; obviously you have not.

Actually, I just misunderstood what you meant.

Matt Kruse

 

[Richard Cornford]

It appears so, but I think we're now discussing the broader
issue, not that specific case.

And that specific case still illustrates that browser sniffing does not
necessarily result in less complex testing.

True, such code exists, but it's also not relevant to jQuery.

Didn't you just say that it was the broader issue that was being
discussed, not the specifics of JQuery?

A few url's:
http://ejohn.org/blog/future-proofing-javascript-libraries/

Includes the statment:-

| Additionally, in Internet Explorer, doing object detection checks
| can, sometimes, cause actual function executions to occur. For
| example:
|
| if ( elem.getAttribute ) {
| // will die in Internet Explorer
| }
|
| That line will cause problems as Internet Explorer attempts to
| execute the getAttribute function with no arguments (which is
| invalid). (The obvious solution is to use
| "typeof elem.getAttribute == 'undefined'" instead.)

At which point I stopped reading. I am hardly going to be interested in
the opinions of someone who cannot even tell what their own code is
doing and retreats into fantasy explanations as a result.

http://andrewdupont.net/2007/04/04/browser-sniffing/

Includes the statment:-

| And a line that says if (Prototype.Browser.IE) is much more
| comprehensible (and honest) than a line that says
| if (document.all && !window.opera).

But on the whole that page illustrates feature testing being superior to
browser sniffing, and the only case where it purports not to looks like
a lack of imagination on the part of the author. And it is written by
one of the authors of Prototype.js, so it completely side-steps the
possibility of designing issues out of the system, because for
Prototype.js replacing the whole thing with a better designed
alternative is unthinkable.

http://dev.opera.com/articles/view/using-capability-detection/

That page does not include a single suggestion that browser sniffing
would ever be superior to feature detection for any reason.

Perhaps if you are seeking logical perfection,

I am seeking the difference between knowing and believing.

yes. Practically, perfection isn't required.

Whether perfection is required or not is irrelevant. Your argument took
the form of; knowing this and knowing that then the other, which is a
fine form for an argument to take. If, on examination, that argument is
actually; believing this and assuming that then the other, it becomes a
much less substantial position to argue. That makes it quiet important
to understand what it takes for believing to become knowing in this
context.

Remember that you were the one making the strong statements like "the
problem is known to only exist in a single browser".

Of all the browsers you claim exist, I'll
bet that I haven't seen hardly any of them
visit the sites I care about.

How would you expect to have "seen" them? Server logs recording User
Agent headers perhaps? Hasn't it been pointed out that the vast majority
of User Agent headers are designed to be spoofing the User Agent headers
of other browsers? If IceBrowser sends a user Agent header that is
indistinguishable form that of IE how do you expect to be able to
distinguish it from IE?

Devoting effort and thought to a fringe user who might
someday visit my site with a browser I don't know about
is not something I really care that much about.

Evidently. It is not something I care about either, but that is because
I do not care about the type or version of browser that people use at
all so such a visit would require no special interest.

Which may be a fine area to be in.

Generally, not while writing computer programs, and certainly not when
it was avoidable.

And yet the code that exists seems to work just fine for
every single user I've ever cared about, without exception.

That is a pointlessly circular argument. If you define the users you
care about as the ones for whom the use of poor techniques is not a
problem then the statement is self evidently true, though not
informatively so.

But an important question in relation to what you may or may not care
about is whether that is relevant to what you do. If you only ever write
code to satisfy your own perceived needs, on your own web site, fine, it
is your choice to make. Otherwise code written is intended to achieve
something for someone else, and the question of what should and what
should not be cared about is theirs to decide, not yours.

Believe me, I understand your theoretical/logical argument.
If you're seeking perfect logical consistency similar to a
mathematical proof, you are absolutely correct in your arguments.

If I am seeking practical, robust, reliable and easily maintained
browser scripts I am also correct.

But sometimes "good enough" really _is_ "good enough".

And sometimes "good enough" is an illusion that will evaporate over
time. And sometimes when it evaporates the person left carrying the can
is not the person who walked away having delivered something that only
looked "good enough".

Why kill yourself trying to create an exhaustive and
bullet-proof detection algorithm that may not even be
possible?

Why walk away from the possibility of creating and exhaustive and
bulletproof algorithm (which, once created, will serve for its purpose
for ever) before being certain that it is impossible?

You could instead solve the case for every known
user and every probable future user of your site
with some simple code,

Where is the "instead" about it? Feature detection is not inherently
complex, and browser sniffing is not inherently simple (even while being
inherently unreliable). And it precisely in the area of accommodating
future users that browser sniffing reveals one of its major weaknesses.
'If I could ... with browser sniffing' then that would be one thing, but
it has been tried and it has become blatantly obvious that 'if not then
....' is the position we are in.

and leave open the possibility that a rare case may exist
in the future that may make you want to reconsider your
code. Or download the latest version of your library and
find that 20 others have already investigated the problem
and fixed it for you.


Again, perhaps technically true.

No "perhaps", it is technically true, has been true for the best part of
a decade, and is demonstrated to be true by all the browsers that are
never "seen" in server logs but exist regardless.

But in reality, it is a source of information.

No, it is an arbitrary sequence of characters.

And it's correct for almost every single user

It is "correct" for all users. It is not possible for an arbitrary
sequence of characters to be incorrect so long as it is a sequence of
characters.

with the exception of some people who purposely try to
provide inaccurate information.

These "people" including the authors of all those web browser you have
never "seen", because they have set up the default UA strings in the
browsers they author so that they are indistinguishable from IE's.

Personally, I don't care about those people. That's not
perfect, but it sure is practical.

Where "practical" is defined as not contradicting what you choose to
care about.

You can't prove it conclusively.

You can if you do test in every browser, but nothing short of that would
"demonstrate" anything.

But, for example, I often code for
apps that support only IE or maybe IE/FF.

So do I, for commercial web application development that is quite a
reasonable criteria as it covers all available OSs and if someone is
purchasing a web application to use then they should not have a problem
with getting a supported browser (or doing any necessary configuration
(in an appropriate security zone)). It would be very sub-standard for a
public web site or e-commerce site design.

I can demonstrate well that there are no known issues
outside of my supported browser environment.

Yes you can, because you only have at most two browser to worry about.

And for my case, browser detection (when required) works
flawlessly, without exception.

But not any more flawlessly than the alternatives, and with only two
browsers and maybe 2 or 3 versions of each to worry about, feature
testing becomes extremely simple too. Indeed, working with just IE and
Mozilla/Firefox the need to have any branching at all is reduced to
probably less than 4% of the code, and no branching means no testing at
all.

I agree. And where practical, that approach is always preferred.

But most of assertions of impracticality are actually just
manifestations of a lack of imagination or a lack of understanding on
the part of the person making the assertion. Which is why I frequently
challenge people who make such assertions to render than sufficiently
concrete that they could be tested for their veracity. To date you are
the only person who has ever risen to that challenge, and when you have
you have been shown either that a feature test is possible/practical, or
that it would be trivial to design the issue out of the system.

Anyway, to your argument. You started off saying that "knowing ..." and
"demonstrating ..." supported browser sniffing, and ended up saying that
'bereaving ...', 'assuming ..' and 'not caring about ...' justified
browser sniffing. I am not impressed with that, but not particularly
surprised.

Richard.

 

[Richard Cornford]

This is all hypothetical.

It is not hypothetical, and the section of text you failed to quote
(disingenuously falling to mark the edit again) made that point.
Professional Java programmers do not violet the convention in their
langue, though there is nothing stopping them from doing so if they
wanted to.

Do you know of a single case where a developer went to the
standards to find out what $ meant and was confused by its
use in a lib such as jQuery or Prototype, etc?

In this case I am burdened by working in the company of professional
programmers so the question will never come up.

I can't believe such a situation has ever
existed.

And you probably would not caser even if you knew that it had.

Presumably because it would cause confusion. But I'm not convinced
anyone has _ever_ been confused. So how does it even matter?

It is a matter of principle; The principle that existing conventions
should be observed.

There is a pre-implied meaning from the standards, and also
a pre-implied meaning from previous and popular libraries and code.

ECMA 262 first asserted the convention in June 1997, the prevalence of
the abuse of the $ symbol dates from nearer 2003-4.

It is still my suspicion that a JS developer with any experience
will be more familiar with $ as the name of an element-selector
function rather than a convention for machine-generated variable
names.

Being aware that other people do things badly would still not motivate a
decent programmer to join in. And the $ symbol is not uniquely used a
name for an "element-selector" (whatever that is intended to mean).

Usage as the former wildly outnumbers usage as the latter,

Only because machine generating javascript Identifiers is itself a
novelty.

thereby making it the de-facto standard IMO.

But a standard that is not observed either, so not that much of a
de-facto standard. Indeed has it not been observed here that JQuery used
$ as an alias for an object, not an element retrieval function? The only
"de-facto standard" here is that the ECMA convention is being
disregarded for no particularly god reason, beyond ignorance of its
existence on the part of individuals who are not very well versed in
javascript.

In spite of the recommendation in the
standards _documents_.

Standards are a great thing, but by no means perfect. It's
the direction of actual developers that drive the standards.
If developers decide to ignore the $ recommendation, and do
so to the extent that the meaning of $ changes, then surely
the standards will be changed to reflect that.

There may be a point where giving up in the face of pandemic ignorance
and stupidity is seen a the only option.

And IMO, I've not seen a convincing argument to _not_ use it

You should not need a reason for observing a programming conventions,
you should only need a reason for breaking one.

No, I'm talking about the people who regularly research
javascript topics, discuss issues in depth, create frameworks
and reusable code, publish blogs about javascript development,
give talks at Google and Yahoo, etc. I'm not sure who you
would place in a circle of experts about javascript topics,
but these are the people that I would place there. And their
opinions differ from that of yours and Thomas'.


These are the people writing books

The people writing books?

and being hired by Google, <snip>

LOL

Surely they are programmers,

You might hope so, but hansom is as hansom does.

and surely they are very
knowledgeable about web/javascript development.

Did you just put that in the same paragraph as "being hired by Google"?

Richard.

 

[Jeff North]

Well you might also let the people at Yahoo, Google et al know this
because they use the same terminology.

| >> | Please trim your quotes.

Post trimmed - happy now?
-- -------------------------------------------------------------
(e-mail address removed) : Remove your pants to reply
-- -------------------------------------------------------------

 

[dhtmlkitchen]

I don't know what exactly you mean by "proprietary", but check out
base2:http://code.google.com/p/base2/

Hey Matt,

I haven't looked in-depth at Base, but I've been a long time fan of
Dean's code. I will check it out. I have so many things to read these
days.

I have used CssQuery and suggested it to Selenium, where it was
implemented shortly thereafter.

One thing noticed in jQuery is the $ function. This pollutes the
global namespace and may confuse developers who might think that
jQuery is (or is related to) Prototype. (Hyundai mktg).

The $ function is overloaded in a fashion that makes it's use seem to
me, less explicit.

There are a host of other top-level symbols. I really don't like this
design:
http://docs.jquery.com/API/1.1.2/Core#.24.28_expr.2C_context_.29

I've used Dojo and would not ever want to be subjugated to this again.
I've also used YUI, and since I know a lot of the guys, I can usually
complain directly to them, however, I really dislike the inflexible
design of the Connection Manager. I stay far, far away from Prototype,
and will continue to do so, if I can.

http://www.prototypejs.org/api/utility

shows a host of non-explicitly named global symbols. plus a method:
document.getElementsByClass

Binding the method to the document COM object will create a memory
leak. Also, the implementation seems to be limited to the defaultView
of the window's document (although the way they name methods
inexplicitly, that method signature may likely lie.

Garrett

Dean's goal is to merely correct for browsers bugs/quirks and to
implement missing functionality so that you can code javascript to the
standards and have it work even in browsers that don't support the
standards. It's an interesting approach, but it doesn't offer the
convenience or simplicity of higher-level libs like jQuery.

Dean's code is sick.