JS strangeness

[Jorge]

... could program JS with an Oscilloscope and a
soldering iron if they really tried.

...and what's wrong with that ?

--Jorge.

 

[Henry]

On Jul 28, 4:01 pm, Aaron Gray wrote:

There's another library I have came accross that seems to do the
same as jQuery but seems alot lighterweight and have not heard it
mentioned on clj.

       http://www.domassistant.com/

Have not used it, but it has four figure version numbers and is
up to 2.7.1.1 so it _may_ be a good library.

<snip>

When reviewing John Resig's "Pro JavaScript Techniques" Robert Nyman,
the original author of DOMAssistant, wrote; "I would say that any
JavaScript web developer out there, from intermediate to advanced, can
learn something sincerely valuable from this book.". To read that book
and come to that conclusion does not bode well. It implies he uses a
definition of "advanced" "JavaScript web developer" that does not
involve the possession of the technical understanding that would
result in the reader seeing the many faults and nonsenses in the book
and so dismissing it out of hand as a learning source.

 

[Aaron Gray]

<snip>

When reviewing John Resig's "Pro JavaScript Techniques" Robert Nyman,
the original author of DOMAssistant, wrote; "I would say that any
JavaScript web developer out there, from intermediate to advanced, can
learn something sincerely valuable from this book.". To read that book
and come to that conclusion does not bode well. It implies he uses a

Oh, dear, oh, dear, oh, dear, this does not bode well, your right.

Or maybe he was just glosing over the errors and taking the good bits, some
people are like that and prefer not to emphasize the bad ?

Oh, well I have John's book on order so will see for myself. Just started
reading "Javsscript: The good parts" for some sanity.

Have you used/looked at DOMAssistant at all, has it been used in any medium
scale or large projects at all ?

Regards,

Aaron

 

[Tim Streater]

...and what's wrong with that ?

Personally I use a bar magnet and a magnifying glass. Saves amazing
amounts of CPU.

 

[Thomas 'PointedEars' Lahn]

When reviewing John Resig's "Pro JavaScript Techniques" Robert Nyman,
the original author of DOMAssistant, wrote; "I would say that any
JavaScript web developer out there, from intermediate to advanced, can
learn something sincerely valuable from this book.". To read that book
and come to that conclusion does not bode well. [...]

Well, there is certainly one valuable thing that can be learned from this
book: how not to write one ;-)


PointedEars

 

[Dr J R Stockton]

In comp.lang.javascript message <b7423ee2-9d42-4c73-9fc0-ab95455179d2@m3
g2000hsc.googlegroups.com>, Sun, 27 Jul 2008 12:18:24, Pink Pig

[...] But often, Firebug reports that the variable 'calimg' is not

PointedEars
--

This is really not a helpful response. You might at least point me to
the appropriate section of this massive document.

if you had prudently read the newsgroup before posting, you would have
known what to expect from Lahn.

 

[Gregor Kofler]

Aaron Gray meinte:

There's another library I have came accross that seems to do the same as
jQuery but seems alot lighterweight and have not heard it mentioned on clj.

http://www.domassistant.com/

Have not used it, but it has four figure version numbers and is up to
2.7.1.1 so it _may_ be a good library.

Dunno...

line 6:
var isIE = /*@cc_on!@*/false;

line 1330:
if (/KHTML|WebKit|iCab/i.test(navigator.userAgent)) {
DOMLoadTimer = setInterval(function () {
if (/loaded|complete/i.test(document.readyState)) {
DOMHasLoaded();
clearInterval(DOMLoadTimer);
}
}, 10);
}


And why would one want to do something like that:

window.addEvent = this.addEvent;
window.removeEvent = this.removeEvent;


Gregor

 

[Jorge]

Personally I use a bar magnet and a magnifying glass. Saves amazing
amounts of CPU.

Oh, yes, the magnifying glass changed my life. But what's the magnet
for ?

--Jorge.

 

[Hamish Campbell]

Personally I use a bar magnet and a magnifying glass. Saves amazing
amounts of CPU.

Hehe. Yeah, my point was that there are serious experts in this forum,
but few programmers - even good ones - have the time/inclination/
ability to delve into the inner workings of JS (and even fewer get to
the point where they seem to be able to quote the spec at will!).

