Re: OT - where to invest



D.Campagna wrote:
[english mode ON - it's not my first language, nor the second one.]
I have been impressed by the deep knowledge of Javascript of many of
the participants in this NG. Also I appreciate the vaste amount of
time and diligence they are spending in giving advice to newbies
(like me) with no rewards at all if not a sporadic "thank you very
much" from people often in a hurry, looking for a quick (and at no
cost) answer.

There are more rewards than you imagine. Just taking the time to write
out an explanation of some aspect of a technical subject can be valuable
in itself, as it helps clarify your own understanding of it (and gives
others the opportunity to offer corrections).

But after many rants against jQuery, in a way that is far away
from a technical debate, but more as a religion war, I decided
to see who is this John Resig so hatred and criticized, and
how the crew of buffoons followers he has are managing the
criticism that the entire world of javascript serious
programmers is supposed to oppose to their ludicrous library.
Well, after a visit at the John Resig's homepage and after spending
some time reading his blog I only would like to know how old are
people here, for example David Mark, Thomas Lahn, or Robert Crockford

You are not scoring well on research here.

(the first three tech-savvy persons that are coming to my mind,
in no order).
I have been impressed not only by the vaste amount of knowledge
this guy is putting on the plate,

Have you? Maybe this is a matter of perspective; perceptions differ
depending on where you observe from.

but by the amount in general of things he
does, not to say the enthusiasm of his followers.
My perplexity reached the top when I discovered he is only an
undergraduate, a person that in no way cold be considered
experienced;

Which would seem to make writing a book called "Pro JavaScript
Techniques" (where "pro" is presumably intended to be an abbreviation of
'professional') a somewhat questionable thing to have done. Pertinent
experience (along with knowledge) being something that you would expect
to see in a professional.

and admittedly is doing things a bit for fun, in his free time
after the hours spent to accomplish his education. Amazing!
This is called only in a way for me, he is a kind of genius, no
way to call him otherwise.

Not having English as a first language you may not perceive this for
what it is, but when John Resig writes, for example, :-

"Since valid HTML is simply a subset of XML, having an efficient way to
parse and browse DOM documents is an absolutely essential for making
JavaScript development easier." - John Resig: Pro JavaScript Techniques.
2006

- and disregarding its status as being factually void, it is difficult
to see the asserted 'since' relationship between 'HTML being ...' and
'an efficient way to parse .. DOM documents is an absolute essential'
as being the work of a genius. Even of the facts were there the logic
of the relationship would still be missing.

Then there are the bogus conclusions drawn on:-

<URL: http://ejohn.org/blog/most-bizarre-ie-quirk >

- where it is difficult to see how a 'genius' could have failed to
anticipate that employing an - alert - in the tests would seriously
impair an effective analysis of mouse interaction related behaviour.

People is criticizing his work here as it were the work of an
entire life of a pretending guy that has already made his best
and is an incompetent.

No that is not the nature of the criticism, quite the reverse. The
criticism is that JQuery is the work of a near novice and (inevitably)
started out making nearly every mistake that would be expected of
someone that far down the browser scripting learning curve. There are
additional criticisms arising from John Resig's unwillingness to accept
that assessment, and so his resistance to changing JQuery to fix those
mistakes (or at least the mistakes that can be fixed and still leave
something that is recognisable as JQuery in existence).

Just so we don't have to go over the 'near novice' perception again,
here is the logic:-

We know that JQuery was designed before the book "Pro JavaScript
Techniques" was written, thus whatever the book shows to be true of its
author in terms of lack of knowledge or experience could only be more
true at the earlier time when JQuery was designed.

"Pro JavaScript Techniques" shows many aspects of javascript from the
optimistic perspective of first seeing a possibility, without any
evidence of being tempered by experience. So, for example, emulating
method overloading is presented as one of its 'techniques'. More
seasoned heads would give method overloading very low priority, as
something that is only very occasionally needed/useful and best avoided
otherwise. There are many reasons for this, including the fact that a
javascript programmer should know the type of value they are passing
into a function when they call it, and so it is pretty dim to throw that
knowledge away and instead have the code in the function work out what
type the argument was (with all the overheads and potential for
misinterpretation that go along with doing that work). An important
factor here being the extreme difficulty that there has always been in
effectively deducing the type of host objects (particularly given the
observed diversity in different web browsers).

