to learn jQuery if already using prototype

[VK]

A lot of sailors have to use dial-up via INMARSAT. Do you have a cheery
word for them ?

As a person: "Good and safe trip to all of you!".
As a web developer: nothing. Unless of course some particular project
will require to accommodate the content delivery to the most thin
clients and/or most narrow bandwidth. In the latter case we will do
anything possible within the budget for that: from light weighted HTML
to WML. But no one will change the Web in whole neither for Inmarsat
nor for GSM cell phone surfers.

 

[Andrew Dupont]

On Apr 19, 11:02 am, "Richard Cornford" <[email protected]>
wrote:

First off, full disclosure: I am a Prototype developer, and I know
John Resig well and have immense respect for his library. I don't seek
to change anyone's mind about libraries; I only want to ensure that
dislike thereof is driven by thoughtful deliberation and/or a core
philosophy difference. I welcome any constructive criticism and agree
to disagree about the rest.

That wasn't a rebuttal, more of an excuse for using the code regardless
of any informed assessment of its quality.

To be clearer: I saw it as an argument for why Thomas owned the burden
of proof. If these libraries have won legitimacy on the mainstream
Web, then the opinion that they are shoddy is held by a minority, and
they obviously need to do more persuading.

Again, I worry about matters of taste being presented as facts. I
don't mean to say that all statements need to be prepended with "In my
opinion," but Thomas was using his own taste to render judgement on a
thread and shoo away its originator. I think it's far more
constructive to say "Most of us are not library fans, so you're
unlikely to find useful answers here," then point the way to the
jQuery mailing list. That'd accomplish the same goal with far less
drama.

<snip>

Where the 'proof' is already a matter of public record, and familiar to
anyone who has any more than superficial record of participating in this
group, there is no longer any burden of proof at all.

Perhaps the comp.lang.javascript FAQ needs an entry for this, then. A
large portion of those who post on this newsgroup aren't participants
or even lurkers; they come by only when they have problems. They can't
be expected to catch up on the backstory.

In this case we have a very obviously stupid use of user agent string
based browser detection to make a decision that would be more logically
made with feature detection.

Actually, no — no browser implements String#(un)escapeHTML, so feature
detection would be pointless. We define that function earlier in the
file, but redefine them for WebKit and IE because the String#replace
approach is much, much faster in these two browsers (but much, much
slower in FF and Opera).

To be sure, there are other UA sniffs in Prototype that hard-liners
would decry as unnecessary. I personally try to avoid sniffing
wherever possible, but there are some instances in which a capability
check is either impossible or prohibitively complicated. (The line
between "acceptably complicated" and "prohibitively complicated" is
defined by the individual.)

But that is not the rookie mistake I alluded to above. That mistake is
that the escaping and unescaping methods are not symmetrical. That is,
if you apply the second to the output of the first you will not always
end up with the character sequence you start with. I.E.:-

<script type="text/javascript">
alert('&lt;'.escapeHTML().unescapeHTML()); //alerts "<"
alert('&amp;lt;'.unescapeHTML().escapeHTML()) //alerts "&lt;"
<script>

- and that is pretty bad by anyone's standards (except maybe VK's).

I agree with you on this one. A bug was filed on this not too long
ago; I believe a fix has been checked into trunk and will be in the
next release.

Cheers,
Andrew

 

[Richard Cornford]

On Apr 19, 11:02 am, Richard Cornford wrote:

First off, full disclosure: I am a Prototype developer,
and I know John Resig well and have immense respect for
his library.
I don't seek to change anyone's mind about libraries; I only
want to ensure that dislike thereof is driven by thoughtful
deliberation and/or a core philosophy difference. I welcome
any constructive criticism and agree to disagree about the
rest.

Who is going to be deciding what 'constructive' means in this context?

To be clearer: I saw it as an argument for why Thomas owned
the burden of proof. If these libraries have won legitimacy
on the mainstream Web,

That is an 'if'. Did they win legitimacy or are they just the next
evolution of the copy-and-paste script collections that were mainstay of
less commencement web developers of 5 or 6 years ago?

then the opinion that they are shoddy is held by a minority,

Most informed quality assessments in technical areas will be held by a
minority.

and they obviously need to do more persuading.