And hey, an accessible library like jQuery is [hopefully] a good entry
point for someone who will later learn *ahem* real JS.

Meanwhile, I'm fixing basic PHP/SQL injection issues because there are
plenty of php hobbyists who refuse to use frameworks because they
don't understand how they work (so they must be bad). It's basically
the reverse scenario - except that as far as I can see, it is better
to have someone bumbling around within a fixed set of functionality
than to be let loose to create havok in ways they don't understand.

return 'bye';

 

[David Mark]

Personally I use a bar magnet and a magnifying glass. Saves amazing
amounts of CPU.

Hehe. Yeah, my point was that there are serious experts in this forum,
but few programmers - even good ones - have the time/inclination/
ability to delve into the inner workings of JS (and even fewer get to
the point where they seem to be able to quote the spec at will!).

And hey, an accessible library like jQuery is [hopefully] a good entry
point for someone who will later learn *ahem* real JS.

That's what you fail to understand. It isn't. There is no argument
for it. Search the group. Thanks.

 

[RobG]

Aaron Gray meinte:


Dunno...

line 6:
var isIE = /*@cc_on!@*/false;

I guess it does that because shortly afterward it does:

var pushAll = function (set1, set2) {
for (var j=0, jL=set2.length; j<jL; j++) {
set1.push(set2[j]);
}
return set1;
};
if (isIE) {
pushAll = function (set1, set2) {
if (set2.slice) {
return set1.concat(set2);
}
for (var i=0, iL=set2.length; i<iL; i++) {
set1[set1.length] = set2;
}
return set1;
};
}

[...]

And why would one want to do something like that:

Because the author(s) do no know how to implement effective feature
detection?

How about:

var HTMLArray = function () {
// Constructor
};

....

