Matt Kruse wrote:
RobG wrote:
>I understand Richard's primary complaints, I think they are:
- the use of the $ character should indicate machine-generated
code
That's a suggestion in the specs. Certainly not law.
The spec says "The dollar sign is intended for use only in mechanically
generated code", which is neither a suggestion nor an order, it is an
explanation of why a character that did not need to be included has been
included.
The _vast_ majority of people writing javascript have never seen
the specs, nor do they care that they suggest $-prefixed names be
reserved for machine-generated code.
It is not just as a prefix that the dollar symbol has that implied
meaning.
> - getElementById really doesn't need to be abbreviated
It's quite a long name, and limited in its functionality. You cannot
select multiple items with one call, for example. The purpose of $()
is not just to replace document.getElementById() but also to extend
it to be more useful.
> - the name is meaningless
I don't think so. It's short for "Selector" and $() is
better than S(), IMO.
Being short for something does not make it meaningful. It is necessary
to know what it is short for and how it is 'short' for it if it is that
much of an abbreviation. You can just about work out something like
'gEBI', but a single character really needs knowing up front.
Why would "Selector" be a name for a wrapper round - getElementById -?
Why would - $ - be a better abbreviation than 'S'? And if - $ - is to be
an abbreviation wouldn't it be better suited as an abbreviation of
'dollar', applied to a function that, say, took a numeric argument and
returned a formatted US currency string?
<snip>
>However, an issue arises here because the chosen symbol
already has a purposed suggested in the ECMAScript Language
specification.
Does that really matter?
Yes it does matter. The existing convention is a useful convention. It
allows more to be inferred from source code than is written in the
source code.
When more people understand the purpose of
$() than have even heard of the specs,
"Understand" is an interesting choice of word. How many propel have you
encountered who really understand javascript and who haven't at least
heard of ECMA 262?
But we both know the real reason that - $ - is used in Prototype.js, and
similarly in other places. It is because in some language preceding a
variable name with a dollar symbol means; 'take the value of this
variable as the name of another variable and return the value of that
other variable'. Thus - $x; - has its nearest equivalent in javascript
as - eval(x); -(at least when the value of - x - holds the name of a
variable/function/formal parameter defined in the current scope (or
maybe - window[x] - if the only significant scope for the operation is
global)). If you could do - var $ = eval; - and then call it as -
$(x); - (which you cannot as eval may throw an EvalError exception if
called in any way other than by the explicit use of its name as an
Identifier) that formulation would most closely satisfy the
'understanding' of individuals familiar only with those languages.
var $ = window; - or - var $ = this; -(in the global execution context),
used with - $[x]; - might be the other alternative, though it is
unlikely that either would fully satisfy the expectations of someone
familiar with - $x; - from other languages. (and they are the ones to
whom Prototype.js seems to have the greatest appeal).
In practice wrapping a - $ - function around - getElementById - (however
loosely) is more of a nod toward the Microsoft notion that IDed DOM
elements should be made available as properties of the global object
(effectively pre-defined global variables). That decision by Microsoft
has been widely perceived as a poor choice, and promoting to conceptual
relationship between IDed DOM elements and global variables through the
borrowing of meaning associated with the dollar symbol in other
languages does not strike me as a good idea at all.
Incidentally, it is the disregard of the provision for throwing
EvalError exceptions that makes the current version of Prototype.js
(needlessly) non-ECMAScript compliant. We can see from their disregard
for its naming conventions that the authors of Prototype.js were not
familiar with the language specification, and we know that less skilled
javascript authors don't tend to push their browser testing beyond the
most common sub-set of browsers and so don't get to see how disregarding
the specs does get in the way of creating interoperable systems. It is a
pity that this disregard for the standards is going to have a knock-on
effect for web development clients, where what they will be getting are
systems that rely upon code that should not be expected to work in any
ECMA 262 compliant environment. They will not know it is happening (why
should they as they are not web developers) and the developers foisting
such systems upon them will not know that they are doing it (as most, as
you say, neither know nor care about ECMA 262, and even could not
understand the Prototype.js code if they bothered to look). Yet those
clients will have to live with the consequences.
then I say the specs lose. Too bad.
Web standardisation has been a good thing. We have moved towards, and
are now pretty much at, a point where a single, well-defined, scripting
language can be used in all scriptable web browsers. Leaving just the
inconstancies in the browser's object models to be worked round (while
they are gradually reduced by DOM standardisation). And so it becomes
easier for us to do our jobs well.
However, it has always been even easier for people to do the web
development job badly. Witness the Netscape only, and then (mostly)
Microsoft only, web sites. Their creators needed no standards to 'earn'
their fees, and their clients probably got what they 'asked' for.
Several times over the years I have asked you to state whether you think
the client of a professional web developer has a reasonable right to
expect that developer to possess the technical skills that they are
selling. You have never answered the direct question.
Here you are arguing that because a mass or individuals follow a
particular course (whether motivated by choice, fashion, ease, perceived
familiarity or whatever else) then that course is acceptable (regardless
of its consequences).
Considering that you publish a javascript 'best practices' page (and
frequently refer others to it) isn't that a bit of an inconsistent
position? Aren't the majority of the things that would be changed by
adopting your 'best practices' precisely the things that are common
practice now (or at least in the recent past)?
The main reason it is necessary to promote some sort of notion of 'best
practices' to replace common practices is that the average technical
standard of web developers is abysmal. As javascript developers go you
are well above average, but remember that to a large mass of 'web
developers' VK (apparently) looks impressive. We all know how very bad
VK is in reality, but realistically he probably is, skills-wise,
hovering around the average as far as web developers go. The general
state of the art really is that bad. The average 'web developer' is so
technically unskilled that they could not get work as even the lowliest
of programmers in any software house.
Given that, appeals to the 'masses' (or worse, the 'lowest common
denominator') are not worth considering. In the same way as I have often
said that any 'best practice' is not a 'best practice' unless it is
accompanied by an explanation that is good enough to convince the reader
to follow the practice, a choice of naming conventions should follow
from its merits. We have a situation where a naming convention is well
known to people who understand javascript, has a context where it can be
employed and when used in that context can convey information that is
important to individuals needing to work efficiently with the resulting
system. That system is not an average web site, and the average 'web
developer' is not going to be employed to work on it, and so has no
reason to care for that convention.
The alternative is not an alternative convention for the meaning of -
$ - symbols in javascript (at least nobody has proposed such a
convention, here or elsewhere). It is the acceptance of one specific
employment of the symbol, negating the convention from the standard but
leaving the - $ - symbol to be scattered willy-nilly through javascript
Identifiers and having one meaning to one author and another to the
next, while improving the readability of nothing through its use.
Consider:-
alert(this.$.$.id);
- (no need to guess who may have written that) Is that a step towards
understandable and maintainable javascript code? Is that a price worth
paying in order to be able to infer new meaning in - $(x); -
specifically?
>So when $() is encountered in a code snippet with no other
context, which library are we to assume is in use, and what
purpose is it supposed to fulfil?
We don't know exactly. But I would say almost everyone here
knows that $('id') will get a reference to an element with
id "id", regardless of which framework has implemented the
$() function.
Is that really true, when you are arguing about code created by what you
are effectively defining as "the people who don't know any better"? Is
the result a DOM node with a particular ID attribute, or are we going to
get elements with corresponding NAME attributes, a collection of such
elements, an augmented Element, etc.? And, much more importantly, what
will be the result when the reference fails? Null (as you would always
get with getElementById), undefined, a harmless dummy Element created
with JS so that unchecked interaction with it does not throw exceptions,
and empty array, and so on? In the context of a question on c.l.js
(where questions are usually prompted by things not being quite as they
appear at first) that side of the behaviour of some arbitrary - $ -
function may be very significant, and only answerable by seeing its
definition code (and any dependencies that may have).
That's knowledge that's in the world, and
that's useful.
Believing that you know something that is not the case can be more
harmful than knowing that you don't know.
Richard.