You mean that if someone is in a 'minority' then they must be wrong?
That is hardly an attitude that would allow progress through the
adoption of new ideas.

Again, I worry about matters of taste being presented
as facts.

You have not demonstrated that these are questions of taste. The last
time we discussed the prototype.js code here in detail (which was
version 1.6, in November last year) it demonstrated evidence of or its
authors (collectively, as nobody had corrected the code) not
understanding how the code they were writing was going to behave. Seeing
that brings everything into question, form the original design concepts
to every detail of its implementation. And those are not then questions
of taste but the inevitable consequence of evident ignorance among its
developers.

I don't mean to say that all statements need to be
prepended with "In my opinion," but Thomas was using his
own taste to render judgement on a thread and shoo away
its originator.

How do you know that? It seems likely to me that Thomas was using his
memory of the many (more or less detailed) discussions of Prototype.js
code that have happened here over the past few years to inform a general
assessment of the code.

I think it's far more constructive to say "Most of us
are not library fans, so you're unlikely to find useful
answers here,"

That would not be a true statement (at least the second part of it, and
the first part if you take the word 'library' in its most general
sense).

then point the way to the jQuery mailing list.

I have read enough of posts on the JQuery groups to be pretty sure
nobody is likely to much understanding their either. There is too much
of the blind leading the blind (and a huge proportion of questions never
seem to get answered at all).

That'd accomplish the same goal with far less
drama.

Accomplish which goal? Don't you think the OP, if he/she is still
reading this, has not learnt a great deal from this discussion despite
its initial response. There is a lot to be said for the uncensored
exchange of ideas in public.

Perhaps the comp.lang.javascript FAQ needs an entry for this,
then.

It has been discussed, and a number of draft entries proposed. But there
remains some dispute as to what an appropriate response to the question
should be. From the point of view of someone wanting a better
understanding of javascript or browser scripting who just happens to be
using some 'popular' library then they really would get the best answers
to their questions here, if they could present their questions in
isolation (from all of the unrelated and irrelevant stuff that those
libraries contain).

A large portion of those who post on this newsgroup aren't
participants or even lurkers;

If they post questions then they are participants.

they come by only when they have problems. They can't
be expected to catch up on the backstory.

They can. Expecting someone to do a few web searches before they ask to
be spoon fed is not too unreasonable.

Actually, no - no browser implements String#(un)escapeHTML,
so feature detection would be pointless. We define that
function earlier in the file,

Yes, I noticed the other two assignments to the - String.prototype -
later and realised that I was wrong about that.

but redefine them for WebKit and IE because the String#replace
approach is much, much faster in these two browsers (but much,
much slower in FF and Opera).

Can you post a test-case that demonstrates that assertion? Historically
IE has been renowned for its lousy performance with string
manipulation, while Mozilla outperformed everyone else in that area.

But I noticed that the other two escaping/unescaping methods are nothing
like analogous to the two I posted. That is pretty bad in itself because
it means that the same source code is going to have different outcomes
depending on which browser it encounters, and the only way to avoid
falling foul of that would be to explicitly test any application using
the code on each and every browser and with a sufficiently divers set of
data to expose the situations where those inconsistencies might be
problematic. And that is something that is unlikely to actually happen
even in organisations that do do formal QA. After all, you missed the
fact that Safari/IE versions were defective yourselves so how could you
expect web developers who know no more than how to use a library find
the potential issues (or understand them if they did manifest
themselves).

It would be safer to forget about performance in this respect and just
use one set of escaping and unescaping methods. After all, these methods
are not used by the library itself, and are unlikely to be that heavily
used in applications.

To be sure, there are other UA sniffs in Prototype that
hard-liners would decry as unnecessary.

It is not 'unnecessary' that is the questionable aspect of browser
sniffing, but rather that it is technically baseless and demonstrably
ineffective.

I agree with you on this one.

But I suppose that you would not agree that being able to find an
obvious rookie mistake in less then three seconds of looking (at a
library that is already a good few years old) tends to support the
"junk" assessment.

A bug was filed on this not too long ago; I believe a
fix has been checked into trunk and will be in the
next release.

Well, it is a pretty simple fix, and I notice that the subject of my
last substantial criticism of the prototype's code has also been
removed.