if (isIE) {
HTMLArray = Array;
}
HTMLArray.prototype = [];
HTMLArray.prototype.each = function (functionCall) {


Which extends Array.prototype in IE with an each method, but in other
browsers extends a generic array object.

 

[Richard Cornford]

Hey Pink,

The jQuery google group is excellent:
http://groups.google.com/group/jquery-en

The JQuery group responded to the OP's question by pointing out that the
information provided was insufficient for an answer to be given
(particularly asking to see the code). Pretty much the same reaction to
the question as received here (and unsurprising as there is a minimum of
information required in any meaningful analysis).

In the end it turned out that my suspicion that the information provided
was inaccurate at least in part, due to the contradiction between the
description of the code and the symptoms, was well founded. The issue
was caused by arbitrary character sequences being written into the
javascript source code for a string literal without appropriate
escaping. A common novice mistake that easily goes unnoticed up until
the point where someone/something introduces a character that is
forbidden or problematic in a string literal, like apostrophes
(problematic) or line terminators (forbidden).

That meant that the "run it locally under Firefox, everything works
fine" was pure misdirection, as given the same data it would have failed
as reliably locally as it failed "on the host site".

Plenty of people there (including myself) willing to
help out.

Willingness does not necessitate ability. What I don't see on the JQuery
group is any depth of expiation, or any push to enable other posters to
become better javascript programmers. It appears that everything is
geared towards getting things 'working' in some sense, with no
consideration of how stupidly coded that 'working' outcome may be. Is
that a limitation in the ability of the participants, or a desire to
keep JQuery users as 'in the dark' as possible about javascript?

There are plenty of people here who are willing to help, but the help
offered anywhere may often not be something that the person asking for
help would be happy to hear.

Try to post a link to a sample site if
possible.

You see, even you think the OP has to expose the code before an answer
can be proffered.

Unfortunately this group can be a little.. old school.

"Old school"? What can you mean by that? Are you suggesting that there
are practices and ideas in javascript programming/browser scripting that
have been superseded by more recent developments and we ("the group")
are steadfastly using and promoting them despite the tide of progress?

So are we talking about ideas such as those relating to handling browser
differences. Where the oldest idea was User Agent string based browser
sniffing (which pre-dates javascript), followed by the more potentially
more effective strategy of object inference browser sniffing (which was
very rarely implemented to get anywhere near reaching its potential),
and eventually the more rationally justified feature detection strategy.
And all of this in the dying years of the last century.

All of the proposed alternatives are old, but if any is to be regarded
as "old school" it should have to be one of the first two. But here it
is feature detection (the most modern of those strategies) that is
promoted, and UA string sniffing is ridiculed for its lack of any
technical foundation and demonstrable inability to make the required
discriminations. While in contrast it is in libraries like JQuery that
you find heavy reliance on UA string based browser sniffing and the
people promoting the strategy are the authors of those libraries.

Language use has changed over time, in terms of style. Go back to 2001
and pretty much all large-ish scale javascript design was relentlessly
OO style aping Java. While the passage of time has seen things develop
towards exploiting the functional programming aspects of javascript.

Consider the understanding of closures as an aspect of that trend. At
the turn of the century very few javascript programmers had any idea
what a closure was (at least partly as a consequence of their having
zero coverage in books of the day) and little use for them. These days
anyone who intends putting themselves forward as an expert on javascript
is going to be expected to have a good handle on closures, and the run
of the mill programmers are expected to have a working familiarity. That
trend started right here on this group. You would be hard pressed to
find a single regular participant in this group (with the obvious
exception of VK) in the middle of 2004 who was not fully familiar with
the theory, mechanism and practical applications of closures.

Similarly the "Module Pattern" (and generally the use of inline calls to
function expressions to provided a pseudo-private scope) that came as
such a new idea to so many in mid 2007 when the famous YUI blog was
first published is old enough to be regarded as "old school". It was
first published, on this group, in April-May 2003 (various examples from
function expression calls motivated by private scooping to recognisable
"module pattern" implementations). And it was participants in this group
who first took up the idea, developed and discussed it, teased out its
permutations and identified its appropriate uses, with sufficient rigor
and enthusiasm that the whole subject was played out here by the end of
2004.

So it is "old school" to be in at the point other people's new ideas of
the last couple of years really were genuinely new ides? To be, what
appears to be, 3 or 4 years ahead of the game?

And given 3 or 4 years head start to spend debating the issues do you
really think that the reasoning behind the "hatred" of these libraries
is not well thought out? After all, the idea of large-scale
general-purpose javascript/DOM libraries is hardly anything like a new
ides. When I started writing javascript back in 2001 libraries such as
'overlib' and (I think it was called something like) 'x-lib' had the
mass popularity. Maybe not to the level of current libraries, but that
is partly because the demand for javascript on the web was nothing like
what it is today (and I don't think anyone even considered marketing
them, and certainly not having t-shirts printed). Consider how critical
and argumentative this group is; is it credible that poor reasoning
about such an old idea would not have been torn apart by now in such an
environment?

I'm pretty sure that PointedEars et. al. could
program JS with an Oscilloscope and a soldering iron
if they really tried. Unfortunately that sword has cut
both ways and they're all but blind to the benefits
that jQuery (and the other hated libraries) bring
to real world developers.

Is that true? Do you imagine that nobody has ever attempted to enumerate
the supposed benefits of those "hated" libraries here? Granted, mostly
when you ask a 'supporter' of these libraries to enumerate the benefits
they offer, no list is forthcoming. Which always suggests to me that the
"benefits ... to real world developers" arguments are the
comprehensionless parroting of someone else's propaganda. And when the
response is 'they are too obvious to mention' I know full well that I am
not listening to reasoned argument (whenever something is really that
obvious it is also easy to justify/explain/enumerate).

When it comes down to it, the things that really are of benefit in these
things are not exclusive to these things, or maximised by these things.
A good few years of discussing these subjects suggests that all of the
benefits are achievable in other code authoring strategies, and that
some of those alternative strategies can significantly mitigate the
drawbacks of the "hated" libraries.

It may be the case that the debate of alternatives has not yet
crystallised into any formal strategies, and so code written by
participants in the debate still varies considerably in style and
structure, but still the direction chosen is away form the "hated"
libraries.

And of course some of the things put forward as benefits of these
libraries actually turn out to be drawbacks when critically examined.

It may be inevitable that most people will not appreciate being told
that they have taken a totally wrong direction, but that is not a good
reason for not telling them. And mostly when it comes to taking advice
about which path to take it is a good idea to get the advice from
someone familiar with the whole journey.

Richard.

 

[Thomas 'PointedEars' Lahn]

^
There is something wrong with your NetNews user agent. The last `1' in
`11:41' is _not_ followed by an unknown character.

Hehe. Yeah, my point was that there are serious experts in this forum,
but few programmers - even good ones - have the time/inclination/
ability to delve into the inner workings of JS (and even fewer get to
the point where they seem to be able to quote the spec at will!).

Those who do not even attempt to evaluate code they are using before they
are using it, who use code they do not understand in the first place, do not
deserve to be called programmers. They are only script-kiddies.

And hey, an accessible library like jQuery is [hopefully] a good entry
point for someone who will later learn *ahem* real JS.

1. jQuery is the exact opposite of accessible.

2. How could code lead to a greater understanding about a programming
language when one does not even bother about the possibility that it
could be bad?

Meanwhile, I'm fixing basic PHP/SQL injection issues because there are
plenty of php hobbyists who refuse to use frameworks because they
don't understand how they work (so they must be bad). It's basically
the reverse scenario - except that as far as I can see, it is better
to have someone bumbling around within a fixed set of functionality
than to be let loose to create havok in ways they don't understand.

You miss the point. The problem with jQuery is certainly not that the
people criticizing it here do not understand how it works. Instead they
understand how it works (or rather does not work) all too well, obviously
better than its author, as in contrast they are not only not lacking the
minimum clue but also have much a larger record of (professional) experience
than its author. As it is often the case with so-called frameworks or
(all-in-one) libraries, heavily marketed as the Second Coming of programming
and therefore easily fallen for by those new to the programming language
(who are by definition in no position to assess their quality properly).

return 'bye';

SyntaxError: return not in function.

Please do not remove the attribution line for the precursor; especially,
you should retain all attribution lines for quotations you include.


PointedEars

 

[Hamish Campbell]

The thing is, Richard & Thomas, jQuery saves me hours and my clients $$
$ and none of my users has ever complained (or, for that matter,
noticed).

I *can* write any of the jQuery functionality by hand if I need to -
but why would I?

 

[Andrew Poulos]

The thing is, Richard & Thomas, jQuery saves me hours and my clients $$
$ and none of my users has ever complained (or, for that matter,
noticed).

I *can* write any of the jQuery functionality by hand if I need to -
but why would I?

Generally, to ignore what Richard, Thomas et al say on javascript
matters is a bit like driving without wearing a seat belt.

Andrew Poulos

 

[Jorge]

Generally, to ignore what Richard, Thomas et al say on javascript
matters is a bit like driving without wearing a seat belt.

But you can't argue that "jQuery saves me hours and my clients $$$".
(And increased margins and productivity too).
Nor that "none of my users has ever complained (or, for that matter,
noticed)", as that's something that only he knows.

