Re: to learn jQuery if already using prototype

On Apr 19, 11:07 pm, "Richard Cornford" <Rich...@xxxxxxxxxxxxxxxxxxx>
wrote:
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.

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 write your own words. That way they'll be _from the heart_. You
know the point I'm trying to make.


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.

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.

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).

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.

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

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 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.

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

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,

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.

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.

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.

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).

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.

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
.

Relevant Pages

  • Re: to learn jQuery if already using prototype
    ... I hold that any technology decision is a question of taste. ... The user is the poor sod looking at an alarming little grey box with yellow 'warning' triangle just above their web browser's window that says "Your browser does not support AJAX" and wondering what the hell they are expected to do about it. ... Of course if there was any technical foundation then that could be pointed at quite easily, but as the navigator.userAgent string is a reflection of the HTTP User Agent header then any such direction must lead to the definition of the header in the HTTP specification, and that definition pretty much says that the User Agent header is an arbitrary sequined of zero or more characters that is not even required to be consistent from one request to the next. ... One of the things that gets proposed as a justification for libraries of this sort is that with many individuals contributing there are plenty of eyes looking at the code to be able to find these sorts of things and fix them up front. ...
    (comp.lang.javascript)
  • Re: "The Good Enough Revolution" - As it applies to js
    ... What is the general argument against libraries? ... You will have seen the proposition that well designed code does not fall over when it encounters the lack of quirks in a new browser. ... The 'feature detection' verses 'browser detection' debate illustrates this. ... You write to the ECMA spec and avoid things like named function expressions and arguments/parameters linkage and the result is one language that behaves the same everywhere, ...
    (comp.lang.javascript)
  • Re: JS framework
    ... that is also depenent on browser sniffing. ... agree that more complex selectors are rarely needed (well, ... Modifying host objects is known to be problematic. ... I would have to support all the libraries with that shaming habit. ...
    (comp.lang.javascript)
  • Re: AJAX.NET and prototype.js
    ... The sentiment you espouse almost makes it seem like browser ... needlessly imposed an ongoing maintenance burden through poor script ... sufficiently general to accommodate the context in which you want to use ... So libraries do not offer the full position reporting facially, ...
    (comp.lang.javascript)
  • Re: ZLib double free bug: Windows NT potentially unaffected
    ... I've been researching this bug since I heard that ssh passes packets to zlib ... Double free vulnerabilities are primarily an issue for malloc implementations ... how exploitation of this error works entitled: ... Also as noted above some malloc libraries have explicit protection mechanisms ...
    (Bugtraq)