Given the superficial optimism expressed in the book it is not
surprising to see method overloading as a common practice in JQuery's
code. And originally that code attempted to make decimations including
attempting to determine the types of host objects. That always was going
to be a nightmare (getting worse as it became necessary to consider more
than the initial couple of browsers) so it is not surprising that recent
changes in JQuery have notched down the method overloading as far as it
possible without re-working the public API. On the other hand, the more
experienced of us, rather than writing books extolling its virtues, have
been recommending against method overloading in javascript, and so
completely avoiding the nightmare that follows its ill considered use.

The book also gives us an insight into its author's grasp of the
fundamentals of javascript at the time of writing; the density of
technical errors and expressed misconceptions joining the doubtful
reasoning shown above to give a generally poor impression. For example,
one passage reads:-

<quote cite="John Resig: Pro JavaScript Techniques. 2006">
| In JavaScript, null, 0, '', false, and undefined are all equal (==)
| to each other, since they all evaluate to false. This means that if
| you use the code test == false, it will evaluate true if test is
| also undefined or equal to null, which may not be what you want.
|
| Listing 3-12. Examples of How != and == Differ from !== and ===
| // Both of these are true
| null == false
| 0 == undefined"
</quote>

- which might be quite an informative, useful and important statement to
make about javascript, if there was one word of truth in it.

(For those who need telling:-

Using the type-converting equality operator (==), null and undefined
equal each other but _do_not_ equal numeric zero, the empty string or
boolean false. Where Numeric zero, the empty string and boolean false do
equal each other they do so because they all type-convert to numeric
zero, not because "they all evaluate to false". There are no true
statements in the first sentence above.

If you use the code - test == false - and test is either undefined or
null then the equality expression will evaluate to false, not true as
asserted above. Whether that is "what you want" or not becomes moot
given that the expressed issue is a chimera. The second sentence above
also contains no true statements.

The expressions from 'Listing 3-12' above, - null == false - and -
0 == undefined - both evaluate to false, making the assertion
"Both of these are true" a false statement. This one is particularly
surprising as you literally only have to write and execute two lines
of code to see the error there.
)

So, at the point of writing his (first) book, John Resig's technical
understanding of the javascript language was, to say the least,
deficient.

A final quote from the book:-

"Compression should be used as the final step, just before putting your
code into production, as your code will frequently become obfuscated
beyond recognition." - John Resig: Pro JavaScript Techniques. 2006

- completes the spectrum. If an individual applies a mechanical
transformation to javascript source code that has the potential of
introducing errors (which "compression" as discussed in the book does)
just prior to putting the code into production, without first re-testing
the code (basically full regression testing) in any software house where
I have worked they would be sacked on the spot, and they would deserve
it. That is just a totally unprofessional thing to.

