Prototype - Good/Bad/Why?
ashore
someone share your views, either way?
Thanks,
AS
David Mark
Prototype - very bad.
It relies on browser sniffing in lieu of proper feature detection and
testing.
It works (sort of) in a limited set of modern browsers.
It is too large and the design isn't modular.
It is horribly inefficient. Even the lowest level code is tangled up
in syntactic sugar.
It augments host objects, most notably in the (unfortunately named) $
function.
It fails to leverage the inherent power of the JS language, instead
trying to force it to work like a class-based language.
Search the group for more details. Alternatively, read the comments
in the Rails Trac or related blogs.
dhtml
What goes on behind the scenes in Prototype? Some of the syntactic
sugaring is inefficient. It also makes code that uses prototype
require all of prototype, which is now a lot of code. Object Oriented
and non-modular.
The $super approach caused problems with compressors:
http://www5.sys-con.com/read/464826.htm
In fact, YUI compressor has apparently some logic to account for this.
(according to the README).
What do YOU think?
Randy Webb
> Guys, I see a fair bit of negativity around re subject package. Can
> someone share your views, either way?
Richard Cornford said it better than anybody else I have ever seen write
it and Thomas Lahn uses it in a signature:
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300d...@news.demon.co.uk>
--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
David Mark
> On Feb 15, 2:36 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
>
>
>
>
> > On Feb 15, 4:53 pm, ashore <shor...@gmail.com> wrote:
>
> > > Guys, I see a fair bit of negativity around re subject package. Can
> > > someone share your views, either way?
>
> > > Thanks,
>
> > > AS
>
> > Prototype - very bad.
>
> > It relies on browser sniffing in lieu of proper feature detection and
> > testing.
>
> > It works (sort of) in a limited set of modern browsers.
>
> > It is too large and the design isn't modular.
>
> > It is horribly inefficient. Even the lowest level code is tangled up
> > in syntactic sugar.
>
> > It augments host objects, most notably in the (unfortunately named) $
> > function.
>
> > It fails to leverage the inherent power of the JS language, instead
> > trying to force it to work like a class-based language.
>
> > Search the group for more details. Alternatively, read the comments
> > in the Rails Trac or related blogs.
>
> What goes on behind the scenes in Prototype? Some of the syntactic
From what I have read of it, nothing good. Like other (currently)
popular libraries, much of its decision-making is based on browser
sniffing and particularly susceptible to the myriad IE imitators out
there. Treating a non-IE agent as IE is clearly a recipe for
disaster. The authors of such libraries live in a dream world where
such agents don't exist.
I recently stumbled across the change log for the event handling code
and was amused to see that it cannot handle mousewheel events for the
handful of browsers it claims to support without several sniff-and-
branch operations. Such profound incompetence is on display
throughout the code. The accompanying comments to the seemingly
constant changes indicate that the developers haven't got a clue what
they are doing. How long until the maze of browser sniffing logic
outweighs the code that does actual work?
> sugaring is inefficient. It also makes code that uses prototype
> require all of prototype, which is now a lot of code. Object Oriented
> and non-modular.
Exactly. It is all-or-nothing. Developers are advised to choose
nothing.
>
> The $super approach caused problems with compressors:http://www5.sys-con.com/read/464826.htm
I wasn't aware of that one. One of the benefits of not using
Prototype (or the like) is that you don't have to keep up with the bug
reports.
>
> In fact, YUI compressor has apparently some logic to account for this.
> (according to the README).
I highly recommend the YUI "compressor" (misnomer), but certainly not
YUI itself. It is a better script than Prototype, but shares many of
the same problems (e.g. browser sniffing, too much sugar, etc.) Then
there is that ridiculous "namespace."
>
> What do YOU think?
ME? I think I have made that abundantly clear. The only thing worse
than Prototype is jQuery. YUI is slightly better, but still well
south of competent. Using any of these libraries (or God forbid
combinations of them) is a bad idea. The average Web developer can
achieve lousy results on their own, so what is the benefit of adding
100K of third-party incompetence to the mix?
Randy Webb
<snip>
> The average Web developer can achieve lousy results on
> their own, so what is the benefit of adding 100K of
> third-party incompetence to the mix?
Incompetence and peer pressure. Not knowing better and because
"everybody" is using it.
David Mark
> David Mark said the following on 2/15/2008 10:42 PM:
>
> <snip>
>
> > The average Web developer can achieve lousy results on
> > their own, so what is the benefit of adding 100K of
> > third-party incompetence to the mix?
>
> Incompetence and peer pressure. Not knowing better and because
> "everybody" is using it.
>
It sometimes seems like "everybody" is doing it. What I can't
understand is why huge corporations would put their faith in trash
like Prototripe/Craptaculous (typically to add a few nifty fade
effects.) Can't they afford to pay competent developers? On the
server side, most appear to believe that .NET is the answer. If so,
what was the question?
From what I have read about IE8 (specifically the new versioning meta
tag), all of the libraries that rely on IE-sniffing are in for a rude
awakening. Will the authors finally see the folly of their ways or
will they add more branching based on the content of the meta tag?
Peter Michaux
> Guys, I see a fair bit of negativity around re subject package. Can
> someone share your views, either way?
<FAQENTRY>
Shouldn't something about Prototype be in the FAQ? It comes up very
frequently.
Peter
David Mark
I propose a two word entry: mostly harmful.
And for jQuery: completely worthless.
dhtml
> On Feb 15, 9:36 pm, dhtml <dhtmlkitc...@gmail.com> wrote:
>
>
>
> > On Feb 15, 2:36 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > On Feb 15, 4:53 pm, ashore <shor...@gmail.com> wrote:
>
> I highly recommend the YUI "compressor" (misnomer), but certainly not
> YUI itself.
Me too. But why 'misnomer'? It reduces the file size pretty well.
It is a better script than Prototype, but shares many of
> the same problems (e.g. browser sniffing, too much sugar, etc.) Then
> there is that ridiculous "namespace."
>
Namespacing seemed stupid to me, at first. I mean, these aren't
"packages", they're just objects.
In fact, it confused the junior devs. Check out this example:
YAHOO.namespace("YAHOO.mst.scheduler");
YAHOO.mst.scheduler = function() { ... }
It's entirely possible to do this; to reassing a "package" to a
function (or any value, or delete it). It's not safe. But neither are
prototypes.
extend(Sub, Super);
Sub.prototype = { }; // <- Developer Mistake, just reassinged
prototype.
extend(Sub, Super, mixin); // <- corrected.
On the other hand, enforcing namespacing has made my code more
modular. Keeping the global namespace clean is just a small benefit.
If I didn't use packages and a build system, unit testing would be a
lot harder.
Writing a library is a lot of work. I want to write a better one. This
includes:
modular desing.
minimal framework.
building things as simple as possible, but not any simpler.
unit testing.
code review.
Now that last one, I could probably use a lot of help on.
>
>
> > What do YOU think?
>
That was meant for the OP. I'm not sure why this thread was brought up
even. If s/he's really considering Prototype, he could have done a web
search, or searched this group. (but I can't search Groups in FF
again; it's only FF now).
> ME? I think I have made that abundantly clear.
You have.
The only thing worse
> than Prototype is jQuery. YUI is slightly better, but still well
> south of competent. Using any of these libraries (or God forbid
> combinations of them) is a bad idea. The average Web developer can
> achieve lousy results on their own, so what is the benefit of adding
> 100K of third-party incompetence to the mix?
Most of the F/E jobs here in the bay area want someone who has one of
the following:
Prototype, YUI, Dojo, Scriptaculous, jQuery. If you can do that (of
fake it good enough), you can make decent money.
Richard Cornford
> On Feb 15, 7:42 pm, David Mark wrote:
>> On Feb 15, 9:36 pm, dhtml wrote:
>>> On Feb 15, 2:36 pm, David Mark wrote:
>>>> On Feb 15, 4:53 pm, ashore wrote:
<snip>
> It's entirely possible to do this; to reassing a "package"
> to a function (or any value, or delete it). It's not safe.
> But neither are prototypes.
Javascript is a dynamic language where it is possible to write code that
will 'mess up' pretty much any other code. Nothing is "safe", there are just
varying degrees to which it is easy for programmer to break an existing
system. In the end it is the programmer's responsibility not to be doing
things wrongly, and that is going to be best achieved by understanding the
task in hand, the system it is to be done in/with and the environment(s) in
which it will operate.
<snip>
> On the other hand, enforcing namespacing has made my code
> more modular. Keeping the global namespace clean is just
> a small benefit.
If 'namespacing' were the only way of making code modular then that would
act as a justification for them, but they are not. Which leaves the only
relevant namspace-modularity relationship being a demonstration that they
may be either 'the best method' for achieving modularity or a 'good' method
in some sense or under some circumstances.
<snip>
> Writing a library is a lot of work.
> I want to write a better one.
Remember to decide what precisely your library if for before even starting
to design it. Browser scripting has many contexts of application and trying
to create something that attempts to be all things to all people is pretty
much guaranteed to have a result that falls short of all.
> This includes:
> modular desing.
> minimal framework.
> building things as simple as possible, but not any simpler.
> unit testing.
> code review.
>
> Now that last one, I could probably use a lot of help on.
It is still probably the easiest because all you have to do is post code
here in a readable/understandable form (along with an explanation of what it
is for) and its shortcomings will be pointed out.
My thoughts on the majority of current libraries is that they have been
bought into existence while their authors were experiencing the first flush
of superficial success in browser scripting (the stage where you start to be
able to create things that will work on more than two browsers and then gain
the false impression that you have the problem cracked) and then rushed
before a public hungry for such things. This has the effect of pretty much
freezing the libraries API (and its approach and the implied code authoring
style). The problem being that the authors don't see (because they don't
have the experience to see) that they have made fundamentally flawed design
decisions, and then the freezing of the API that follows from its being used
in the wider world removes any future hope of the overall design being
corrected (even if the authors are willing/ capable of recognising their
mistakes (and the current set seems to include many who have personalities
that are extremely resistant to the very idea that they may have done
anything wrong)).
Generally people who can recognise and learn from their mistakes will do
things better a second time and better yet a third.
<snip>
> Most of the F/E jobs here in the bay area want someone who has
> one of the following:
> Prototype, YUI, Dojo, Scriptaculous, jQuery. If you can do that
> (of fake it good enough), you can make decent money.
This is also the trend in job advertisements in the UK, but not for the jobs
with the "decent money" (though our perceptions of "decent money" may
differ). It probably should not be taken too seriously, as the people doing
the recruiting don't tend to know what they need but have to write
something. It is like all the web development jobs where knowing Dreamweaver
was part of the requirement, regardless of the fact that the odds would be
that someone who knew Dreamweaver well would then not have any actual
technical understanding of web development at all.
Richard.
--
"Even if you're not completely familiar with XML, you will get great
satisfaction knowing that all HTML documents (which are, in the eyes of the
browser, XML documents) have a DOM representation that is ready to use." -
John Resig: Pro JavaScript Techniques. 2006
Richard Cornford
> ashore said the following on 2/15/2008 4:53 PM:
>> Guys, I see a fair bit of negativity around re subject
>> package. Can someone share your views, either way?
>
> Richard Cornford said it better than anybody else I have
> ever seen write it and Thomas Lahn uses it in a signature:
>
> Prototype.js was written by people who don't know javascript
> for people who don't know javascript. People who don't know
> javascript are not the best source of advice on designing
> systems that use javascript.
<snip>
To be fair, I did not write that as a criticism of Prototype.js as such. I
wrote it as a comment on the worth of taking the advice of people who use
Prototype.js (advice which is usually that others should also use
Prototype.js).
Of course the comment was justified, and I certainly demonstrated technical
justification of my "by people who don't know javascript" in the thread with
the subject "Why should I eschew prototype.js?" (which started with
Message-ID: < 1194882268.2...@v3g2000hsg.googlegroups.com >).
Richard.
--
"Since valid HTML is simply a subset of XML, having an efficient way to
parse and browser DOM documents is an absolutely essential for making
JavaScript development easier." - John Resig: Pro JavaScript Techniques.
2006
dhtml
wrote:
> dhtml wrote:
> > On Feb 15, 7:42 pm, David Mark wrote:
> >> On Feb 15, 9:36 pm, dhtml wrote:
> >>> On Feb 15, 2:36 pm, David Mark wrote:
> >>>> On Feb 15, 4:53 pm, ashore wrote:
> <snip>
> > It's entirely possible to do this; to reassing a "package"
> > to a function (or any value, or delete it). It's not safe.
> > But neither are prototypes.
>
> Javascript is a dynamic language where it is possible to write code that
> will 'mess up' pretty much any other code. Nothing is "safe", there are just
> varying degrees to which it is easy for programmer to break an existing
> system. In the end it is the programmer's responsibility not to be doing
> things wrongly, and that is going to be best achieved by understanding the
> task in hand, the system it is to be done in/with and the environment(s) in
> which it will operate.
>
[snip]
> <snip>
>
> > On the other hand, enforcing namespacing has made my code
> > more modular. Keeping the global namespace clean is just
> > a small benefit.
>
[sip]
> > code review.
>
> > Now that last one, I could probably use a lot of help on.
>
> It is still probably the easiest because all you have to do is post code
> here in a readable/understandable form (along with an explanation of what it
> is for) and its shortcomings will be pointed out.
>
Thread coming.
> My thoughts on the majority of current libraries is that they have been
> bought into existence while their authors were experiencing the first flush
> of superficial success in browser scripting (the stage where you start to be
> able to create things that will work on more than two browsers and then gain
> the false impression that you have the problem cracked) and then rushed
> before a public hungry for such things.
Well there;s plenty of mistakes to learn from, then.
This has the effect of pretty much
> freezing the libraries API (and its approach and the implied code authoring
> style).
That's what I see with YAHOO. They can't change some broken core parts
of the library, like YAHOO.hasOwnProperty, augmentObject, et c.
With so many dependencies, how can they change?
The problem being that the authors don't see (because they don't
> have the experience to see) that they have made fundamentally flawed design
> decisions, and then the freezing of the API that follows from its being used
> in the wider world removes any future hope of the overall design being
> corrected (even if the authors are willing/ capable of recognising their
> mistakes (and the current set seems to include many who have personalities
> that are extremely resistant to the very idea that they may have done
> anything wrong)).
>
> Generally people who can recognise and learn from their mistakes will do
> things better a second time and better yet a third.
>
> <snip>
>
> > Most of the F/E jobs here in the bay area want someone who has
> > one of the following:
> > Prototype, YUI, Dojo, Scriptaculous, jQuery. If you can do that
> > (of fake it good enough), you can make decent money.
>
> This is also the trend in job advertisements in the UK, but not for the jobs
> with the "decent money" (though our perceptions of "decent money" may
> differ). It probably should not be taken too seriously, as the people doing
> the recruiting don't tend to know what they need but have to write
> something. It is like all the web development jobs where knowing Dreamweaver
> was part of the requirement, regardless of the fact that the odds would be
> that someone who knew Dreamweaver well would then not have any actual
> technical understanding of web development at all.
>
It's not just recruiters. Not many javascript experts out there.
One case is the company adopts a library. Often, they're B/E devs (or
tech leads w/o F/E experience). They want a library that's easy to
understand and does what they need.
Another case is a F/E dev will promote the library he likes to his
company, or the team will pick a library. As the team grows, they hire
other developers who know the same tools.
Hype can be a big influence.
Contract jobs such as these vay in pay range, depending on desparation
(Urgent: Must get 'Ajax' guru). They pay from USD 40-90+/hr. or 70-150k
+/yr. (in the Bay area).
Garrett
> Richard.
timothytoe
jQuery or Prototype or YUI, those libraries will be continue to be
used to make websites. And probably to an acccelerating degree.
I agree that browser-sniffing is about as appealing as anus-sniffing,
but programmers in the real-world sometimes need to actually get
things done. A smart programmer (as opposed to a perfection-seeking
zealot} will go with the flow and be able to throw together a website
quickly as a result. Sure, the website will be brittle, and users with
obscure browsers will whine, but that's not a bad way for programmers
to ensure future work.
If my site is cobbled together in jQuery, guess what I'm going to look
for on a FE resume. I need another guy who knows jQuery, so he can
read and debug the crappy code I wrote, and create new crappy code
that I can read and debug. I want someone who knows the jQuery plug-
ins, not some guy that'll come in and write a bunch of new untested
tab systems, tablesorters, Canvas charting systems, modal dialogs, and
tool-tips. If my new programmer quits because he hates the music I
play, or because we have a dangerous-looking homeless guy outside who
regularly threatens his life and throws half-eaten mayonnaise-and-
cheese sandwiches at him every time he walks to his car at night, I'm
going to look for <i>another</i> jQuery programmer to replace him.
And don't underestimate the impact of these libraries on the makers of
browsers. As jQuery shows up in more and more sites, will Microsoft
really want to be seen as releasing an IE8 that is "broken" and
"sucks?" I predict that Microsoft will endeavor to not break jQuery,
Prototype, and YUI sites. Already, people are starting to base their
ideas of "browser speed" on the CSS and XPath selector timings from
various libraries, and upon Javascript performance. It's not just the
speed of layout that counts now. I bet Microsoft will actually
accommodate these libraries so that IE has a little bit less
embarrassing showing in the benchmarks. Do you think it's coincidence
that Microsoft is trying to pass acid tests?
By all means, point out the flaws in the libraries. But if you know
how to write a better library, perhaps spend some of your time
building a better mousetrap and a little less time flapping your
mouthtrap.
It's all changed out from under you. The libraries are THE major force
in Web 2.0 development now. jQuery is in (I believe) Rails now, and
Drupal, and AIR. You may have disdain for them, but it's a quixotic
(and mildly pathetically humorous) jihad you wage against them.
I'm not saying there is not a place for a by-the-books JS programmer
out there--there certainly is. But I think there are already more
places for a library-slinger and every month will bring more. It's
more helpful to council people of how to deal with the libraries than
avoid them.
Lasse Reichstein Nielsen
> It's all changed out from under you. The libraries are THE major force
> in Web 2.0 development now. jQuery is in (I believe) Rails now, and
> Drupal, and AIR. You may have disdain for them, but it's a quixotic
> (and mildly pathetically humorous) jihad you wage against them.
It's expected behavior. DHTML+AJAX is a disruptive technology, and so
are the libraries that enable its use to mortals. The responses to it
fall neatly into the two expected categories: worship and disgust.
Sure, the libraries are not perfect, but they "get the job done" -
delivering results that are "good enough", and that get better with
every iteration.
Personally I would rather use GWT, but I like statically typed
languages :)
/L
--
Lasse Reichstein Nielsen - l...@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
timothytoe
I see three: worship, disgust, and pragmatism.
I fall into the third category. I just can't bring myself to be either
worshipful of or disgusted by a tool that people use to get things
done. I reserve my worship for Jimi Hendrix and Picasso and my disgust
for tubgirl and goatse.
Peter Michaux
> timothytoe <timothy...@gmail.com> writes:
> > It's all changed out from under you. The libraries are THE major force
> > in Web 2.0 development now. jQuery is in (I believe) Rails now, and
> > Drupal, and AIR. You may have disdain for them, but it's a quixotic
> > (and mildly pathetically humorous) jihad you wage against them.
>
> It's expected behavior. DHTML+AJAX is a disruptive technology, and so
> are the libraries that enable its use to mortals. The responses to it
> fall neatly into the two expected categories: worship and disgust.
I think the worshipers are the people who are glad to have someone
else worry about browser bugs. Then they can defer responsibility when
the boss questions about the support complaints.
> Sure, the libraries are not perfect, but they "get the job done" -
> delivering results that are "good enough", and that get better with
> every iteration.
But why do they get better so slowly when so many people are using
them and apparently reading the code? Browser scripting topics like
feature detection have been known for a long time and there are many
well known tests; however, the mainstream libraries opt for
navigator.userAgent frequently.
Peter
timothytoe
>>them and apparently reading the code? Browser scripting topics like
>>feature detection have been known for a long time and there are many
>>well known tests; however, the mainstream libraries opt for
>>navigator.userAgent frequently.
You'd have to hunt one of them down and make them answer to know, but
my assumption is not yours. You appear to assume that they are simply
sniffing to detect features. I assume they are sniffing to get around
browser JS or CSS bugs, or perhaps in some cases to improve
performance or to reduce the size of their often-transmitted
functions. In other words, they probably have reasons that have to do
with real-world trade-offs.
dhtml
> On Feb 15, 1:53 pm, ashore <shor...@gmail.com> wrote:
>
> > Guys, I see a fair bit of negativity around re subject package. Can
> > someone share your views, either way?
>
> <FAQENTRY>
>
There shuold be an article about javascript API design. It should
ideally include an interview or forward by Brendan (long or brief).
This could be discussed by library authors and users of libraries.
> Shouldn't something about Prototype be in the FAQ? It comes up very
> frequently.
An FAQ Entry should be unbiased and informative. There could be a link
to some Prototype JS forums. This topic does come up a lot.
>
> Peter
timothytoe
Now that's a provocative idea!
dhtml
> Until a clj Nazi codes a "correct" library with the capabilities of
> jQuery or Prototype or YUI, those libraries will be continue to be
> used to make websites. And probably to an acccelerating degree.
>
> And don't underestimate the impact of these libraries
They do damage. They do this by relying on browser bugs, sniffing the
userAgent, and then patching it with a hack. What happens if the
browser is to fix the bug? Chris Wilson takes about IE trying to "not
break the web".
<snip blah>
Peter Michaux
That right there is the most solid argument I've seen against hacking.
That is worth having in your sig line.
Peter
Peter Michaux
> On Feb 15, 10:23 pm, Peter Michaux <petermich...@gmail.com> wrote:
>
> > On Feb 15, 1:53 pm, ashore <shor...@gmail.com> wrote:
>
> > > Guys, I see a fair bit of negativity around re subject package. Can
> > > someone share your views, either way?
>
> > <FAQENTRY>
>
> There shuold be an article about javascript API design. It should
> ideally include an interview or forward by Brendan (long or brief).
> This could be discussed by library authors and users of libraries.
Richard Cornford had an interesting comment about Brendan Eich and
browser scripting. It is a bit uncomfortable to read...
<URL: http://groups.google.com/group/comp.lang.javascript/msg/49401dc958fba9fb>
> > Shouldn't something about Prototype be in the FAQ? It comes up very
> > frequently.
>
> An FAQ Entry should be unbiased and informative.
The contributors to this group have solid arguments why Prototype has
problems. Those would need to be pointed out or the FAQ answer would
not encapsulate the general opinions of the contributors. That is
really what the FAQ is for: to reduce typing the same thing over and
over again. If that is "biased" then the entry should be biased.
> There could be a link
> to some Prototype JS forums.
It should have that. It is a genuine frequent answer to "I'm having
trouble with Prototype..."
> This topic does come up a lot.
A lot.
Randy, what do you say? Is a FAQ entry acceptable?
Peter
John Resig
> parse and browser DOM documents is an absolutely essential for making
> JavaScript development easier." -JohnResig: Pro JavaScript Techniques.
> 2006
Oh, interesting - is book errata submitted via usenet sig these days?
http://apress.com/book/errata/275
To help you out the correct quote is:
"Since valid HTML is simply a subset of XML, having an efficient way
to
parse and browse DOM documents is absolutely essential for making
JavaScript development easier." (Chapter 1, Page 8)
--John
timothytoe
On his aptly-named blog (Albatross!), Chris Wilson says, "standards
compliance and not breaking existing websites are, in fact, why I show
up to work."
The albatross around his neck is that buggy old browser, IE. We've
been living with Microsoft's buggy non-compliant slop for years and
years. Chris Wilson knows that's why he has to deal with the hard job
of not breaking websites that did ugly things to get around IE's ugly
things.
And yet he manages to do it with a positive attitude nothing like the
angry, bile-filled, childish vitriol that passes for acceptable
behavior in this group. Inspirational.
As he says, he has two jobs--working towards compliance and not
breaking the web. He performs his job cheerfully. He has a keen sense
of reality, knowing people are using what they have to to get their
jobs done. Good for him.
timothytoe
problems. Those would need to be pointed out or the FAQ answer would
not encapsulate the general opinions of the contributors. That is
really what the FAQ is for: to reduce typing the same thing over and
over again. If that is "biased" then the entry should be biased.
It would be incredibly disappointing to me if the clj FAQ Entry for
Prototype failed to condense the supreme rage that occurs when that
library is mentioned into a hellishly hot and nasty black hole of snot.
dhtml
> On Feb 16, 1:40 pm, Peter Michaux <petermich...@gmail.com> wrote:
>
>
>
> > On Feb 16, 1:32 pm, dhtml <dhtmlkitc...@gmail.com> wrote:
>
> > > On Feb 16, 11:29 am, timothytoe <timothy...@gmail.com> wrote:> Until a clj Nazi codes a "correct" library with the capabilities of
> > > > jQuery or Prototype or YUI, those libraries will be continue to be
> > > > used to make websites. And probably to an acccelerating degree.
>
> > > <snip blah>
>
> > > > And don't underestimate the impact of these libraries
>
>
> angry, bile-filled, childish vitriol that passes for acceptable
> behavior in this group. Inspirational.
>
Childish behavior. Yeah, I know. Flame bait threads are the worst!
Peter Michaux
> nothing like the
> angry, bile-filled, childish vitriol that passes for acceptable
> behavior in this group. Inspirational.
I don't worry about how people behave here unless it is at the level
of racism. Really it is just the content (which is the best on the
internet) that is important to me and I can easily ignore a little
rudeness. The people that are rude often have a good point.
Peter
Richard Cornford
>> "Since valid HTML is simply a subset of XML, having an efficient
>> way to parse and browser DOM documents is an absolutely
>> essential for making JavaScript development easier."
>> -JohnResig: Pro JavaScript Techniques. 2006
>
> Oh, interesting - is book errata submitted via usenet sig these
> days?
It is not errata, the intention is humorous. Though I am not surprised
that you would not see the funny side.
> To help you out the correct quote is:
> "Since valid HTML is simply a subset of XML, having an
> efficient way to parse and browse DOM documents is absolutely
> essential for making JavaScript development easier." (Chapter
> 1, Page 8)
This would be "correct" in a sense I was not previously aware of.
Richard.
--
"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
David Mark
> On Feb 15, 7:42 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > On Feb 15, 9:36 pm, dhtml <dhtmlkitc...@gmail.com> wrote:
>
> > > On Feb 15, 2:36 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > > On Feb 15, 4:53 pm, ashore <shor...@gmail.com> wrote:
>
> > I highly recommend the YUI "compressor" (misnomer), but certainly not
> > YUI itself.
>
> Me too. But why 'misnomer'? It reduces the file size pretty well.
It is a minifier/obfuscator. Compression is the final reduction that
is negotiated by the server and client.
>
> It is a better script than Prototype, but shares many of> the same problems (e.g. browser sniffing, too much sugar, etc.) Then
> > there is that ridiculous "namespace."
>
> Namespacing seemed stupid to me, at first. I mean, these aren't
> "packages", they're just objects.
One flat namespace is all that is required IMO. Its only purpose is
to keep the global namespace clean.
>
> In fact, it confused the junior devs. Check out this example:
>
> YAHOO.namespace("YAHOO.mst.scheduler");
>
> YAHOO.mst.scheduler = function() { ... }
>
> It's entirely possible to do this; to reassing a "package" to a
> function (or any value, or delete it). It's not safe. But neither are
> prototypes.
>
> extend(Sub, Super);
> Sub.prototype = { }; // <- Developer Mistake, just reassinged
> prototype.
>
> extend(Sub, Super, mixin); // <- corrected.
>
> On the other hand, enforcing namespacing has made my code more
> modular. Keeping the global namespace clean is just a small benefit.
I don't see how it helps with modularity.
>
> If I didn't use packages and a build system, unit testing would be a
> lot harder.
I use a build system, but only one namespace. I used to build a
hierarchy ala Yahoo, but came to the conclusion that it was a waste of
time and space.
>
> Writing a library is a lot of work. I want to write a better one. This
> includes:
> modular desing.
> minimal framework.
> building things as simple as possible, but not any simpler.
> unit testing.
> code review.
>
> Now that last one, I could probably use a lot of help on.
Post code here.
>
>
>
> > > What do YOU think?
>
> That was meant for the OP. I'm not sure why this thread was brought up
> even. If s/he's really considering Prototype, he could have done a web
> search, or searched this group. (but I can't search Groups in FF
> again; it's only FF now).
You can't search GG in FF? I assume GG has a new bug then. (?)
>
> > ME? I think I have made that abundantly clear.
>
> You have.
> The only thing worse
>
> > than Prototype is jQuery. YUI is slightly better, but still well
> > south of competent. Using any of these libraries (or God forbid
> > combinations of them) is a bad idea. The average Web developer can
> > achieve lousy results on their own, so what is the benefit of adding
> > 100K of third-party incompetence to the mix?
>
> Most of the F/E jobs here in the bay area want someone who has one of
> the following:
> Prototype, YUI, Dojo, Scriptaculous, jQuery. If you can do that (of
> fake it good enough), you can make decent money.
HR people are clueless when it comes to front-end development. More
often than not (at least around here), their posted requirements
include such things as "x years of DreamWeaver experience." (!) Of
course, the more years of DW experience you have, the less likely you
are to know anything about Web development.
timothytoe
Accepting needless and humorless rudeness will be what keeps clj in
the ghetto.
I would hope that clj could be more relevant and influential. To be
so, it'd have to be a little less consumed by its cult of misanthropic
personalities and stereotypical programmer nervous twitches, and a
little bit more about JavaScript.
David Mark
Who are you responding to? This is not a blog.
> Until a clj Nazi codes a "correct" library with the capabilities of
LOL. Perhaps you haven't been paying attention?
> jQuery or Prototype or YUI, those libraries will be continue to be
> used to make websites. And probably to an acccelerating degree.
Doubtful. Though it will be hard to derail YUI as it is backed by a
behemoth (soon to be swallowed by a bigger behemoth.)
>
> I agree that browser-sniffing is about as appealing as anus-sniffing,
> but programmers in the real-world sometimes need to actually get
Not the "real-world" argument again.
> things done. A smart programmer (as opposed to a perfection-seeking
> zealot} will go with the flow and be able to throw together a website
> quickly as a result. Sure, the website will be brittle, and users with
> obscure browsers will whine, but that's not a bad way for programmers
> to ensure future work.
So the aim of a "smart programmer" is to design an instantly obsolete
Website with the hope that such a design will lead to additional work
fixing their own mistakes? Interesting strategy. Ridiculous and
disingenuous, but interesting.
>
> If my site is cobbled together in jQuery, guess what I'm going to look
Then you have a lousy site.
> for on a FE resume. I need another guy who knows jQuery, so he can
So if you are incompetent, then you would hypothetically look to other
incompetents for help? I don't follow the logic.
> read and debug the crappy code I wrote, and create new crappy code
> that I can read and debug. I want someone who knows the jQuery plug-
> ins, not some guy that'll come in and write a bunch of new untested
> tab systems, tablesorters, Canvas charting systems, modal dialogs, and
LOL. The jQuery UI components are garbage piled on garbage. Even
their developers admit they are crawling with bugs.
> tool-tips. If my new programmer quits because he hates the music I
> play, or because we have a dangerous-looking homeless guy outside who
> regularly threatens his life and throws half-eaten mayonnaise-and-
> cheese sandwiches at him every time he walks to his car at night, I'm
> going to look for <i>another</i> jQuery programmer to replace him.
<em>another</em>
It seems your initial cobbling strategy has led you down the
proverbial "slippery slope."
>
> And don't underestimate the impact of these libraries on the makers of
> browsers. As jQuery shows up in more and more sites, will Microsoft
Microsoft surely doesn't care how many sites use jQuery. And I don't
think the total is headed anywhere but down.
> really want to be seen as releasing an IE8 that is "broken" and
> "sucks?" I predict that Microsoft will endeavor to not break jQuery,
> Prototype, and YUI sites. Already, people are starting to base their
LOL. Have you read about IE8's new versioning feature? The IE-
sniffers are going to have to re-code and re-test everything.
> ideas of "browser speed" on the CSS and XPath selector timings from
> various libraries, and upon Javascript performance. It's not just the
Do tell.
> speed of layout that counts now. I bet Microsoft will actually
> accommodate these libraries so that IE has a little bit less
> embarrassing showing in the benchmarks. Do you think it's coincidence
The biggest problem for IE in the selector benchmarks is that they
don't support XPath for HTML documents. If they add that, they will
catch up. But what does that have to do with incompetently coded
libraries?
> that Microsoft is trying to pass acid tests?
I don't see the connection.
>
> By all means, point out the flaws in the libraries. But if you know
Glad to have your approval.
> how to write a better library, perhaps spend some of your time
> building a better mousetrap and a little less time flapping your
> mouthtrap.
As mentioned, you haven't been paying attention.
>
> It's all changed out from under you. The libraries are THE major force
Out from under whom?
> in Web 2.0 development now. jQuery is in (I believe) Rails now, and
Who cares what is in Rails?
> Drupal, and AIR. You may have disdain for them, but it's a quixotic
> (and mildly pathetically humorous) jihad you wage against them.
"Mildy pathetically humorous?" Can you elaborate?
>
> I'm not saying there is not a place for a by-the-books JS programmer
There's no book.
> out there--there certainly is. But I think there are already more
> places for a library-slinger and every month will bring more. It's
A library-slinger? Does that describe you? Most of this sounds like
an attempt to justify browser scripting incompetence (and planned
obsolescence.)
> more helpful to council people of how to deal with the libraries than
> avoid them.
But the best way to deal with them is to ignore them (and the
misguided zealots who promote them.)
David Mark
> >>But why do they get better so slowly when so many people are using
> >>them and apparently reading the code? Browser scripting topics like
> >>feature detection have been known for a long time and there are many
> >>well known tests; however, the mainstream libraries opt for
> >>navigator.userAgent frequently.
>
> You'd have to hunt one of them down and make them answer to know, but
No need to hunt them down. They pop in here occasionally and attempt
to justify their delusions.
Alternatively, you can gain an insight into their madness by reading
articles like this one:
http://ejohn.org/blog/future-proofing-javascript-libraries/
> my assumption is not yours. You appear to assume that they are simply
> sniffing to detect features. I assume they are sniffing to get around
> browser JS or CSS bugs, or perhaps in some cases to improve
Feature detection and testing can (and should be) done without
resorting to user agent sniffing.
> performance or to reduce the size of their often-transmitted
Then why are these libraries so bloated? And why do they only work in
a handful of modern browsers?
> functions. In other words, they probably have reasons that have to do
> with real-world trade-offs.
LOL. The "real-world" argument again. Is the real world really
devoid of developers who understand JavaScript and browser scripting?
If so, then education, rather than mindless justification, is the
answer.
David Mark
> > "Since valid HTML is simply a subset of XML, having an efficient way to
> > parse and browser DOM documents is an absolutely essential for making
> > JavaScript development easier." -JohnResig: Pro JavaScript Techniques.
> > 2006
And who are you replying to? This is Usenet, not a blog.
>
> Oh, interesting - is book errata submitted via usenet sig these days?http://apress.com/book/errata/275
Will you please stop writing books on browser scripting, at least
until you learn the basics?
>
> To help you out the correct quote is:
> "Since valid HTML is simply a subset of XML, having an efficient way
> to
> parse and browse DOM documents is absolutely essential for making
> JavaScript development easier." (Chapter 1, Page 8)
Other than the grammar, that is hardly an improvement. People who
write books are supposed to know what they are talking about, just as
people who write browser scripting libraries are supposed to know what
they are doing.
David
--
"Additionally, in Internet Explorer, doing object detection checks
can, sometimes, cause actual function executions to occur. For
example:
if ( elem.getAttribute ) {
// will die in Internet Explorer
}
That line will cause problems as Internet Explorer attempts to execute
the getAttribute function with no arguments (which is invalid). (The
obvious solution is to use "typeof elem.getAttribute == 'undefined'"
instead.)" -John Resig: Future-Proofing JavaScript Libraries
timothytoe
things the correct way if insults were not the default form of
greeting on clj.
Or is the entertainment value of belittling them more valuable than
actually trying to convince them that you are correct?
timothytoe
LOL. In the real world people use libraries. I'm all in favor of
education, and I think you do it poorly when you are rude and childish.
David Mark
> Perhaps the library writers could be more easily convinced to see
Who and what are you replying to?
> things the correct way if insults were not the default form of
> greeting on clj.
Au contraire. Insults have been shown to be the default form of
deflecting justifiable criticism of the writers' work. You reap what
you sow.
>
> Or is the entertainment value of belittling them more valuable than
> actually trying to convince them that you are correct?
I've personally never tried to convince any of them of anything. It
has been shown to be a waste of time. I simply warn others to resist
the urge to use delusions as a crutch.
timothytoe
> On Feb 16, 6:13 pm, timothytoe <timothy...@gmail.com> wrote:
>
> Au contraire. Insults have been shown to be the default form of
If that's true, then the library writers who are being childish. So
are we stuck in a hopeless, vicious cycle of insults that no one is
adult enough to break out of?
>>I've personally never tried to convince any of them of anything. It
>>has been shown to be a waste of time. I simply warn others to resist
>>the urge to use delusions as a crutch.
It seems delusional to think that people will stay away from the
libraries. If the situation (by situation, I mean that these libraries
are being used on more and more websites) is to be improved, I believe
engagement with the library writers or the writing of comparably
useful but more robust libraries is the only solution.
If you've given up on helping the library writers improve the
robustness of their libraries, that's fine. Spend your time as you
like. But I still think the rudeness that permeates this newsgroup is
detrimental to its influence. Perhaps the thuggery elicits a few
chuckles from the peanut gallery, but I don't believe it's impressive
otherwise.
David Mark
No, that is an imagined utopia, where there are only three or four
agents to consider and user agent strings are meaningful.
> education, and I think you do it poorly when you are rude and childish.
Well, "TimothyToe", if you consider justifiable criticism and warnings
to be "rude and childish", rather than educational, feel free to drop
out of the class.
timothytoe
Justifiable criticisms and warnings are exactly what I'm looking for,
and are indeed educational. Please, more of that! Personal attacks,
not so much.
David Mark
> On Feb 16, 3:22 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > On Feb 16, 6:13 pm, timothytoe <timothy...@gmail.com> wrote:
>
> > Au contraire. Insults have been shown to be the default form of
> > deflecting justifiable criticism of the writers' work...
>
> If that's true, then the library writers who are being childish. So
> are we stuck in a hopeless, vicious cycle of insults that no one is
> adult enough to break out of?
Not at all. We rarely talk about people here. The discussions
typically revolve around code.
>
> >>I've personally never tried to convince any of them of anything. It
> >>has been shown to be a waste of time. I simply warn others to resist
> >>the urge to use delusions as a crutch.
>
> It seems delusional to think that people will stay away from the
> libraries. If the situation (by situation, I mean that these libraries
> are being used on more and more websites) is to be improved, I believe
> engagement with the library writers or the writing of comparably
> useful but more robust libraries is the only solution.
The latter is the only option I see. The writers of the currently
popular libraries have shown that they have little interest in
learning from their mistakes. As Richard pointed out, the fact that
they rushed out their first attempts at browser scripting and found a
public willing to bet their sites on them, has left many frozen in
time. I would add that praise heaped on them by people who clearly
didn't know any better has given them a false sense of righteousness.
>
> If you've given up on helping the library writers improve the
> robustness of their libraries, that's fine. Spend your time as you
Thanks. I'll do that.
> like. But I still think the rudeness that permeates this newsgroup is
Who wants to be coddled in a technical discussion group? An encounter
group would seem a better place for that.
> detrimental to its influence. Perhaps the thuggery elicits a few
> chuckles from the peanut gallery, but I don't believe it's impressive
> otherwise.
Thuggery? I think you are reaching.
Richard Cornford
> Perhaps the library writers could be more easily convinced
> to see things the correct way if insults were not the
> default form of greeting on clj.
The way in which you read things seems to be having a very big impact on how
your perceive them. Try reading what you see as measured statements by
reasoning individuals and you might find that it is not at all insulting
(even if the comments are likely to be unwelcome to their recipient).
The post you are replying to (have you worked out which post you are
replying to yet?) contains a request (including the word "please"), a very
reasonable statement about the section of a book that I originally quoted
(which was a statement that in terms of semantics and verisimilitude is
about as reasonable as asserting that "Since Atlantic Salmon spawn in the
deep oceans refrigerators operate more effectively with clean shelves"), a
reasonable statement about general expectations of the qualifications of
book authors and library authors (expectations are often disappointed) and
finally cites and obvious (and easily demonstrated) nonsense.
If you don't read that as insulting it promptly stops being insulting, just
critical, and being relentlessly critical is the strength of Usenet.
> Or is the entertainment value of belittling them more
> valuable than actually trying to convince them that you
> are correct?
Think about that. John Resig has written a book called "Pro JavaScript
Techniques". So presumably he believes not only that he knows what he is
talking about but that he is in a position to be telling other people what
they should be doing. If you are going to successfully introduce such an
individual to the notion that they don't know what they are talking about
you are not going to do it by slapping them on the back and telling them how
well they have done.
Richard.
--
"Listing 3-12. Examples of How != and == Differ from !== and ===
// Both of these are true
null == false
0 == undefined" - John Resig: Pro JavaScript Techniques. 2006
timothytoe
replying to yet?
No, could you please help me with that?
timothytoe
Not I. If only there were some possible middle ground between coddling
and eviscerating.
Peter Michaux
> Perhaps the library writers could be more easily convinced to see
> things the correct way if insults were not the default form of
> greeting on clj.
I agree. The critics could word their criticism in a more friendly way
but perhaps that would remove the sense of conviction they feel. The
criticized could also simply ignore the emotionally charged language
and take the criticism as for what it is: a statement about a piece of
code. It takes both sides to fuel the flames. It is so simple to get
along with folks in this group that I'm amazed those claiming social
graces cannot do it. Odd, eh?
Peter
Richard Cornford
>>>have you worked out which post you are replying to yet?
>
> No, could you please help me with that?
OK. You are using Google groups so you start off with a huge disadvantage
because all of its defaults are now geared toward Google's own web forums
rather than Usenet. Web forums tend to be linear and all new posts are
effectively just appended to a list. Usenet is 'threaded', which means that
discussions are tree-like in form. A discussion starts with a posted message
(know as the OP (for Original Post, though OP is also used to refer to the
Original Poster (the individual who makes the original post))), any number
of people may reply that OP and each reply can be subject to other replies,
thus each reply to the OP potentially becomes a branch in the tree structure
of the thread (though it may end up being a leaf if it does not get
responded to).
Most of the people who regularly use the group are doing so through
dedicated news servers (provided by their ISPs or as commercial service by
third parties (the days of free public news servers seem to have gone)) and
are using 'newsreader' software that is geared to presenting Usenet in its
threaded form.
This is not to say that Google groups interface cannot show Usenet in its
threaded form. Go to a discussion listing and click on the word 'Options' at
the right end of the grey bar that contains the subject to expand some
'links' that provide display options. One of those options is labelled "View
as tree", and clicking it shows Google's best effort at a tree display of
the thread. That should make things clearer.
It is also a good idea to also use the 'fixed font' option because ascii art
and various common text highlighting strategies rely upon the reader using a
fixed width font, as otherwise there is no telling how wide the reader's
characters (especially spaces) are. Also, avoid using tabs to indent code
(use (possibly multiple) spaces instead) because the display capabilities
and defaults of newsreaders when handling tabs varies enormously.
If you want to see the mechanism behind Usenet threading use the "more
options" 'link' at the top of each message and click the "Show original"
option. This shows the individual message with its headers (though google
always mangle everything that looks like an e-mail address). Not that each
message has a Message-ID header that uniquely identifies the message, and a
References header that describes its context in the tree of the thread by
listing the chain of Message-ID from the original post at the beginning to
the message that the current message is responding to at the end.
While you are there note that a Content-Type header should exist and specify
"text/plain". Usenet is normally (and comp.lang.javascript always) a plain
text medium (no HTML posts, mixed content posts or attachments here). That
explains why you don't need PRE elements in order to retain text formatting,
and why <i>xxx</i> doesn't work. There are Usenet conventions for
*emphasis*, _underline_ and /stress/ in plain text messages.
While you are in the 'options' at the top of each message, to the far left
is a 'Reply' option that has historically been the most effective at
providing the previous message body in a quoted form and replying
effectively to the specific message. There have been many (often extended)
periods when the similar link at the bottom of the message has either failed
to reply to the specific message or not provide the previous message in
quoted form. Remember that Google's javascript developers (and particularly
the ones working on google groups) are quite astoundingly bad, so you can
consider yourself lucky if anything works properly/consistently over any
period of time. Despite that you will be held responsible for what you post,
so keep your eyes open for when google f**k-up, because they will (and
blaming them will not get you very far).
In that context, be particularly cautions of google's habit of inserting
statements like "Show quoted text" into the material they present as a
'quote' of the pervasions message. The accuracy of any quotes you post are
your responsibility. You may edit the irrelevant/superfluous (appropriately
marking such edits so there is no doubt about what you have done) but you
must not change the wording of whatever you do quite and you certainly must
not add anything because that would be (literally or by implication) putting
words into other people's moths and be disingenuous at the very least.
Remember, it is no good blaming google, you are 100% responsible for
everything _you_ post.
There is a conventional/traditional form for Usenet posts. You can find out
more about this through the group's FAQ (hint: it is in the faq notes). We
expect to see that form followed here. The reasoning goes; A well
formed/complete Usenet post requires a little discipline, while browser
scripting requires a lot of discipline, so an individual who cannot
demonstrate the former is going to be a hopeless case with regard to the
latter. That may seem harsh and a little arbitrary but experience has not
invalidated it.
Richard.
--
"When performing string concatenation the result is always a new string
object rather than a modified version of the original string." - John Resig:
Pro JavaScript Techniques. 2006
timothytoe
wrote:
Ah, I see. Some of you are still reading on Usenet. I've not done it
that way for a few years. I understand the confusion now. Makes
perfect sense. Thanks.
RobG
>> Richard.
>> --
>> "When performing string concatenation the result is always a new string
>> object rather than a modified version of the original string." - John Resig:
>> Pro JavaScript Techniques. 2006
>
> Ah, I see. Some of you are still reading on Usenet. I've not done it
> that way for a few years. I understand the confusion now. Makes
> perfect sense. Thanks.
Other things that Google Groups (GG) does badly are:
1. Not automatically trim signatures
2. Remove the trailing space from "-- " which signifies
the start of a signature so that news readers can't find the
signature either.
I use a minimal signature when posting via GG to help attenuate issues
arising from that.
--
Rob
"We shall not cease from exploration, and the end of all our
exploring will be to arrive where we started and know the
place for the first time." -- T. S. Eliot
Richard Cornford
> On Feb 16, 5:55 pm, Richard Cornford wrote:
<snip>
>> ...We expect to see that form followed here. The reasoning
>> goes; A well formed/complete Usenet post requires a little
>> discipline, while browser scripting requires a lot of
>> discipline, so an individual who cannot demonstrate the
>> former is going to be a hopeless case with regard to the
>> latter. That may seem harsh and a little arbitrary but
>> experience has not invalidated it.
> Ah, I see.
"Said the blind man ... "
> Some of you are still reading on Usenet.
If you are reading this then you are reading Usenet. There is no "some"
about it.
> I've not done it that way for a few years. I understand
> the confusion now. Makes perfect sense. Thanks.
Your are not scoring that well yet.
"Could do better" ;-)
Richard.
--
"Since the use of JavaScript in nonbrowser settings (e.g., server-side
JavaScript) is still rather experimental, the feature set of JavaScript is
still very browser-centric. Thus, the features available in JavaScript are
very closely tied to how browsers evolve and which features they (or their
users) deem as the most important." - John Resig: Pro JavaScript Techniques.
2006
Richard Cornford
> Until a clj Nazi codes a "correct" library with the capabilities
> to be used to make websites. And probably to an acccelerating
> degree.
>
> anus-sniffing, but programmers in the real-world sometimes need
> a perfection-seeking zealot} will go with the flow and be able
> to throw together a website quickly as a result.
If you go back 5 or 6 years there is (or was) a "real world" practice that
had pretty much all of the characteristics that we see paraded before us in
favour of the otherwise objectively and demonstrably bad library code.
That practice was using the - eval - function to retrieve object references
using runtime assembles string representations of dot notation property
accessors. It had everything you might want; there were literally millions
of examples in use on the Internet, including on all of the sites of all of
the often-listed "major players" and in the majority of the 'popular
libraries' of the time. It worked, it got the job done and it allowed people
with a limited understanding of javascript to throw together web sites that
they would not have been able to create otherwise. (Indeed in relation to
browser sniffing it also has the advantages of a formal technical
justification and actually being reliable). It worked just fine then, it
works today, and it is going to still work tomorrow.
It is gone now. You don't see it being done in anything but the very oldest
code, and you don't see anyone recommending it as a practice any more. Why
is that? Could it be that somewhere there were people who could recognise a
bad idea when they observed it? People who were not interested in following
the crowd or accepting the "a million monkeys can't be wrong" argument.
Perfectionist zealots who kept on saying "this is stupidly inefficient",
"this is totally unnecessary" and "you should be doing this instead" until
eventually enough people understood the folly sufficiently for its
prorogation to cease and for the practice to die out.
Did you go and look at the "Why should I eschew prototype.js?" thread I
referred to? Did you see the code I highlighted there demonstrating that the
author of the (at the time) latest version of Prototype.js did not
understand how the code he was writing worked, and had ended up with
something that, where it worked at all, worked only by coincidence? It is
not a subjective question, and it is not a matter of opinion, it is in the
code for all to see; Prototype.js was written by people who don't understand
javascript. They don't understand its theory and they don't comprehend its
reality. Now if, knowing that, someone still thinks it is going to be a good
idea to use Prototype.js then more fool them, I cannot stop them. But that
is not a reason for me to stop telling it like it is.
Have you looked at the John Resig material I have been quoting today? Have
you seen the common theme?
> Sure, the website will be brittle, and users with
> obscure browsers will whine, but that's not a bad way
> for programmers to ensure future work.
Professionalism? Did you actually ask the client how they feel about your
design strategy?
Richard.
--
"Luckily, there exists an excellent resource for explaining how closures
work in JavaScript: "JavaScript Closures" by Jim Jey at
http://jibbering.com/faq/faq_notes/closures.html." - John Resig: Pro
JavaScript Techniques. 2006
Peter Michaux
> I agree that browser-sniffing is about as appealing as anus-sniffing,
> but programmers in the real-world sometimes need to actually get
> things done. A smart programmer (as opposed to a perfection-seeking
> zealot} will go with the flow and be able to throw together a website
> quickly as a result. Sure, the website will be brittle, and users with
> obscure browsers will whine, but that's not a bad way for programmers
> to ensure future work.
Or perhaps no work at all.
Peter
FAQEditor
> On Feb 15, 1:53 pm, ashore <shor...@gmail.com> wrote:
>> Guys, I see a fair bit of negativity around re subject package. Can
>> someone share your views, either way?
>
> <FAQENTRY>
>
> Shouldn't something about Prototype be in the FAQ? It comes up very
> frequently.
I have not read the rest of the thread yet, so it may be mentioned. But,
the last time an FAQ Entry was requested on Prototype, it was turned
down. If you list Prototype and the problems with it, then you need to
list YUI, Mootools, etc.. and that becomes way too intensive for the
FAQ. What could be listed is a link to this thread about Prototype and
then links to the other library threads.
All in all, I still think it is a bad idea though.
--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
FAQ Notes: http://www.jibbering.com/faq/faq_notes/faq_notes.html
ECMAScript Language Specification via FAQ2.6
FAQEditor
<snip>
> Randy, what do you say? Is a FAQ entry acceptable?
Fine by me. See my other reply. Somebody writes a Prototype entry and
the group wants it in the FAQ, I will add it :)
David Mark
wrote:
> timothytoe wrote:
> > Until a clj Nazi codes a "correct" library with the capabilities
> > of jQuery or Prototype or YUI, those libraries will be continue
> > to be used to make websites. And probably to an acccelerating
> > degree.
>
> > I agree that browser-sniffing is about as appealing as
> > anus-sniffing, but programmers in the real-world sometimes need
> > to actually get things done. A smart programmer (as opposed to
> > a perfection-seeking zealot} will go with the flow and be able
> > to throw together a website quickly as a result.
>
> If you go back 5 or 6 years there is (or was) a "real world" practice that
> had pretty much all of the characteristics that we see paraded before us in
> favour of the otherwise objectively and demonstrably bad library code.
>
> That practice was using the - eval - function to retrieve object references
> using runtime assembles string representations of dot notation property
> accessors. It had everything you might want; there were literally millions
> of examples in use on the Internet, including on all of the sites of all of
> the often-listed "major players" and in the majority of the 'popular
> libraries' of the time. It worked, it got the job done and it allowed people
> with a limited understanding of javascript to throw together web sites that
> they would not have been able to create otherwise. (Indeed in relation to
> browser sniffing it also has the advantages of a formal technical
> justification and actually being reliable). It worked just fine then, it
> works today, and it is going to still work tomorrow.
That one must have passed me by.
>
> It is gone now. You don't see it being done in anything but the very oldest
> code, and you don't see anyone recommending it as a practice any more. Why
> is that? Could it be that somewhere there were people who could recognise a
> bad idea when they observed it? People who were not interested in following
> the crowd or accepting the "a million monkeys can't be wrong" argument.
> Perfectionist zealots who kept on saying "this is stupidly inefficient",
> "this is totally unnecessary" and "you should be doing this instead" until
> eventually enough people understood the folly sufficiently for its
> prorogation to cease and for the practice to die out.
Let us hope the same happens to Prototype, jQuery, etc. It looks like
IE8 is going to help out quite a bit in this regard.
>
> Did you go and look at the "Why should I eschew prototype.js?" thread I
> referred to? Did you see the code I highlighted there demonstrating that the
> author of the (at the time) latest version of Prototype.js did not
> understand how the code he was writing worked, and had ended up with
> something that, where it worked at all, worked only by coincidence? It is
Yes, the nested function declarations in that example should be enough
to convince people that the million monkeys behind it haven't got a
Shakespeare among them.
You would think that an open source project with so many eyes on it
would be relatively free of such obvious gaffes. Wasn't the number of
watchful contributors involved a recent argument posed in favor of
using jQuery? IIRC, that was right before it came to light that after
two plus years, not one of them had spotted the typeof xyz == 'array'
goof, even after the function in question had been posted (twice) in a
thread involving the original author (who was too busy being snotty to
read is own cited code.) I don't think we heard from him again, until
he dropped by to ineffectually ridicule one of your signatures.
> not a subjective question, and it is not a matter of opinion, it is in the
That didn't stop several participants from attempting argue in favor
of the code in question. The fact that they didn't understand the
issues with it provided no barrier to entry for them and the clarity
of your position was ultimately muddied. I figure that many who read
that thread will get lost in the maze of replies and assume that it
really was just a matter of opinion.
> code for all to see; Prototype.js was written by people who don't understand
> javascript. They don't understand its theory and they don't comprehend its
> reality. Now if, knowing that, someone still thinks it is going to be a good
> idea to use Prototype.js then more fool them, I cannot stop them. But that
> is not a reason for me to stop telling it like it is.
And you shouldn't. It isn't just their personal choice. It affects
everyone who browses the Web. It seems like every time I try to
reference anything on the Internet these days, my progress is impeded
by script errors, aborted popup windows, browser freezes, botched
validation logic, malformed layouts (my favorite is the in-page popup
with a single off-screen close button that can't be scrolled to),
inefficient keypress listeners (takes ten years to type ten letters),
broken back buttons, etc., etc. Disabling scripting is almost never
an answer as most of these Ajax nuts are convinced that they don't
need to design for that eventuality. Granted, these issues cannot all
be laid at Prototype's doorstep, but they illustrate the obvious fact
that people who don't understand browser scripting should not be
charged with writing interactive Web pages (or God forbid Web
applications.) Piling on a 100K of incompetently written script does
not help, but typically makes things worse.
>
> Have you looked at the John Resig material I have been quoting today? Have
Yes. LOL. You've got to be cruel to kind.
> you seen the common theme?
Ignorance?
>
> > Sure, the website will be brittle, and users with
> > obscure browsers will whine, but that's not a bad way
> > for programmers to ensure future work.
>
> Professionalism? Did you actually ask the client how they feel about your
> design strategy?
Yeah, right. Assuming a client exists (poor them), I doubt they would
be happy with such a nefarious strategy. And what is this
undercurrent of anger toward people who use "obscure browsers" (read:
handheld devices) or disable scripting? Is everything that goes wrong
with incompetently designed sites the fault of the user? Same for
those who point out problems with the libraries. As much as the
authors and proponents of the major libraries like to talk about
reality, they sure get antsy when someone pokes holes in their
blinders.
>
> Richard.
> --
> "Luckily, there exists an excellent resource for explaining how closures
> work in JavaScript: "JavaScript Closures" by Jim Jey athttp://jibbering.com/faq/faq_notes/closures.html." - John Resig: Pro
> JavaScript Techniques. 2006
I assume the "Jim Jey" attribute is a typo, but of course, the
original author of the quote misspelled "Richard Cornford." LOL.
Peter Michaux
> Peter Michaux said the following on 2/16/2008 4:47 PM:
>
> <snip>
>
> > Randy, what do you say? Is a FAQ entry acceptable?
>
> Fine by me. See my other reply. Somebody writes a Prototype entry and
> the group wants it in the FAQ, I will add it :)
How about just a few links to some of these long Prototype threads
rather than trying to get an agreement on an actual critic?
Peter
Randy Webb
>>> The contributors to this group have solid arguments why Prototype has
> problems. Those would need to be pointed out or the FAQ answer would
> not encapsulate the general opinions of the contributors. That is
> really what the FAQ is for: to reduce typing the same thing over and
> over again. If that is "biased" then the entry should be biased.
>
> It would be incredibly disappointing to me if the clj FAQ Entry for
> Prototype failed to condense the supreme rage that occurs when that
> library is mentioned into a hellishly hot and nasty black hole of snot.
If this group decides that an entry in the FAQ should be added for
Prototype.js, then it will reflect the current thinking about
Prototype.js in this group. If the truth hurts peoples feelings, then
they need to learn to bear the pain. My personal feelings about a
subject have never entered into the way an entry is written, modified,
or removed.
--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
FAQEditor
Adding an entry isn't a big deal. It just a few lines pasted into a
file. The rest is automated. As for whether it should be in there or
not, let me see if I can find the thread where it was talked about last
time.
<FAQENTRY>
What are some of the problems with general purpose javascript libraries?
The consensus of regular posters in comp.lang.javascript hold the view
that most, if not all, general purpose libraries are of a sufficient
lack of quality as to make them useless in a cross-browser environment.
These are a few of the discussions that have taken place in the past
about libraries available for general public use:
Prototype.js:
<URL here>
<URL here>
<URL here>
YUI:
<URL here>
<URL here>
Mootools:
<URL here>
<URL here>
Etc..
That is a start.
I haven't been following your RFC threads lately, anything FAQ related
in them?
Peter Michaux
> Peter Michaux said the following on 2/17/2008 1:57 AM:
>
> > On Feb 16, 10:44 pm, FAQEditor <clj...@comcast.net> wrote:
> >> Peter Michaux said the following on 2/16/2008 4:47 PM:
>
> >> <snip>
>
> >>> Randy, what do you say? Is a FAQ entry acceptable?
> >> Fine by me. See my other reply. Somebody writes a Prototype entry and
> >> the group wants it in the FAQ, I will add it :)
>
> > How about just a few links to some of these long Prototype threads
> > rather than trying to get an agreement on an actual critic?
>
> Adding an entry isn't a big deal. It just a few lines pasted into a
> file. The rest is automated. As for whether it should be in there or
> not, let me see if I can find the thread where it was talked about last
> time.
>
> <FAQENTRY>
>
> What are some of the problems with general purpose javascript libraries?
>
> The consensus of regular posters in comp.lang.javascript hold the view
> that most, if not all, general purpose libraries are of a sufficient
"mainstream, downloadable general purpose"?
> lack of quality as to make them useless in a cross-browser environment.
> These are a few of the discussions that have taken place in the past
> about libraries available for general public use:
>
> Prototype.js:
> <URL here>
> <URL here>
> <URL here>
>
> YUI:
> <URL here>
> <URL here>
>
> Mootools:
> <URL here>
> <URL here>
>
> Etc..
>
> That is a start.
I think it is close enough to the group regular's general feeling. I
don't particularly agree with the social skills displayed in the
threads to be linked but they sure do express the sentiment of the
most vocal regulars.
> I haven't been following your RFC threads lately, anything FAQ related
> in them?
I don't think so. Some interesting minutia about cross-browser testing
host objects and the ECMAScript spec. I know you really like that
stuff.
Peter
FAQEditor
> As for whether it should be in there or not, let me see
> if I can find the thread where it was talked about last
> time.
Searching for prototype.js and FAQENTRY doesn't find the thread I am
remembering. I will try finding it tomorrow if nobody else does first.
The general idea of the thread I am hunting was that if you listed
Prototype, then you would need to list the rest and it goes to the issue
that Richard was talking about where it could become a never ending list
as more libraries come out.
What might be better, to keep the FAQ entry size down, is to simply link
to a Notes page where it can list different libraries and the
discussions here about them. That way, as libraries come out or new
threads are started about them, the FAQ doesn't grow every time a
library is discussed.
Randy Webb
> On Feb 16, 11:21 pm, FAQEditor <clj...@comcast.net> wrote:
<snip>
>> What are some of the problems with general purpose javascript libraries?
>>
>> The consensus of regular posters in comp.lang.javascript hold the view
>> that most, if not all, general purpose libraries are of a sufficient
>
> "mainstream, downloadable general purpose"?
I think that implies, or might, that non-mainstream libraries don't
suffer many of the problems that mainstream libraries do.
<snip>
>
> I think it is close enough to the group regular's general feeling. I
> don't particularly agree with the social skills displayed in the
> threads to be linked but they sure do express the sentiment of the
> most vocal regulars.
You going to volunteer to hunt and weed out the threads for links?
>> I haven't been following your RFC threads lately, anything FAQ related
>> in them?
>
> I don't think so. Some interesting minutia about cross-browser testing
> host objects and the ECMAScript spec. I know you really like that
> stuff.
You know me too well :)
I think that Matt's libraries should be included as well if there are
any threads where they are discussed. From what I have seen though, when
Matt finds out about a problem with one of his, he tries to correct it.
--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Peter Michaux
> Peter Michaux said the following on 2/17/2008 2:30 AM:
>
> > On Feb 16, 11:21 pm, FAQEditor <clj...@comcast.net> wrote:
>
> <snip>
>
> >> What are some of the problems with general purpose javascript libraries?
>
> >> The consensus of regular posters in comp.lang.javascript hold the view
> >> that most, if not all, general purpose libraries are of a sufficient
>
> > "mainstream, downloadable general purpose"?
>
> I think that implies, or might, that non-mainstream libraries don't
> suffer many of the problems that mainstream libraries do.
Well, if it isn't right, we can be sure Dr Stockton will mention it to
you soon and frequently.
> > I think it is close enough to the group regular's general feeling. I
> > don't particularly agree with the social skills displayed in the
> > threads to be linked but they sure do express the sentiment of the
> > most vocal regulars.
>
> You going to volunteer to hunt and weed out the threads for links?
I can find some.
> >> I haven't been following your RFC threads lately, anything FAQ related
> >> in them?
>
> > I don't think so. Some interesting minutia about cross-browser testing
> > host objects and the ECMAScript spec. I know you really like that
> > stuff.
>
> You know me too well :)
>
> I think that Matt's libraries should be included as well if there are
> any threads where they are discussed. From what I have seen though, when
> Matt finds out about a problem with one of his, he tries to correct it.
Matt did mention in one of the recent, colossal jQuery threads that he
uses jQuery at work and doesn't have much time for his own code
anymore. I don't know if he is keeping up to date.
I don't think Matt's library should be mentioned because it is not a
frequently asked question. Also there is not a consensus that Matt's
library is bad (actually it is probably the contrary) so I wouldn't
want to imply anything about his code.
Peter
Peter Michaux
> On Feb 16, 11:35 pm, Randy Webb <HikksNotAtH...@aol.com> wrote:
>
> > Peter Michaux said the following on 2/17/2008 2:30 AM:
>
> > > On Feb 16, 11:21 pm, FAQEditor <clj...@comcast.net> wrote:
>
> > <snip>
>
> > >> What are some of the problems with general purpose javascript libraries?
>
> > >> The consensus of regular posters in comp.lang.javascript hold the view
> > >> that most, if not all, general purpose libraries are of a sufficient
>
> > > "mainstream, downloadable general purpose"?
>
> > I think that implies, or might, that non-mainstream libraries don't
> > suffer many of the problems that mainstream libraries do.
>
> Well, if it isn't right, we can be sure Dr Stockton will mention it to
> you soon and frequently.
>
> > > I think it is close enough to the group regular's general feeling. I
> > > don't particularly agree with the social skills displayed in the
> > > threads to be linked but they sure do express the sentiment of the
> > > most vocal regulars.
>
> > You going to volunteer to hunt and weed out the threads for links?
>
> I can find some.
I didn't say I was going to spend my life compiling them all.
These are ones I remember and all involve regulars and the general
opinions in the group. In some of the threads more than one library is
mentioned but I've grouped by the library that took the hardest hit.
Prototype
http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/181f03af63cc81c2
http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/2072e63631688fc4
jQuery
http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/415949d1bcce6e6a
YUI
http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/fefce445673d7135
http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/37c2a1b93d566b74
Peter
dhtml
library does not appear to be maintained.
Is there a bug count that, say, Prototype exceeds, yet Javascript
toolbox doesn't?
Which library should I use?
would be a good FAQEntry.
It could cover a range of things from: What are your needs/what are
you trying to accomplish? Or all or none of the following:
Library: jQuery :
overview: <BLAH>
pro: small, simple API
con: oversimplified; code behind methods is complicated, difficult
to test
<UNBIASED EXAMPLE>
known bugs /issues: <UNBIASED EXAMPLE>
highlights:
Then the reader can make his onw decision.
Pick Popular libraries that getasked about frequently. EXT, YUI,
Lasse Reichstein Nielsen
> But why do they get better so slowly when so many people are using
> them and apparently reading the code? Browser scripting topics like
> feature detection have been known for a long time and there are many
> well known tests; however, the mainstream libraries opt for
> navigator.userAgent frequently.
According to the author of JQuery there are cases where it's the only
thing that "works". You can't test for rendeing bugs by feature detection.
You can have browsers that implement a feature so badly that you must
avoid it, even if feature detection detects it.
There is no easy way to make two pieces of crap compatible :)
/L
--
Lasse Reichstein Nielsen - l...@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Lasse Reichstein Nielsen
> On Feb 16, 6:17 pm, timothytoe <timothy...@gmail.com> wrote:
>> LOL. In the real world people use libraries. I'm all in favor of
>
> No, that is an imagined utopia, where there are only three or four
> agents to consider and user agent strings are meaningful.
No, that's the real world, where people don't care if it works in
anything but IE and Mozilla, and are happy if it also works in
Safari, Opera and Konqueror too. That real world, which is nowhere
near the utopia where everybody writes web pages that work in all
browsers.
Richard Cornford
> Peter Michaux <peterm...@gmail.com> writes:
>
>> But why do they get better so slowly when so many people
>> are using them and apparently reading the code? Browser
>> scripting topics like feature detection have been known
>> for a long time and there are many well known tests;
>> however, the mainstream libraries opt for
>> navigator.userAgent frequently.
>
> According to the author of JQuery there are cases where it's
> the only thing that "works".
While looking through the source code of various libraries (JQery include) I
keep encountering comments that assert weird and incredible things about web
browsers. Things that I either know to be false or things that, if they were
true, would have been raised here long ago (30,000 posts a year for more
than ten years) and so I would know the truth of. None of these comments
every go into details and most are immediately followed by a crazy user
agent string driven set of branching. My impression is that these are
manifestations of misconceptions in circumstances where the author does not
have the experience or analytical skills to move from observing a symptom in
their code to understanding the real cause and effect relationships behind
it.
Thus when I hear "According to the author of ... " I am going to take that
with a large pinch of salt. It is showing the code that demonstrates a
phenomenon that proves the truth of any such claim (or reveals the
misconceptions behind it).
> You can't test for rendeing bugs by feature
> detection.
You can't test for all rendering bugs (probably most), but scripts do have
access to some information about the web page as it is actually displayed
and so can apply some testing to that.
> You can have browsers that implement a feature so badly
> that you must avoid it, even if feature detection detects it.
And you can design to avoid issues. While you were away (and its good to see
you back :) there were long discussions about an - isFunction - method from
JQuery, which in tern was significant because it was employed by a method in
JQuery that attempted to implement a sort of 'method overloading' where it
was passed host object references in some contexts and user defined function
references in others. The problem came when it encountered the first of the
many browsers where collections are implemented as functions (are callable
and have =- typeof - equal to 'function'). The parade of misconceptions and
assumptions that lead to this position ended in attempts to make an -
isFunction - test that 'did what we want' rather than having any
relationship with any aspect of what a function is or what a function does.
But that was all just (mostly unsuccessful) hacking to get round an
underlying but avoidable design mistake; the 'method overloading' emulation
was not a good idea in the circumstances (and usually isn't). If that
direction had never been taken the browser sniffing in the hacks necessary
to get the - isFunction - test to do what was needed of it would not have
been necessary.
> There is no easy way to make two pieces of crap compatible :)
Yes, but remember that JQuery only works with the default configurations of
3 or 4 browsers.
Richard.
--
"Additionally, an object can contain a set of properties, all of which are
simply references to other objects (such as strings, numbers, arrays,
etc.)." - John Resig: Pro JavaScript Techniques. 2006
Peter Michaux
> Peter Michaux <petermich...@gmail.com> writes:
> > But why do they get better so slowly when so many people are using
> > them and apparently reading the code? Browser scripting topics like
> > feature detection have been known for a long time and there are many
> > well known tests; however, the mainstream libraries opt for
> > navigator.userAgent frequently.
>
> According to the author of JQuery there are cases where it's the only
> thing that "works". You can't test for rendeing bugs by feature detection.
> You can have browsers that implement a feature so badly that you must
> avoid it, even if feature detection detects it.
I think that is a cop out to justify giving up looking for a better
test.
<URL: http://ejohn.org/blog/building-a-javascript-library/#comment-232407>
> There is no easy way to make two pieces of crap compatible :)
True. It isn't always easy and we have to do it for many more than
just two!
Peter
Matt Kruse
> Matt did mention in one of the recent, colossal jQuery threads that he
> uses jQuery at work and doesn't have much time for his own code
> anymore. I don't know if he is keeping up to date.
I don't read this group as intensely anymore, but I'm flattered that I
am remembered! ;) I will now proceed to wander off-topic...
I do not write much code anymore, either at home or work. You know how
it goes, all genius must happen before wife and kids, and I'm way too
late for that. I consider most of my code to be pretty solid for what
it does, and there isn't a lot of need to re-visit it. Certainly some
of it should be removed or re-written, since I now know better
practices and could create a better product. But for the most part, I
think a lot of my previous work (certainly not all of it) is still
pretty good.
I have updated some of my code recently, like the table sorting/
filtering/paging library, but I haven't put all the latest stuff out
there. I just don't have much time anymore, or to be honest, much
interest. I use jQuery quite a bit at work and for personal stuff. Not
because it's perfect, because it's certainly not, but because I know
my limited scope and requirements and the trade-off of using a single
library that does everything _I_ need correctly in the environment _I_
know I have versus writing things from scratch definitely leans in the
favor of the jQuery approach.
So lately some of my efforts have been put into writing jquery plugins
for personal/work purposes, or fixing existing plugins, or patching
jquery code to work as I would like it to.
I also spend more time working on Gadgets these days, which I find
more interesting :)
http://www.google.com/ig/authors?hl=en&author=gadget%40mattkruse.com
> I don't think Matt's library should be mentioned because it is not a
> frequently asked question. Also there is not a consensus that Matt's
> library is bad (actually it is probably the contrary) so I wouldn't
> want to imply anything about his code.
My code may be known in small circles, but nowhere close to libraries
like jquery, prototype, etc. I doubt that anyone looking for pros/cons
of "major libraries" would be looking for comments on my code.
Matt Kruse
John G Harris
Cornford wrote:
<snip>
>putting
>words into other people's moths
<snip>
I like it :-)
John
--
John Harris
timothytoe
Like a mouth to the flame...
Thomas 'PointedEars' Lahn
> Until a clj Nazi codes a "correct" library with the capabilities of
> jQuery or Prototype or YUI, those libraries will be continue to be
Godwin's Law. You lose.
PointedEars, with a fitting random signature
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300...@news.demon.co.uk>
Thomas 'PointedEars' Lahn
> On Feb 16, 7:01 am, dhtml <dhtmlkitc...@gmail.com> wrote:
>> On Feb 15, 7:42 pm, David Mark <dmark.cins...@gmail.com> wrote:
>>> Then there is that ridiculous "namespace."
>> Namespacing seemed stupid to me, at first. I mean, these aren't
>> "packages", they're just objects.
>
> One flat namespace is all that is required IMO. Its only purpose is
> to keep the global namespace clean.
There are no namespaces in implementations of ECMAScript up to Edition 3
Final. In such a highly dynamic language, it borders to self-delusion to
think that those "namespaces" uninitiated people talk about would
automatically help to keep the global "namespace" clean. That they do not
can be be readily observed with the number of "namespaced" libraries (and
mindless accreditions of those in script-kiddie Web sites) which fail to
declare identifiers as local variables.
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
Thomas 'PointedEars' Lahn
> To help you out the correct quote is:
> "Since valid HTML is simply a subset of XML, having an efficient way
> to parse and browse DOM documents is absolutely essential for making
> JavaScript development easier." (Chapter 1, Page 8)
Are you serious and currently capable of cognitive reasoning? Then you
should be able to read both the HTML and the XML Specifications and
recognize that what you wrote is complete utter nonsense.
JFYI: HTML is an application of SGML. XML is a subset of SGML. XHTML is
an application of XML. And finally, your statement is, even if corrected
*accordingly*, a non sequitur.
I can only second what was said before: you really should stop with
everything that involves Web software development until you got the very
basics, the above included. Any other course of action is a recipe for
disaster, as (unfortunately) jQuery readily reveals.
David Mark
> Peter Michaux <petermich...@gmail.com> writes:
> > But why do they get better so slowly when so many people are using
> > them and apparently reading the code? Browser scripting topics like
> > feature detection have been known for a long time and there are many
> > well known tests; however, the mainstream libraries opt for
> > navigator.userAgent frequently.
>
> According to the author of JQuery there are cases where it's the only
> thing that "works". You can't test for rendeing bugs by feature detection.
> You can have browsers that implement a feature so badly that you must
> avoid it, even if feature detection detects it.
It is important to make the distinction between feature testing and
feature detection. The former can weed out or compensate for broken
features, whereas the latter can only tell if the features are
present.
>
> There is no easy way to make two pieces of crap compatible :)
Nobody said it is easy. The oft-repeated myth is that it is
impossible.
David Mark
> David Mark <dmark.cins...@gmail.com> writes:
> > On Feb 16, 6:17 pm, timothytoe <timothy...@gmail.com> wrote:
> >> LOL. In the real world people use libraries. I'm all in favor of
>
> > No, that is an imagined utopia, where there are only three or four
> > agents to consider and user agent strings are meaningful.
>
> No, that's the real world, where people don't care if it works in
What the developers care about is immaterial.
> anything but IE and Mozilla, and are happy if it also works in
That isn't the real world for users of other agents.
> Safari, Opera and Konqueror too. That real world, which is nowhere
> near the utopia where everybody writes web pages that work in all
> browsers.
The imagined utopia is a world where mobile devices, set top boxes and
other off-brand browsers do not exist. That does not describe the
public Internet today and will diverge futher from reality in the
future. It is best to get a handle on it now.
David Mark
wrote:
> David Mark wrote:
> > On Feb 16, 7:01 am, dhtml <dhtmlkitc...@gmail.com> wrote:
> >> On Feb 15, 7:42 pm, David Mark <dmark.cins...@gmail.com> wrote:
> >>> Then there is that ridiculous "namespace."
> >> Namespacing seemed stupid to me, at first. I mean, these aren't
> >> "packages", they're just objects.
>
> > One flat namespace is all that is required IMO. Its only purpose is
> > to keep the global namespace clean.
>
> There are no namespaces in implementations of ECMAScript up to Edition 3
Thanks for that. I think we all know what the term "namespace" means
in the context of this discussion.
> Final. In such a highly dynamic language, it borders to self-delusion to
> think that those "namespaces" uninitiated people talk about would
> automatically help to keep the global "namespace" clean. That they do not
> can be be readily observed with the number of "namespaced" libraries (and
> mindless accreditions of those in script-kiddie Web sites) which fail to
> declare identifiers as local variables.
Incompetent implementations aside, adding methods to a single globally
declared object generates far less pollution than creating a new
property of THE Global Object for every function in a library.
Thomas 'PointedEars' Lahn
> [...] Thomas 'PointedEars' Lahn [...] wrote:
>> David Mark wrote:
>>> On Feb 16, 7:01 am, dhtml <dhtmlkitc...@gmail.com> wrote:
>>>> On Feb 15, 7:42 pm, David Mark <dmark.cins...@gmail.com> wrote:
>>>>> Then there is that ridiculous "namespace."
>>>> Namespacing seemed stupid to me, at first. I mean, these aren't
>>>> "packages", they're just objects.
>>> One flat namespace is all that is required IMO. Its only purpose is
>>> to keep the global namespace clean.
>> There are no namespaces in implementations of ECMAScript up to Edition 3
>> Final. In such a highly dynamic language, it borders to self-delusion to
>> think that those "namespaces" uninitiated people talk about would
>> automatically help to keep the global "namespace" clean. That they do not
>> can be be readily observed with the number of "namespaced" libraries (and
>> mindless accreditions of those in script-kiddie Web sites) which fail to
>> declare identifiers as local variables.
>
> Incompetent implementations aside, adding methods to a single globally
> declared object generates far less pollution than creating a new
> property of THE Global Object for every function in a library.
Not necessarily.
David Mark
wrote:
It is one vs. many. How could you consider many to be less pollution
than one?
FAQEditor
> On Feb 16, 11:41 pm, Peter Michaux <petermich...@gmail.com> wrote:
>> On Feb 16, 11:35 pm, Randy Webb <HikksNotAtH...@aol.com> wrote:
>>
>>> Peter Michaux said the following on 2/17/2008 2:30 AM:
>>>> On Feb 16, 11:21 pm, FAQEditor <clj...@comcast.net> wrote:
>>> <snip>
>>>>> What are some of the problems with general purpose javascript libraries?
>>>>> The consensus of regular posters in comp.lang.javascript hold the view
>>>>> that most, if not all, general purpose libraries are of a sufficient
>>>> "mainstream, downloadable general purpose"?
>>> I think that implies, or might, that non-mainstream libraries don't
>>> suffer many of the problems that mainstream libraries do.
>> Well, if it isn't right, we can be sure Dr Stockton will mention it to
>> you soon and frequently.
>>>> I think it is close enough to the group regular's general feeling. I
>>>> don't particularly agree with the social skills displayed in the
>>>> threads to be linked but they sure do express the sentiment of the
>>>> most vocal regulars.
>>> You going to volunteer to hunt and weed out the threads for links?
>> I can find some.
>
> I didn't say I was going to spend my life compiling them all.
No, no need to do that.
> These are ones I remember and all involve regulars and the general
> opinions in the group. In some of the threads more than one library is
> mentioned but I've grouped by the library that took the hardest hit.
>
> Prototype
> http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/181f03af63cc81c2
> http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/2072e63631688fc4
>
> jQuery
> http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/415949d1bcce6e6a
>
> YUI
> http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/fefce445673d7135
> http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/37c2a1b93d566b74
I have saved this post so I don't lose the links. Thank you.
--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Randy Webb
When a library gets as many questions asked about it here as Prototype
does then it gets old having 150+ posts threads repeating the same
things over and over. And, most of the "mainstream" (probably all of
them), should be condemned from a strictly programming standpoint. If
the authors of those libraries don't want it condemned, then it is in
the hands of the authors to stop that condemnation.
> Is there a bug count that, say, Prototype exceeds, yet Javascript
> toolbox doesn't?
A bug list is far too subjective to even consider as a criteria for
judging a library. How many errors/bugs don't get reported? And, I would
expect, simply based on size, that there are more errors/bugs in YUI,
Prototype, jQuery (pick one) than Matt's do. The second problem is
trying to determine whether the error/bug is in the browser or in the
library. The library is going to blame it on the browser.
> Which library should I use?
You could write a 10,000 page book and not answer that question. Too
many things at work to give a simple answer to that. If you get asked
that, the only correct answer is "It depends on what you want it to do".
> would be a good FAQEntry.
>
> It could cover a range of things from: What are your needs/what are
> you trying to accomplish? Or all or none of the following:
>
> Library: jQuery :
> overview: <BLAH>
> pro: small, simple API
> con: oversimplified; code behind methods is complicated, difficult
> to test
> <UNBIASED EXAMPLE>
> known bugs /issues: <UNBIASED EXAMPLE>
> highlights:
To cover even 3 or 4 libraries, that would almost double the size of the
FAQ.
> Then the reader can make his onw decision.
Any reader can get that same answer by searching the archives for any
particular library they may be interested in.
> Pick Popular libraries that getasked about frequently. EXT, YUI,
What constitutes "asked about frequently"?
The one recurring one that gets asked about, more than any other, is
prototype.js
Gregor Kofler
> John Resig wrote:
[snip]
I doubt that he is reading this reply...
Gregor
--
http://photo.gregorkofler.at ::: Landschafts- und Reisefotografie
http://web.gregorkofler.com ::: meine JS-Spielwiese
http://www.image2d.com ::: Bildagentur für den alpinen Raum
Richard Cornford
> Thomas 'PointedEars' Lahn meinte:
>> John Resig wrote:
>
> [snip]
>
> I doubt that he is reading this reply...
Don't bet on that. How do you think he found the signature in the first
place if not looking himself up on Google? The reply(s) may be found in the
same way.
Richard.
Richard Cornford
> John Resig wrote:
>> To help you out the correct quote is:
>> "Since valid HTML is simply a subset of XML, having an
>> efficient way to parse and browse DOM documents is
>> absolutely essential for making JavaScript development
>> easier." (Chapter 1, Page 8)
>
> Are you serious and currently capable of cognitive reasoning? Then
> you should be able to read both the HTML and the XML Specifications
> and recognize that what you wrote is complete utter nonsense.
>
> JFYI: HTML is an application of SGML. XML is a subset of SGML.
> XHTML is an application of XML. And finally, your statement is, even
> if corrected *accordingly*, a non sequitur.
Obviously true as that is, plus the chronological consideration were it is
difficult to see how HTML could come into existence being a subset of
something that had not yet come into existence itself, the assertion is not
about HTML as such, but rather about "valid HTML". The latter might be taken
as asserting a relationship between the specific mark-up of valid HTML and
XML. Of course that would not help as valid HTML mark-up does not even
necessarily satisfy XML's well-formed-ness rules, and with regard to HTML
elements with EMPTY content models validness in HTML would preclude even the
possibility of satisfying XML's requirement for XML mark-up to be "well
formed".
Disregarding that still leaves the implied IF-THEN relationship between the
section of the 'sentence' before the comma and the section after it, and the
veracity of the section after it (particularly given the use of javascript
in non web browser contexts).
Richard.
--
"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." - John Resig: Pro JavaScript
Techniques. 2006
Randy Webb
> Thomas 'PointedEars' Lahn meinte:
>> John Resig wrote:
>
> [snip]
>
> I doubt that he is reading this reply...
That's his loss. John Resig could learn a lot from this group and this
thread in particular.
David Mark
> Gregor Kofler said the following on 2/18/2008 3:39 AM:
>
> > Thomas 'PointedEars' Lahn meinte:
> >> John Resig wrote:
>
> > [snip]
>
> > I doubt that he is reading this reply...
>
> That's his loss. John Resig could learn a lot from this group and this
> thread in particular.
>
It is also the loss of anybody who relies on his code to build Web
pages and applications, their clients, and ultimately the unwitting
end-users. Then there are those who attempt to learn about JavaScript
and general browser scripting issues from studying his code, blogs,
books, etc.
Clearly his inability to come to terms with his own incompetence and
refusal to learn from those who know better results in damages that
are far-reaching and losses that are virtually incalculable.
Randy Webb
The true loss is that Richard quoting his book (which is what I assume
he is doing) could lead to the opposite reaction whereby people start
thinking Richard agrees with it and that it becomes acceptable. After
all, "Richard Cornford said it in Usenet".
David Mark
> David Mark said the following on 2/18/2008 5:25 AM:
>
>
>
>
>
> > On Feb 18, 5:01 am, Randy Webb <HikksNotAtH...@aol.com> wrote:
> >> Gregor Kofler said the following on 2/18/2008 3:39 AM:
>
> >>> Thomas 'PointedEars' Lahn meinte:
> >>>> John Resig wrote:
> >>> [snip]
> >>> I doubt that he is reading this reply...
> >> That's his loss. John Resig could learn a lot from this group and this
> >> thread in particular.
>
> > It is also the loss of anybody who relies on his code to build Web
> > pages and applications, their clients, and ultimately the unwitting
> > end-users. Then there are those who attempt to learn about JavaScript
> > and general browser scripting issues from studying his code, blogs,
> > books, etc.
>
> > Clearly his inability to come to terms with his own incompetence and
> > refusal to learn from those who know better results in damages that
> > are far-reaching and losses that are virtually incalculable.
>
> The true loss is that Richard quoting his book (which is what I assume
> he is doing) could lead to the opposite reaction whereby people start
> thinking Richard agrees with it and that it becomes acceptable. After
> all, "Richard Cornford said it in Usenet".
>
Yes, that thought occurred to me as well. Viewing some of the
messages from this thread (specifically the absurdist signatures) out
of context could result in the mistaken impression that Richard is a
fan of this menace.
Gregor Kofler
> Gregor Kofler said the following on 2/18/2008 3:39 AM:
>> Thomas 'PointedEars' Lahn meinte:
>>> John Resig wrote:
>>
>> [snip]
>>
>> I doubt that he is reading this reply...
>
> That's his loss. John Resig could learn a lot from this group and this
> thread in particular.
Well, since he is a self-proclaimed "JavaScript evangelist" (as a
non-native speaker I find such notions ...er... odd), I suppose he
relies on "believing" instead of "learning and understanding".
David Mark
> Randy Webb meinte:
>
> > Gregor Kofler said the following on 2/18/2008 3:39 AM:
> >> Thomas 'PointedEars' Lahn meinte:
> >>> John Resig wrote:
>
> >> [snip]
>
> >> I doubt that he is reading this reply...
>
> > That's his loss. John Resig could learn a lot from this group and this
> > thread in particular.
>
> Well, since he is a self-proclaimed "JavaScript evangelist" (as a
LOL. I haven't heard that one before.
> non-native speaker I find such notions ...er... odd), I suppose he
English is my first language and I don't know what that means either.
> relies on "believing" instead of "learning and understanding".
>
Exactly. And he only preaches to his own choir. When addressing more
enlightened denominations (this group for example), he comes off as a
"JavaScript charlatan" and is quickly booed off the stage.
Gregor Kofler
>> Well, since he is a self-proclaimed "JavaScript evangelist" (as a
>
> LOL. I haven't heard that one before.
Since he is the "JavaScript Evangelist for the Mozilla Corporation" I
should reconsider my using of Firefox... But then: Perhaps he's just the
professional guinea pig for debugging add-ons like FireBug.
RobG
I think they are humorous. If they stimulate debate, in whatever
forum that may be, then they are a good thing.
--
Rob
toby.o...@gmail.com
> dhtml said the following on 2/17/2008 3:37 AM:
>
>
> > Pick Popular libraries that getasked about frequently. EXT, YUI,
>
> What constitutes "asked about frequently"?
>
> The one recurring one that gets asked about, more than any other, is
> prototype.js
>
> --
> Randy
> Chance Favors The Prepared Mind
Apparently, some criteria were used to determine which topics to add
to the FAQ since the FAQ is not empty. Perhaps those same criteria
could be applied to framework-related questions. If the regulars here
are tired of fielding framework/library questions, that would be a
good indicator that those questions are "asked about frequently."
toby.o...@gmail.com
>
> Well, since he is a self-proclaimed "JavaScript evangelist" (as a
> non-native speaker I find such notions ...er... odd), I suppose he
> relies on "believing" instead of "learning and understanding".
>
> Gregor
>
Evangelism primarily refers to Christianity, but is also defined as
enthusiasm. He is claiming to be a JS enthusiast or fanatic rather
than a "believer," which would not make much sense in this context.
Unless there is JavaScript in the Bible Code somewhere ;-)
http://www.google.com/search?q=programming+language+evangelist
Gregor Kofler
> Evangelism primarily refers to Christianity, but is also defined as
> enthusiasm.
> He is claiming to be a JS enthusiast or fanatic rather
> than a "believer," which would not make much sense in this context.
Well, the *others* (must be "JS disciples" then) have to believe. clj
regulars are mere heretics.
FAQEditor
> On Feb 17, 6:08 pm, Randy Webb <HikksNotAtH...@aol.com> wrote:
>> dhtml said the following on 2/17/2008 3:37 AM:
>>
>> [snip]
>>
>>> Pick Popular libraries that getasked about frequently. EXT, YUI,
>> What constitutes "asked about frequently"?
>>
>> The one recurring one that gets asked about, more than any other, is
>> prototype.js
>
> to the FAQ since the FAQ is not empty. Perhaps those same criteria
> could be applied to framework-related questions. If the regulars here
> are tired of fielding framework/library questions, that would be a
> good indicator that those questions are "asked about frequently."
>
The only entry in the FAQ that could even come close to the question at
hand would be section 3.1 "What books cover javascript?" and, to the
best of my knowledge, that entry was put in so that there would be
*some* book recommended even though the sole book it recommends isn't
really a "good" book. It is just the best of the bad. The same reasoning
could be used to include an entry, possibly a 3.3 entitled "What is the
best javascript library available?" And then it would need to be worded
to make sure that it was known that most of the regulars think all of
them are junk but that some library was the best of the worst.
The rest of the questions in the FAQ tend to be more specific and less
subjective as to the answer to the question and they are more
programming oriented.
As for adding an entry, as the Editor, it doesn't matter to me. It is
only adding a few lines of text to a file. The rest is auto-generated
for me. What I wouldn't want is an entry that is highly subjective in
it's answer that could potentially get changed every other day as
libraries get changed and bugs get fixed/introduced.
I can tell you this much though, when it comes to the quality of code,
whether in a library or general code, and I have questions about it, the
person I trust most for an opinion on it is - hands down - Richard
Cornford. It doesn't mean I blindly trust him, but I have the utmost
respect for his opinion. Even with regards to ECMAScript and the
regulars here know what my personal opinion about that is.
--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Randy Webb
>> dhtml said the following on 2/17/2008 3:37 AM:
>>
>> [snip]
>>
>>> Pick Popular libraries that getasked about frequently. EXT, YUI,
>> What constitutes "asked about frequently"?
>>
>> The one recurring one that gets asked about, more than any other, is
>> prototype.js
>>
>
> to the FAQ since the FAQ is not empty. Perhaps those same criteria
> could be applied to framework-related questions. If the regulars here
> are tired of fielding framework/library questions, that would be a
> good indicator that those questions are "asked about frequently."
>
In keeping with my longstanding desires to keep my person opinion
separated from what I do as editor, I am also replying to this post
personally. My personal opinion?
Question: What javascript library is the best?
Answer: None of them. They are all junk.
Question: Why is prototype.js pure junk?
Answer: Because it is junk.
Do I think there should be an entry on general purpose libraries?
Absolutely not.
And no, I am not some ECMAScript bible thumping zealot either. Just
search my name and ECMAScript :)
--
Randy
Chance Favors The Prepared Mind
Matt Kruse
> Question: What javascript library is the best?
> Answer: None of them. They are all junk.
I think statements like this are what drive people away from this
group.
Just because libraries typically have technical "problems" or don't
get everything right doesn't classify them as "junk" IMO. It's this
elitist attitude that ignores the real world benefits of generalized
libraries that make lead so many people to use them to begin with.
I consider myself very knowledgeable about js and I have many years of
experience with browser scripting. I certainly don't know as much as
some here. But I use jquery on a regular basis for mission-critical
internal webapps, and it's been working great for us. If it was "junk"
then we would be having endless problems, right? Instead, we are
seeing huge benefits. The library could certainly benefit from some
technical improvements, but dismissing it as "junk" is ridiculous.
There are situations where I wouldn't use jquery, or any library. But
in some cases it is perfect. Any reasonable analysis of jquery or
other libraries needs to keep this in mind.
If the arguments against generalized libraries (and of course there
are some) are to be taken seriously, then they need to be rational and
specific about their criticisms and let the reader then decide if they
should be used or not, given the pros and cons presented.
Matt Kruse
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn meinte:
>> John Resig wrote:
>
> [snip]
>
> I doubt that he is reading this reply...
When others do a foolish thing you should tell them it is a foolish thing.
They can still continue to do it, but at least the truth is where it needs
to be.
-- Dukhat (from: "Babylon 5" - "Atonement")
Regards,
PointedEars
Thomas 'PointedEars' Lahn
> David Mark meinte:
>>> Well, since he is a self-proclaimed "JavaScript evangelist" (as a
>> LOL. I haven't heard that one before.
>
> Here:
> http://ejohn.org/about/
>
> Since he is the "JavaScript Evangelist for the Mozilla Corporation" I
> should reconsider my using of Firefox... But then: Perhaps he's just the
> professional guinea pig for debugging add-ons like FireBug.
I didn't get the last one. Firebug (no caps in between) was conceived
and is continued to be developed by Joe Hewitt, who appears to me to be
a !(John Resig) regarding his approach at Web software development. At
least I found my Firebug beta test comments very well received.
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
David Mark
> On Feb 18, 8:44 am, Randy Webb <HikksNotAtH...@aol.com> wrote:
>
> > Question: What javascript library is the best?
> > Answer: None of them. They are all junk.
>
> I think statements like this are what drive people away from this
> group.
Perhaps. But they need to be said anyway. Those willing to listen,
rather than flee, will gain much-needed perspective. Something has to
counter-balance the pervasive "libraries are great" attitude that has
infected the Web developer community.
>
> Just because libraries typically have technical "problems" or don't
No quotes needed. They have problems, period. Big ones.
> get everything right doesn't classify them as "junk" IMO. It's this
> elitist attitude that ignores the real world benefits of generalized
You and other proponents of junk like jQuery should scratch "real
world" out of your playbook.
> libraries that make lead so many people to use them to begin with.
No, what leads people to use them is ignorance of their various
issues, which is why (most) contributors to this group feel the need
to correct misconceptions about the various libraries in the strongest
possible terms.
>
> I consider myself very knowledgeable about js and I have many years of
> experience with browser scripting. I certainly don't know as much as
> some here. But I use jquery on a regular basis for mission-critical
The fact that you use jQuery seems to contradict the assertion that
you are knowlegeable about JS and browser scripting.
> internal webapps, and it's been working great for us. If it was "junk"
Wait until your company upgrades Windows and finds that IE8 breaks all
of jQuery's IE-sniffing. Or perhaps you will want to create an
Extranet at some point. Your applications will likely run into
considerable trouble on mobile devices. These are hypotheticals of
course, but I think they illustrate the point.
> then we would be having endless problems, right? Instead, we are
It has been explained numerous times that that logic has no place in
the "real world." Just because you are not aware of (current or
imminent) problems on your Intranet, does not mean that the library is
appropriate for use on the public Internet (which is where most people
use it.)
> seeing huge benefits. The library could certainly benefit from some
> technical improvements, but dismissing it as "junk" is ridiculous.
No quotes needed. It is junk and it has long-since been dismissed by
those who have read its source.
> There are situations where I wouldn't use jquery, or any library. But
> in some cases it is perfect. Any reasonable analysis of jquery or
> other libraries needs to keep this in mind.
If you want to take shortcuts and paint your Intranet into a corner by
relying on an incompetent JavaScript library, then it is perfect for
you.
>
> If the arguments against generalized libraries (and of course there
> are some) are to be taken seriously, then they need to be rational and
> specific about their criticisms and let the reader then decide if they
> should be used or not, given the pros and cons presented.
Which we have done to death here. Do you not recall the numerous
mistakes in jQuery that were exposed here not three months ago? IIRC,
you at least tried to educate the authors about them and ran into
"arguments" that further illustrated the pervasive cluelessness of
those involved. Did they ever figure out that the text node event
target issue was neither Safari-specific, nor a case that called for
browser sniffing?