Richard.

 

[Thomas 'PointedEars' Lahn]

Lasse Reichstein Nielsen meinte:

Let John respond:

Gopal:
would consider the "with" statement in JavaScript to be very harmful
rather than being useful.

John:
@Gopal: There's a ton of things in JavaScript that can be "considered
harmful". Since JavaScript is such an, extremely, flexible language you
can make mistakes all over the place and not catch it. I just think that
we need to have a better understanding of how the existing features work
to give us a clearer way to move forward and to work with what we have.

I hope this makes things *a lot* clearer.

Unfortunately, your "this speaks for itself" statement is too ambiguous
to stand as an argument by itself. What exactly are you trying to say here?


PointedEars

 

[beegee]

beegee wrote:

For that matter, at least JavaScript[tm] *is* a compiled language like Java.
Don't confuse prompt execution with no-compilation.

Uh, no. Do you understand what compilation is? I mean, there are
javascript compilers but as far as I've heard, none in a browser yet.

I think you miss the point. YUI is *supposedly* only "more like
'Javascript'" (whatever that might be) than Prototype or jQuery in the sense
that its developers *supposedly* knew enough about the programming languages
to unleash their full potential without having to resort to inefficient and
error-prone detours of inventing "classes" and "initializers" where there
are already prototypes and constructors.

You certainly do like to argue, don't you. It takes quite a talent to
obfuscate agreement to point of it sounding like disagreement.

Bob

 

[Gregor Kofler]

Thomas 'PointedEars' Lahn meinte:

Unfortunately, your "this speaks for itself" statement is too ambiguous
to stand as an argument by itself. What exactly are you trying to say here?