So at the point of writing his book John Resig had defective technical
understanding of javascript, a defective understanding of related web
technologies ("valid HTML is simply a subset of XML"), lacked the
experience to judge the appropriate application of the techniques
available in javascript and apparently was unfamiliar with professional
software authoring (testing) practices. (We can also assume he was a
lousy judge of who he should choose as technical editor for the book, as
that individual obviously wasn't qualified either.)

Given that, it can hardly be surprising that the creation pre-dating the
book should be seen as having serious deficiencies in both its design
and implementation. Indeed given the situation it would be amazing if it
did not have.

You are talking about a young that has already made in few years more
than the average programmer in an entire life.

Bullshit (in every possible sense).

Yes, jQuery has flaws, I realize, but he (Resig) is talking with
browsers developers, and he is pointing them to the flaws and
incompatibility in the dozens of browsers lying around and making
the life of javascript programmers a nightmare.

No he isn't. John Resig tends to speak of the 4 or 5 most common
browsers as "all browsers". That is not the attitude of someone who is
aware of (or even interested in) the diversity of browsers available,
and not likely to result in any communication with the creators of the
browsers that are not in his limited "all browsers" group.

But even then, his own perceptions of what browsers should be doing are
coloured by the pattern and timing of his own experiences of web
browsers. As many novices inevitably do, he started out with one or two
browsers and drew numerous invalid assumptions about how other browsers
should behave from his observations of those. Missing both the bigger
picture and the historical context in the process. For example, JQuery
was once burdened by the assumption that 'collection' objects (NodeList,
NamedNodeMap, HTMLCollection, etc. interface implementing objects )
would result in the string "object" if made the operand of the -
typeof - operator. And it is easy to see how that assumption might be
drawn if you only ever examined windows IE, Firefox/Mozilla and
Opera > 8.0, but historically it has always been common for the result
of such an operation to be 'function' as these 'collection' object have
been callable (pretty much in every browser except
Firefox/Mozilla/Netscape (and NetFront as it happens)).

If research had covered Mac IE 5, Konqueror, Opera <= 7, IceBrowser
and/or numerous other less common browsers the false assumption would
never have been coded into JQuery. For JQuery the issue reared its
head when Safari suddenly started to look like a browser that needed
to be accommodated, and being derived from Konqueror its response to
a - typeof - operation on a 'collection' object was 'function', and
so JQuery grow a dodgy hack to compensate for an invalid assumption
that could have been avoided from the outset with no more than the
application of a little more experience of actual web browsers.

In no other programming languages you have to worry not only
for the issues of the language itself, but even for the
different implementations, the presence or not of certain
characteristics, and so on, all leading to an unnecessary
complexity and discouraging lack of standards.

Being ignorant of standards is not the same as there being no standards,
even if it may give that appearance.

And if I should decide where to invest my time and energy, I most
likely would choose the promising work of a young genius getting a
large consensus from the vast majority of people that understands
that this situation is getting unmanageable every day more.

If anything is true it is that browser scripting is getting ever more
manageable as time goes on. Whole areas of divergence, for example, the
Netscape 4 'Layers' concept, are now gone, never to return. It is
probably easier to write cross browser code today than it has been at
any time in the last decade.

When you consider the actions of the "vast majority" do you really think
that they understand the situation? One of the ongoing problems I face
at work is getting people (mostly server-side developers) to leave their
IE browser configured so that an error report pops-up every time there
is a script error. I maintain that our web applications should _never_
produce a script error so it is important to know immediately if they
do, because 1. it means that there is something that needs fixing, and
2. any subsequent testing of the server-side code with the browser
becomes meaningless from that point on. But still people are continually
turning the JS error reporting off, and their reason for doing it is
that every time they go on the internet they are constantly burdened by
continuously having to dismiss JS error dialogs on every site they
visit. The reality is that the vast majority of people involved in
creating javascript for the Internet don't have a clue about what they
are doing, their product spits out errors with the slightest
provocation, and most don't even have the whit to see that that is
happening.

This isn't a matter of opinion or interpretation, you can try it for
yourself; get a copy of IE (any version 6+ will do), set the Internet
Options... -> Advanced stetting to shoe an report of every JS error and
then browse the Internet for a while (it really won't matter where you
look) and see how long it takes for constant succession of script error
reports to prompt you into turning it off again.

I - as stated - am only a newbie in javascript but in my fifthies,
and have seen many things from the day I decided to work and study
computer science. Nor I am a newbie in my specific field of interest
(that involves javascript, but is not obviously the main issue), and
can in no way accept the lack of standard and the mess browser
scripting is, as it were an immutable state of things.

As I said, things have been improving, plus there is a huge body of
knowledge gained from experience on how things can be handled where they
have not improved so much. Feature detection, for example, has been the
subject of ongoing experimentation, development and discussion since the
closing years of the last century, so when JQuery started to adopt it
last year it was already a very long way from being a new or theoretical
idea.

We are living in days similar to the days before Windows became the
standard de facto and forced all the programmers and developers to
stick with a standard, simplifying the life for everyone of us, from
programmers to end users.

My estimation would be that the vast majority of public web servers use
Linux as an OS these days (including the web servers of organisations
that exclusively use Windows internally).

<snip>
I just will continue to follow this NG and appreciate any advice, and
hope no rants and angry will be directed against me. The more, I don't
think I will use jQuery, but for sure I will stay tuned on Resig's
progresses, and will give a look inside jQuery. I am sure I have a lot
to learn from him too.

Be vary cautious who you 'learn' from. There are whole communities of JS
'programmers' out there who are too happy/busy congratulating each other
on their 'achievements' to notice when they are writing nonsense (let
alone ever challenge anyone else for the nonsense they are writing). It
is not a healthy situation as it propagates misconceptions, hacks and
mystical incantation. To illustrate; go to this page:-

<URL: http://www.google.com/codesearch >

- and enter the following in search box:-

typeof\s*\(?\s*[\S]+\s*\)?\s*(!|=)==?\s*("|')array("|') lang:javascript

- and do the search. What this is looking for is occurrences of test
expression along the lines of - typeof x == 'array' -. That test is a
nonsense; no native object is allowed (by specification) to result in
the string 'array' from a - typeof - operation, and while host object
are allowed to there has never been any evince that any host object ever
has at any time (and since the instigators and propagators of this
nonsense tend to think that 4 or 5 browsers constitute "all browsers" it
doesn't take much looking to be pretty sure that none of those browser's
host object do).

Yet despite the fact that - typeof x == 'array' - is never ever true for
any object the code search still turns up 2000 hits. And look at where
they are; dojo, firebug, jquery and its plugins, and so on. Supposedly
serious scripts written by (supposedly) knowledgeable people.

This is just a mystical incantation, and like most mystical inactions it
is harmless enough (the test is never true so no action is ever taken as a
result) to never bring itself to anyone's attention. And it
propagates, through one person looking at the code of another who they
mistook for someone who know what they were doing, and 'learning'
something from that code.

The comp.lang.javascript newsgroup may be perceived as a critical
environment but at lest if someone posts this type of nonsense here
there will be someone willing to step up and say that it is nonsense.
Here we weed the mystical incantations out, while in other 'communities'
they propagate unchallenged.

But I only would to know why the effort to have
a more standardized platform and the work of this promising genius is
so badly considered. No technical considerations, please, as they have
already been expressed,

What else is there but the technical considerations?

and no reason to insult me, as often I see it
happens in this NG when someone dares to sing out of the choir.

More people perceive themselves as insulted than ever really are
insulted.

You have to remember that when someone acts like a fool their being
called a fool is not necessarily an insult; it might just be a statement
of fact. In a written medium it is very difficult to judge in what tone
something is being said.

And yes, as I am not proficient in Javascript, I am not in the
position of say... etc. etc. Indeed I am, for the experience I have in
the world of IT. Let me know why jQuery should not be considered an
honest effort to put toghether a vaste number of programmers and have
a point against browser developers, limiting their omnipotence in
deciding that we have to break our minds just to have a script that
works flawlessly on every platform.

That last sentence doesn't quite parse (or pass) as meaningful English.
You are going to have to re-phrase it if you want the question answered.

Oh well, If you have read this 'til here, thank you.

There were a couple of bits that I did not understand, but you appear to
be making a number of assumptions about the situation here that you
really should be questioning.

Richard.

.



Relevant Pages

  • Re: Javascript Library
    ... JavaScript library of any kind, nor has used JavaScript code in any ... jQuery only supports the following browsers: ... Whatever you support, you shouldn't have to ...
    (comp.lang.javascript)
  • Re: OT - where to invest
    ... criticism is that JQuery is the work of a near novice and ... It is probably true that many people, included me, try to learn Javascript outside the schoolclasses, by themselves, in a disordered way, with no precise method. ... So it seems that Resig worked it out alone, not listening to the exprienced programmers, entering the wrong way in some occasion. ... incompatibility in the dozens of browsers lying around and making ...
    (comp.lang.javascript)
  • Re: Comments, suggestions on comp.lang.javascript FAQ
    ... In terms of javascript support and DHTML support, ... some browsers interpret this as ... Upload and post a link to that example so that it can be added to the FAQ. ...
    (comp.lang.javascript)
  • Re: Does Macintosh read uppercase?
    ... global tag in JavaScript used to reference the whole HTML ... case sensitive in all browsers when referencing it in JavaScript). ... It should be $0.00 if the spouse is not registering, ... "Murray" wrote: ...
    (microsoft.public.frontpage.programming)
  • Re: SetTimeout question...
    ... Extract the images as a jQuery object, ... Works in *all* browsers ... which isn't a strong suit for jQuery developers to begin with.) ... If you had learned JavaScript rather than jQuery, ...
    (comp.lang.javascript)