As to "Why would I (write my own library) ?", many people wouldn't
even think about it. Libraries as tools, are ok as long as they get
their jobs done. At least for the people whose interest is not in
building tools, or in JavaScriptology. And that's allright (for them).

--Jorge.

 

[Erwin Moller]

Hamish Campbell schreef:

Personally I use a bar magnet and a magnifying glass. Saves amazing
amounts of CPU.

Hehe. Yeah, my point was that there are serious experts in this forum,
but few programmers - even good ones - have the time/inclination/
ability to delve into the inner workings of JS (and even fewer get to
the point where they seem to be able to quote the spec at will!).

And hey, an accessible library like jQuery is [hopefully] a good entry
point for someone who will later learn *ahem* real JS.

Hamish,

It works the other way around.
If you want to learn something, you must start learning that something.
Make mistakes, and learn. Get good documentation and read it.
I don't think people will learn JavaScript very well by using JQuery.
They will learn how to use JQuery instead.
JQuery != Javascript.

Meanwhile, I'm fixing basic PHP/SQL injection issues because there are
plenty of php hobbyists who refuse to use frameworks because they
don't understand how they work (so they must be bad). It's basically
the reverse scenario - except that as far as I can see, it is better
to have someone bumbling around within a fixed set of functionality
than to be let loose to create havok in ways they don't understand.