I can only think of one advantage of with - saves some typing (and
script size). There might be others I don't know of. However, I also
know about the problem with with because of breaking the scope chain
(perhaps that's Gopal meant with his comment). There might be others I
don't know of.

Anyway, I expect that somebody claiming to be an "evangelist", "guru" or
"ninja" advertising the usefulness of "with", comes up with a more
substantial response than ...this. Well, maybe he doesn't want to give
away the best parts of the book.

Gregor

 

[Thomas 'PointedEars' Lahn]

beegee wrote:
For that matter, at least JavaScript[tm] *is* a compiled language like
Java. Don't confuse prompt execution with no-compilation.

Uh, no. Do you understand what compilation is?

Yes, do you?

I mean, there are javascript compilers but as far as I've heard, none in
a browser yet.

There are JIT-compilers.

You certainly do like to argue, don't you. It takes quite a talent to
obfuscate agreement to point of it sounding like disagreement.

We don't have an agreement here.


PointedEars

 

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn meinte:

Unfortunately, your "this speaks for itself" statement is too ambiguous
to stand as an argument by itself. What exactly are you trying to say here?

[...] I expect that somebody claiming to be an "evangelist", "guru" or
"ninja" advertising the usefulness of "with", comes up with a more
substantial response than ...this. [...]

I see, and I agree with you here. Thanks for your explanation.


PointedEars

 

[Lasse Reichstein Nielsen]

If these libraries have won legitimacy on the mainstream
Web, then the opinion that they are shoddy is held by a minority, and
they obviously need to do more persuading.

There is no contradiction between the two opinions. Something can
easily win ligitimacy and still be shoddy.

In this particular case, I believe libraries like Prototype and JQuery
to be distruptive technologies (q.v.). I.e., they *are* qualitatively
inferior to doing things the hard (old) way. However, they work
/adequately/ for many things, and they allow people with less skill
than would otherwise be necessary to create pages that serve their
needs. I.e., they are /enabling/ without being perfect.

People here will keep complaining about the shoddy quality of
libraries while that quality, slowly, increases. This goes on until
the time when libraries have won, and anybody not using them is
putting themselves at a disadvantage.

/L

 

[Richard Cornford]

There is no contradiction between the two opinions. Something can
easily win ligitimacy and still be shoddy.

<snip>

And then there is the question of what constitutes "legitimacy" in the
first place. Were the copy-and-paste code collections of the last decade
illegitimate? Or endemic bad practices such as eval-ing runtime
constructed property accessor strings? Some would answered with a
resounding 'yes', while the people using them would probably have
disagreed.

People here will keep complaining about the shoddy quality of
libraries while that quality, slowly, increases.

If complaining was the only thing that went on here then that would end
up being futile and pointless. But over the years the discussions of the
many inherent problems with general purpose libraries had resulted in
some useful ideas about how to set about creating a code-base that could
offer high levels of code re-use, and a relatively low entry level,
while mitigating the problems inherent in the current approaches.

As to "slowly, increasing"; that is happening, at minimum because the
authors of those libraries cannot avoid becoming better informed about
how javascript works at time goes on. The really very obviously bad
aspects of their original cod do eventually get weeded out. But there is
a limit to how far that can go because while these things have 'users'
who expect ongoing support, bug fixes and updates for new browsers there
is never a possibility of going back and re-visiting the fundamental
design of the library's API. And if the original design was done at a
time when the original authors were writing code that was amenable to
improvements in its internal quality the odd are extremely good that
those shortcomings also manifested themselves in the API design itself.

So Prototype.js and QUery authors are struggling to mitigate the poor
performance that their code exhibits, and realistically can probably
nearly double its actual performance, but that is it. Aspects of the
original library design place a fixed cap on what can be achieved even
if all of the internal details were rendered optimal.

This goes on until the time when libraries have won, and
anybody not using them is putting themselves at a
disadvantage.

There is no disadvantage from understanding javascript. In the event
that I was put in a position of being forced to use any of these
'popular' libraries the ability to understand how they work internally
would be a huge advantage in actually using them. Though that is
extremely unlikely to happen where I work now because none of the
existing popular libraries perform anywhere near fast enough for the web
applications I work on, and they never could.

Richard.

 

[kangax]

There is no disadvantage from understanding javascript. In the event
that I was put in a position of being forced to use any of these
'popular' libraries the ability to understand how they work internally
would be a huge advantage in actually using them. Though that is
extremely unlikely to happen where I work now because none of the
existing popular libraries perform anywhere near fast enough for the web
applications I work on, and they never could.

Is it possible to see the above mentioned web applications?

Thanks,
kangax

 

[beegee]

beegee wrote:

Yes, do you?

Transforming an english-like higher level programming language coded
program into a lower-level programming language coded program for the
benefits of speed and size.

There are JIT-compilers.

And what lower level language or instruction set are these JIT-
compilers compiling Javascript into to? Setting up a symbol table and
transforming to more efficient Javascript in the pre-processing pass
of Javascript is not compiling. All modern interpreters do this.
Again, there are real compilers for Javascript (Rhino) but they are
not in browsers yet although it's possible that FF 3.0 has one.

We don't have an agreement here.

Really? Are you saying the creators of YUI do not know enough about
javascript to avoid the pitfalls of JQuery and Prototype? I'm the
first to admit that YUI has some speed and object model problems but
I'm not sure that mocking the libary for only *supposedly* being
better than the others without some kind of specifics is really a
point view.

Bob

 

[Zeroglif]

Transforming an english-like higher level programming language coded
program into a lower-level programming language coded program for the
benefits of speed and size.

Brendan Eich (JavaScript):
"Client JavaScript reads source from SCRIPT tag contents, but compiles
it into an internal bytecode for faster interpretation."

Eric Lippert (JScript):
"JScript Classic acts like a compiled language in the sense that
before any JScript Classic program runs, we fully syntax check the
code, generate a full parse tree, and generate a bytecode. We then run
the bytecode through a bytecode interpreter. In that sense, JScript is
every bit as "compiled" as Java. The difference is that JScript does
not allow you to persist or examine our proprietary bytecode. Also,
the bytecode is much higher-level than the JVM bytecode -- the JScript
Classic bytecode language is little more than a linearization of the
parse tree, whereas the JVM bytecode is clearly intended to operate on
a low-level stack machine."

 

[Andrew Dupont]

Who is going to be deciding what 'constructive' means in this context?

Each individual on his own. Or, in other words: say what you want to
say, and I'll brush off anything I think is unwarranted. I'm not
setting conditions for prior restraint here.

You mean that if someone is in a 'minority' then they must be wrong?
That is hardly an attitude that would allow progress through the
adoption of new ideas.

I never said anything of the sort. I said the minority need to do more
_persuading_. You stated that these libraries were junk as though it
were common knowledge. Clearly it isn't common knowledge.

You have not demonstrated that these are questions of taste. The last
time we discussed the prototype.js code here in detail (which was
version 1.6, in November last year) it demonstrated evidence of or its
authors (collectively, as nobody had corrected the code) not
understanding how the code they were writing was going to behave. Seeing
that brings everything into question, form the original design concepts
to every detail of its implementation. And those are not then questions
of taste but the inevitable consequence of evident ignorance among its
developers.

I hold that any technology decision is a question of taste. There is
no objective "better" in the sense of Ruby vs. Python, or vi vs.
emacs; there is only the subjective "better" — whichever best serves
the user's own needs.

Naturally, this does _not_ mean that everything is relative, or that
it's not worth having passionate arguments thereabout. I implied as
much in my music analogy: friends argue among themselves over which
band is "better," but they all realize that taste is the ultimate
arbiter. These arguments become tiresome only when people dig trenches
and start speaking in absolutes.

How do you know that? It seems likely to me that Thomas was using his
memory of the many (more or less detailed) discussions of Prototype.js
code that have happened here over the past few years to inform a general
assessment of the code.

And I submit that is a matter of taste. Bugs are bugs, of course, and
we welcome bug reports. But you've gone further than that; you've
inferred from "evidence" that code in Prototype does not do what its
author means for it to do.

That would not be a true statement (at least the second part of it, and
the first part if you take the word 'library' in its most general
sense).

Then write your own words. That way they'll be _from the heart_. You
know the point I'm trying to make.

I have read enough of posts on the JQuery groups to be pretty sure
nobody is likely to much understanding their either. There is too much
of the blind leading the blind (and a huge proportion of questions never
seem to get answered at all).



Accomplish which goal? Don't you think the OP, if he/she is still
reading this, has not learnt a great deal from this discussion despite
its initial response. There is a lot to be said for the uncensored
exchange of ideas in public.

The word "censorship" doesn't come within miles of this thread. I do
not own a telecommunications company; I don't have the means or
authority to "censor" anyone.

I can only imagine the OP was interested in the free exchange of ideas
when he asked you why you thought jQuery and Prototype were junk. I'm
arguing that he'd have learned far more from a link to a page called
"Why I, Richard Cornford, Think Prototype and jQuery Are Junk" than
from this low-signal, high-noise snark-off.

It has been discussed, and a number of draft entries proposed. But there
remains some dispute as to what an appropriate response to the question
should be. From the point of view of someone wanting a better
understanding of javascript or browser scripting who just happens to be
using some 'popular' library then they really would get the best answers
to their questions here, if they could present their questions in
isolation (from all of the unrelated and irrelevant stuff that those
libraries contain).

That last sentence is the answer to such a FAQ. Even a link to that
question and answer would be more helpful than what has happened in
this thread.

If they post questions then they are participants.

I mean that they weren't participants before their first post. Many
posters, I would venture, only come here when they need help, and
therefore aren't already familiar with the quirks of the community.

They can. Expecting someone to do a few web searches before they ask to
be spoon fed is not too unreasonable.

Please search this newsgroup for the terms "Prototype" and/or "jQuery"
and see how quickly you find a well-summarized critique of either
library.

Yes, I noticed the other two assignments to the - String.prototype -
later and realised that I was wrong about that.


Can you post a test-case that demonstrates that assertion? Historically
IE has been  renowned for its lousy performance with string
manipulation, while Mozilla outperformed everyone else in that area.

I don't have a test-case. The change was made one year ago by Thomas
Fuchs [1]. You're welcome to ask him, though I suspect he'll punch me
in the sternum for having dragged him into this.

But I noticed that the other two escaping/unescaping methods are nothing
like analogous to the two I posted. That is pretty bad in itself because
it means that the same source code is going to have different outcomes
depending on which browser it encounters, and the only way to avoid
falling foul of that would be to explicitly test any application using
the code on each and every browser and with a sufficiently divers set of
data to expose the situations where those inconsistencies might be
problematic. And that is something that is unlikely to actually happen
even in organisations that do do formal QA. After all, you missed the
fact that Safari/IE versions were defective yourselves so how could you
expect web developers who know no more than how to use a library find
the potential issues (or understand them if they did manifest
themselves).

Nothing I say in our defense will satisfy you, because you seem to
want a level of certitude that I can't guarantee. I could say that we
have extensive unit tests, but clearly they were not extensive enough
to catch the bug that you pointed out — though that bug was noticed in
the wild, submitted to our tracker, and patched, and more unit tests
were added in the process. This is how open-source software works.

I can't guarantee that any of us will write bug-free code on the first
pass, any more than you can guarantee that you won't spell another
word incorrectly for the rest of your life. instead, we have a testing
process meant to ferret out as many self-introduced bugs as possible.
When that fails, we rely on the community to file tickets. No doubt
you have rolled your eyes by now, so I'll just move on.

It would be safer to forget about performance in this respect and just
use one set of escaping and unescaping methods. After all, these methods
are not used by the library itself, and are unlikely to be that heavily
used in applications.


It is not 'unnecessary' that is the questionable aspect of browser
sniffing, but rather that it is technically baseless and demonstrably
ineffective.

You haven't demonstrated that anything is baseless or ineffective;
you've only revealed a different set of priorities. You'd rather have
100% guaranteed behavior even if it meant a wildly-varying performance
graph across browsers. I'd rather have the reverse.

But I suppose that you would not agree that being able to find an
obvious rookie mistake in less then three seconds of looking (at a
library that is already a good few years old) tends to support the
"junk" assessment.

The check-in is only one year old. It is Thomas's bug, but he is no
rookie, so I can only surmise that we all make silly mistakes
sometimes. Bad luck for him that he managed to stumble upon your
Shibboleth Bug(TM).

Well, it is a pretty simple fix, and I notice that the subject of my
last substantial criticism of the prototype's code has also been
removed.

We listen to criticism, we read bug reports, and we constantly search
for ways to improve the feedback loop. So does John Resig, by the way,
so I'd suggest you file a bug on jQuery's Trac about the "makeArray"
mistake.

Cheers,
Andrew

 

[Matt Kruse]

Interestingly I observed Matt Kruse (who is the nearest thing to a
supporter JQuery has among the regular contributors to this group, and
someone who can easily outgun anyone directly involved in JQuery
development when it comes to javascript)

Wow, given your view of the jQuery dev team, I'm not sure if that's
even close to a compliment

directly asked however was
responsible for the - if ( typeof array != "array" ) - code to own up to
it in a post on the JQuery development group. However, when I checked
back a week later to see if anyone had the intellectual integrity to own
up to their mistake I found that Matt's post had been deleted from the
group.

If you're referring to this point:
http://groups.google.com/group/jquery-dev/msg/54b54712bd48ec83
then I can still find it.

Unfortunately, it hasn't generated any further discussion as I thought
it certainly warranted.
It's this kind of indifference about truly embarrassing code in the
jQuery source that I find most troubling.
They seem to be more interested in adding a new CSS3 selector or
saving 20 bytes by condensing some code than in correcting bad
programming practices.

I think John Resig loves Javascript and is probably learning more
about it as time goes on, but I suspect that his primary goal of
evangelizing jQuery is to enable the writing of more books and
attending more speaking engagements. Otherwise I can't comprehend why
some of these issues haven't gotten instant attention as I believe
they deserve.

Matt Kruse

 

[Matt Kruse]

We listen to criticism, we read bug reports, and we constantly search
for ways to improve the feedback loop. So does John Resig, by the way,
so I'd suggest you file a bug on jQuery's Trac about the "makeArray"
mistake.

I know nothing about Prototype's "feedback loop" but I'll say that my
impression of the jQuery loop has been that it is very fond of praise
and quick to dismiss or ignore genuine critiques about its core code
or design decisions.

I've made a number of attempts to make suggestions that I consider to
be no-brainers... getting rid of unnecessary browser sniffs,
optimizing loops which are extremely inefficient, making the
isFunction() function work more more closely to how it was
(misguidedly) intended, removing some code that is completely
unnecessary (makeArray), and reporting some bugs.

I've gotten a lackluster response to most posts, even though I would
consider some of these issues to be extremely important in cleaning up
the jQuery code, making it faster, and improving its overall quality.

I'm quite fond of much of the API that jQuery offers, the coding style
that it often enables, and the ease with which it enables new/amateur
developers to create working code in the right environments. If I had
the time and interest, I would probably be inclined to branch the code
into something more solid, fix many of the issues that exist, and
remove some of the overloading that makes the API kind of a mess.

But since I lack both the time and interest, I'm still trying to push
the jquery dev team into improving the code and hopefully bringing
jQuery up to par as a library that can withstand the scrutiny of
experienced js developers. Even if they would still not choose to use
it.

Matt Kruse

 

[dhtml]

One of the arguments paraded in favour of these libraries is that they
are examined, worked on and used by very large numbers of people, and so
they should be of reasonably high quality because with many eyes looking
at the code obvious mistakes should not go unnoticed. My experience of
looking at code from the various 'popular' libraries suggests that this
is a fallacy, because (with the exception of YUI (for obvious reasons))

Not obvious.

There's plenty of bugs YUI. A good number of them are reported in the
bugtracker (public) yet others are reported on the Yahoo internal bug
tracker (Bugzilla). Others may still be unfiled.

I don't 100% agree that the problem is not that the authors aren't
smart enough. A lot of these problems come from the process. Things
like having one guy own such-such piece of code, or the code freezes.
Or testing the happy path of maybe 20% of an object's methods.

all of the 'popular' library contain numerous obviously stupid mistakes.

Including YUI.

They also have bug trackers. As Andrew pointed out, Prototype does
too.

A fix for the bug that was demonstrated seems to be by simply putting
the &amp; last.

String.prototype.unescapeHTML = function() {
return this.replace(/&lt;/g,'<')
.replace(/&gt;/g,'>')
.replace(/&amp;/g,'&');
};

That would need to be tested out though.

Right?

Garrett

 

[beegee]

Brendan Eich (JavaScript):
"Client JavaScript reads source from SCRIPT tag contents, but compiles
it into an internal bytecode for faster interpretation."

Eric Lippert (JScript):
"JScript Classic acts like a compiled language in the sense that
before any JScript Classic program runs, we fully syntax check the
code, generate a full parse tree, and generate a bytecode. We then run
the bytecode through a bytecode interpreter. In that sense, JScript is
every bit as "compiled" as Java. The difference is that JScript does
not allow you to persist or examine our proprietary bytecode. Also,
the bytecode is much higher-level than the JVM bytecode -- the JScript
Classic bytecode language is little more than a linearization of the
parse tree, whereas the JVM bytecode is clearly intended to operate on
a low-level stack machine."

Thanks for the quotes. I thought, at first, from reading them that I
had been totally wrong about compilation of javascript. Then I read
deeper in the second quote about what the byte code is. And really,
it is not a true compilation. It is still a first pass optimization.
In fact I wouldn't be surprised if the same machine that can interpret
unprocessed javascript, interprets the bytecode.

Bob

 

[Thomas 'PointedEars' Lahn]

Thanks for the quotes. I thought, at first, from reading them that I had
been totally wrong about compilation of javascript. Then I read deeper
in the second quote about what the byte code is. And really, it is not a
true compilation. It is still a first pass optimization.

Winding around your error, are you? It is true compilation, as true as
byte-code compilation in Java is, for example.

In fact I wouldn't be surprised if the same machine that can interpret
unprocessed javascript, interprets the bytecode.

Bytecode is platform-independent, of course, because a Virtual Machine
interprets it. As I have said, in that sense at least JavaScript[tm],
and as it turns out JScript also, are compiled languages.


PointedEars

 

[VK]

Bytecode is platform-independent, of course, because a Virtual Machine
interprets it. As I have said, in that sense at least JavaScript[tm],
and as it turns out JScript also, are compiled languages.

???

What is interpreted language then for you? Read next line of code -
Parse for token - Create internal code - Execute - Forgot this code -
Cleared the memory - Moved to the next line? Something like that?
There is no such engine since Enigma and Cyclometer at least

Javascript is being stored and delivered to the engine in the raw text
source code format. The engine naturally compiles it to be able to use
so the engine works with compiled code - but Javascript is not a
compiled language. Try to see the difference, if you can.

P.S. JScript.NET _is_ a compiled language.