Javascript Libraries

[Randy Webb]

VK said the following on 1/10/2006 2:50 PM:

Because you cannot count on everyone else.

Then don't. If you are using a library in a page/site then it is your
obligation, as the programmer, to ensure that you do not have name
clashes. And then, you only need a list of the ones in the Libraries you
are using.

A "Global List of Global Names in Libraries" would be completely and
utterly useless though. What need do I have for a list of names that may
or may not be in Libraries that I may or may not use? None.

Even taking just Matt Kruse's Libraries, if you made a list of all of
the Global Names it uses, and then use just one of the Libraries, then
the list is useless and irrelevant.

I thought the OP's idea was to "urbi et orbi", not just sharing
experience between a group of "selected people" (I'm aside).

I don't understand Latin so I am not sure what you just said to me.

There are rather popular libraries which overload or extend host
object methods (window or document) and which have some global
variables like "isSomething".

And if you use one of those Libraries, then you would need a list of
variables in *that library only*.

It is terrible, incorrect, errorneous, false, profanic, obscene,
sacrilegious, amateurish, dilettantish, jackleg, jackass and mf b.s.

In your opinion, maybe. That doesn't make it so.

The problem remains that a lot of people are not aware of it or do not
give a tea-spoon of the substance for this matter ;-)

And you propose to save them from that? Good luck.

So rather then pretend that the problem do not exists it is better to
get a fair picture of what obstacles can be met by academically correct
libraries in the imperfect surrounding.

Just the sheer number of possibilities makes that impossible to do. But
you can start it off. When you get the first 10 million, or so, global
variable names that are about on the web, you can post a URL to your
list here.

 

[VK]

If you are using a library in a page/site then it is your
obligation, as the programmer, to ensure that you do not have name
clashes. And then, you only need a list of the ones in the Libraries you
are using.

1) Is it also my obligation to ensure that window.alert() indeed shows
alert and not a postcard? Or that for-in loop gives some expected
results? Or that attachEvent() is overloaded so actually it's now a
pointer to addEventListener?
It is *not* about predicting all possible obstacles: you cannot write
an absolutely enviroment independent program. But you may try to list
the most probable "ennemies", at least top three maybe.

A "Global List of Global Names in Libraries" would be completely and
utterly useless though. What need do I have for a list of names that may
or may not be in Libraries that I may or may not use? None.

2) That brings the point two, and it's excellently illustrated by this
yesterday post:
<http://groups.google.com/group/comp...dbd3a890b00/1ef7c4b35e964237#1ef7c4b35e964237>

Did you know the meaning of "crossobj" variable? Nor I - until I read
the post and googled for it. And for many end users this "crossobj" is
full of meaning and they probably will be glad to see a "speaking"
object name in your library.
Overall if you're making a *product* (as was spelled by OP) then
popular "folk's libraries" are a must-read and a must-study. Not to
copy the style or approach - but in these libraries people are
expressing exactly *what they think they need* and *how they think
about it* (customer behaviors).
You can call sh** on <side quote>these ignorants who don't know what do
they really need</side quote> and make everything in your {co{rre{ct
wa}y}} - But it may (or may not of course) make the market destiny of
your product much more difficult. Again - not to break the coding rules
in someone's favor. But if you can put a nice color band around your
product, why not try to do it? And "folk's libraries" may hint you of
what color customers like

I don't understand Latin so I am not sure what you just said to me.

Sorry. "for the city and for the world" - thus for whoever wants to
listen, to everyone. (see p.2 above)

<snip>
The rest is commented directly or indirectly in the points above I
guess.

And last but not least: IMHO

 

[Matt Kruse]

Even taking just Matt Kruse's Libraries, if you made a list of all of
the Global Names it uses...

Side note: When I release the new JavascriptToolbox.com, most of my
libraries will have been re-written to use closures and expose just a single
global name, or in some cases 2 or 3.

And I'm going to add this to my "Best Practices" document. When writing libs
and you don't know what other libs a user might include in their page, it's
best to try hard to avoid name collisions.

But I certainly wouldn't conclude that any library which exposes more than a
single name to the global scope is written badly.

To many programmers, writing code like this:

if (isInteger(num)) {
...
}

is just easier, cleaner, and more readble than

if (Validator.isInteger(num)) {
...
}

so I don't think that exposing global names is necessarily always a bad
thing.

 

[VK]

Side note: When I release the new JavascriptToolbox.com, most of my
libraries will have been re-written to use closures and expose just a single
global name, or in some cases 2 or 3.

And I'm going to add this to my "Best Practices" document. When writing libs
and you don't know what other libs a user might include in their page, it's
best to try hard to avoid name collisions.

But I certainly wouldn't conclude that any library which exposes more than a
single name to the global scope is written badly.

To many programmers, writing code like this:

if (isInteger(num)) {
...
}

is just easier, cleaner, and more readble than

if (Validator.isInteger(num)) {
...
}

so I don't think that exposing global names is necessarily always a bad
thing.

Of course not! My relevant post about it in this thread was exaggerated
for *irony*.

First of all there are function-shortcuts - like $() for
document.getElementById(). If one has to use com.vk.misk.$() instead of
$() then what a hell shortcut is that?

Secondly there is still in use (though obsolete)
"TwoLettersPrefix_underscore" way introduced by Dreamweaver. During the
Browser Wars "XX_functionName" was a widely accepted standard. Of
course its limitation is obvious: say MM_ can be equally used by
Macromedia, Inc. and by some say Matthew Morgan. So the risk of name
collision is still rather high - but not *so* high.

Thirdly it is simply much more difficult to work only on the levels of
your own object because of JavaScript's "incontinence of this" flaw.
Namely object methods acting like these "smart clouds" from some sci-fi
movie. On constructor call they are all glued together in one unit with
a clear "this", but right after fall apart again. This forces to
continuously watch the context and keep it somehow manually, while the
context itseld is like a piece of ice on the plate: one wrong move and
it slides away. On a big project this continuos this'ing and {curling)
is time and attention expensive. It is *not* a reason do not use it -
but it is a reason why someone *may* use something else instead.