I totally disagree.
Using a framework is a bad start to learn a new language.
You want to learn PHP? Learn PHP, get SQL-injected all the way if you
don't do it right from the start. That is not a bad thing, but a good thing.
That is the way real programmers are made, by making mistakes and learn
from it. NOT by babysitting and nursing them up in a framework, but by
understanding the language, the securityissue at hand, etc.
The REAL stuff.

Your way of 'learning' leads to wannabees that know how to use a certain
framework.
Their sense of security is lowered by using a framework, since they
never learn about the underlying problems.

AFTER you know how to program and use a certain language, you can MAYBE
have a look at a framework that helps you avoid braindead work.
Most will roll-their-own frameworks by then, or at least pick a
framework they understand.

return 'bye';

echo 'Regards,\nErwin Moller';

 

[Jorge]

If you want to learn something, you must start learning that something.
Make mistakes, and learn. Get good documentation and read it.
I don't think people will learn JavaScript very well by using JQuery.
They will learn how to use JQuery instead.
JQuery != Javascript.

There are many reasons for choosing to use a library:
You may not care less about JavaScriptology, about JavaScript itself,
about object models, about inheritance, about closures, about the DOM,
about etc.
You may just want (or need) to build a web page asap.
You may even care less about the web page itself than about its
contents.
You may not want to deal with cross-browser compatibility issues (I'm
one of those).
You may want to have to learn just one api (any api) that works (and
don't care about how it works).

Have you ever used a C library ?

--Jorge.

 

[Jorge]

If you want to learn something, you must start learning that something.
Make mistakes, and learn. Get good documentation and read it.
I don't think people will learn JavaScript very well by using JQuery.
They will learn how to use JQuery instead.
JQuery != Javascript.

There are many reasons for choosing to use a library:

You may not care less about JavaScriptology, about JavaScript itself,
about object models, about inheritance, about closures, about the
DOM,
about etc.
You may just want (or need) to build a web page asap.
You may even care less about the web page itself than about its
contents.
You may not want to deal with cross-browser compatibility issues (I'm
one of those).
You may want to have to learn just one api (any api) that works (and
don't care about how it works internally).

Have you ever used a C library ?
Did you ever write your own printf() ?

--Jorge.

 

[Erwin Moller]

Jorge schreef:

There are many reasons for choosing to use a library:

You may not care less about JavaScriptology, about JavaScript itself,
about object models, about inheritance, about closures, about the
DOM,
about etc.
You may just want (or need) to build a web page asap.
You may even care less about the web page itself than about its
contents.
You may not want to deal with cross-browser compatibility issues (I'm
one of those).
You may want to have to learn just one api (any api) that works (and
don't care about how it works internally).

Hey Jorge,

Essentially what you are saying is: "If you don't care about
understanding the language you use, or you are in a hurry, use a
framework.".
To THAT I can agree.

But my message to Hamish was a reaction to:

And hey, an accessible library like jQuery is [hopefully] a good entry
point for someone who will later learn *ahem* real JS.

I don't think using a framework will teach the language fast.
Many (important) problems are abstracted away.
It may work, the app may work, the work gets done in time maybe, but it
is not excactly the fastest route to become better in the underlying
language.

When I must send an email in some obscure ASP/VB script from some
ancient W2000 box, I use the first working script I can find on the net
without understanding a jota of the underlying logic.
But then again, I don't want to be good with that technology, I want to
get my work done and get a cool beer. The faster, the better. ;-)
So yes, I surely can understand that attitude, but bottomline is it
won't make you GOOD with the language.
That was my only point. ;-)

Have you ever used a C library ?
Did you ever write your own printf() ?

Hell no!
Isn't that inside STNDOUT package or something?
Long time no C, for me. ;-)
And no, I don't do any machinecode either these days (6502 was my last).

Of course I rely on libs.
But I must say there is a big difference between printf() in C, and
using JQuery.
I think I can use printf() quite safely since it is used everywhere by
good programmers. JQuery has a bad reputation.
That is simply not the same.

--Jorge.

Regards,
Erwin Moller