In the end it would be more productive to learn javascript and browser
scripting, and then you make your own mind up.
Prototype.js, and consequently everything based upon it, like
Script.aculo.us, is junk. The jQuery junk support forums are
elsewhere, too.
So you mean Prototype and jQuery are both junk?
I didn't think that statement was ambiguous in any way.
Can you give some points as to why you think so?
That is probably going to come down to understanding.
For example, how else would you pass a
call back function binding to the current scope,
Do you know what that means? It reads like the usual parroting of the
(lamentably) common misconception(or mislabelling) that scope is in some
way related to the value of the - this - keyword in javascript. While in
javascript scope is lexical and so (mostly) determined by the (structure
of the) source code and the - this - value is determined by how
functions/methods are call, and determined at runtime.
such as processData.bind(this) ?
So it is the - this - value that concerns you, not scope at all.
But what sort of question are you asking? Javascript programmers know
what the - this - keyword will refer to at any point, and how to arrange
that the - this - keyword refers to specific objects when it is
necessary. You are not programming until you are in control of that sort
of thing.
As both of Prototype.js and JQuery are written in javascript it must be
possible to write javascript code that does anything and everything that
either are capable of.
I kind of like the arr.each(function(x)
{ ... })
But is "like" enough of a reason? I have seen some horrendously
inefficient uses of function expressions in - each - and - forEach -
methods (including inside the JQuery source code). They seem to
encourage it, at lest where the author had not understood the
implications of what they are doing.
or the arr.sort().uniq().join(" ") syntax.
That style of method chaining has been dogging javascript for years. It
is occasionally useful, but it does result in some very obscure source
code, which probably explains why I can think of no regular contributors
to this group who choose that style of coding.
And one of the consequences of the inherent obscurity of that style of
code is demonstrated in your example. It looks to me like the intention
of - uniq - would be to remove repetitious values from the array
(assuming the subject is an array) and it is unlikely that that method
has been written such that it benefits in any way from the array being
pre-sorted, but the sort method will almost certainly be more efficient
if any elements that are to be removed from the array are removed before
sorting.
Of course seeing and understanding the source code for those methods
would answer the question one way or the other.
But 'liking' superficial syntax and convenience methods are nowhere near
enough to mitigate for the observation (from the source code) that the
authors of those two libraries did not (and seemingly still do not)
understand javascript as a language or its application in browser
scripting.
Richard.
(eventualy....)