Prototype - Good/Bad/Why?

[toby.oconnell]

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]

(e-mail address removed) meinte:

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.

Gregor

 

[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:

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

 

[David Mark]

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?

 

[timothytoe]

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?


Professionalism? Did you actually ask the client how they feel about your
design strategy?

Richard.

It's not my design strategy. I've never had to get work that way. But
I've just been around long enough to have seen it over and over.

I'm glad that people have eschewed previous bad practices of using
eval. But correcting misuse of eval is one thing. Keeping people away
from using Javascript libraries is another. It's just way too easy to
at least mock something up with them. And once something is mocked up,
of course, it tends to grow more and more dependent on that library. I
rarely see the "money" people are to reengineering a mock up. Enough
time can be lost that the market disappears.

The best you can hope for is to engage the library authors who are
committing the sin of brittleness and to encourage authors who write
robust ones. Being angry with and mean to people who come into this
group hardly seems a winning strategy.

By all means, show what is bad, show how it can be handled correctly,
and do it in a civil and mature way.

I'm in favor of improvements to the libraries and development of
better ones, as all should be.

Telling people that the libraries are crap or junk is not as useful as
simply explaining the deficiencies. If this were handled correctly,
people would be more likely to desire to have more robust libraries.
It's all too easy to dismiss clj because of how unreasonable and
childish a few common posters seem.

If someone came in here and asked, "Should I use Prototype?", a more
productive response than usually comes from here might start, "well, a
lot of people are using it, but here are my concerns with it..."

I've been watching the activity on clj vs. just the main jQuery group.
There has been more action there than here. And that's just one
library. So clj can't win just by being big and angry--it's not big
enough. Instead, it has to be convincing. And to be convincing, it
needs to be a bit less foamy around the mouth.

 

[Matt Kruse]

Perhaps. But they need to be said anyway.

Not really. Saying something "is junk" is meaningless. I could say
your code is junk without any arguments to back it up and that would
be just as pointless. Labeling something "junk" doesn't really mean
anything, and should rightly be ignored.

No quotes needed. They have problems, period. Big ones.

Depends on your viewpoint. It's obvious that you think your
perspective is the only valid one, but that is your bias.

You and other proponents of junk like jQuery should scratch "real
world" out of your playbook.

The "Real world" is what makes jquery a viable option. If you're just
judging pure technical quality and robustness, I'm not sure jquery
would ever win or be the best choice. When you factor in other very
important considerations, it becomes viable and in some cases, IMO,
the best choice.

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 would argue that the need to correct misconceptions is more about
feeding personal egos.

The fact that you use jQuery seems to contradict the assertion that
you are knowlegeable about JS and browser scripting.

That's because you choose to ignore anything that doesn't fit without
your pre-determined conclusions. I'm sure it must be difficult for you
to resolve the apparent conflict of a knowledgeable person using a
library. So it's easier just to dismiss one as being wrong rather than
trying to understand.

Wait until your company upgrades Windows and finds that IE8 breaks all
of jQuery's IE-sniffing.

Are you sure that will happen? I don't even see an upgrade to IE7
happening in the next year or two. Worrying about that is such a minor
consideration compared to the benefits we have received. It's all
about balancing pros and cons, isn't it?

Or perhaps you will want to create an
Extranet at some point. Your applications will likely run into
considerable trouble on mobile devices.

Nope, won't happen. If that were a consideration then I may have
chosen a different solution, don't you think?

These are hypotheticals of
course, but I think they illustrate the point.

No they don't. They illustrate that you don't understand the specific
applications for which I have chosen to implement jquery and why your
points are not at all relevant. If they were, don't you think I would
have chosen not to use jquery to begin with? I haven't yet created a
public site using jquery because I'm aware of its limitations. I know
when it works and when it doesn't. But just because it doesn't work in
ALL cases doesn't mean it's not a great fit for SOME cases.

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

a) I do not use it on an intranet, but rather a web application
b) I'm not sure I've ever said that I would use jquery on a public
internet site, or that I would recommend it. I would certainly only do
so in rare cases, under specific circumstances.

No quotes needed. It is junk and it has long-since been dismissed by
those who have read its source.

Again, if you are judging libraries based only on technical robustness
and correctness, I can see your argument (although I would still never
use the label "junk"). But technical robustness is never the only
factor in the real world.

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.

In fact, just the other day I got an email from John Resig about
working on an effort to make technical improvements to jquery. Things
take time. I'm fine with that.

Did they ever figure out that the text node event
target issue was neither Safari-specific, nor a case that called for
browser sniffing?

I'm sure things like that will be addressed. Personally, I'm in no
hurry. I see no browser upgrade in my future for a year or two, and I
haven't updated the version of jquery that I'm using in over a year.
Still works great for what I use it for. I'm sure that must just rock
your world!

Matt Kruse

 

[David Mark]

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 usin
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 allof
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 thatthe
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?

Professionalism? Did you actually ask the client how they feel about your
design strategy?

[snip]

It's not my design strategy. I've never had to get work that way. But

Well, you seemed to imply that it was indeed the strategy of choice
for "smart programmers."

I've just been around long enough to have seen it over and over.

If all of these "smart programmers" jumped off a bridge, would you
follow suit or advocate it as a useful strategy?

I'm glad that people have eschewed previous bad practices of using
eval. But correcting misuse of eval is one thing. Keeping people away
from using Javascript libraries is another. It's just way too easy to
at least mock something up with them. And once something is mocked up,

IIRC, that it is the first time mockups have been mentioned in this
thread.

of course, it tends to grow more and more dependent on that library. I
rarely see the "money" people are to reengineering a mock up. Enough
time can be lost that the market disappears.

Just who are these "money" people? Google and the like? Certainly
their production sites are mockeries and perhaps they are actually
mockups that were deemed good enough to unleash on an unsuspecting
public. This is not how they made their money, but what they have
chosen to do with the money invested in them. Such practices are not
the best interest of any organization or its shareholders, but perhaps
they just can't find good help.

The best you can hope for is to engage the library authors who are
committing the sin of brittleness and to encourage authors who write
robust ones. Being angry with and mean to people who come into this
group hardly seems a winning strategy.

Who's angry? I see a lot of LOL notations in this thread. The
"arguments" posed in support of ill-conceived and poorly written
JavaScript libraries are at once funny and sad, but hardly anger-
inducing. On the other hand, browsing the Web these days can be very
aggravating and JavaScript libraries are often the source of the
aggravation.

By all means, show what is bad, show how it can be handled correctly,
and do it in a civil and mature way.

I posted the very first response in this thread and there was nothing
uncivil or immature about it. The response answered the OP's question
and the thread should have ended soon after. But, as is often the
case, immature people with odd aliases felt compelled to jump in with
both feet, citing nonsense about the "real world" of "smart
programmers" who fleece unsuspecting clients with admittedly sub-
standard and instantly obsolete products in hopes of securing future
maintenance work.

I'm in favor of improvements to the libraries and development of
better ones, as all should be.

Some simply cannot be improved short of starting over from scratch
with improved insight. Unfortunately, as mentioned, most are frozen
in time due to premature and widespread adoption. They can't change
now, lest they pull the crutch out from under the myriad sites they
have propped up. Even worse, it appears these crutches will fall
apart in unison on the arrival of IE8. This should surprise noone who
reads this group on a regular basis, but will likely be quite a shock
for those who choose to dismiss it.

I am, however, all for the development of better solutions. This
should be quite apparent to regular readers of this group.

Telling people that the libraries are crap or junk is not as useful as
simply explaining the deficiencies. If this were handled correctly,

Did you read the very first reply to this thread (or the numerous
related threads that preceded it?)

people would be more likely to desire to have more robust libraries.

That assumes that people who write and rely on "brittle" libraries
understand their deficiencies. In general, it has been shown that
they do not. Perhaps this is because they dismiss any and all
criticism of such libraries as "childish" and/or "immature."

It's all too easy to dismiss clj because of how unreasonable and
childish a few common posters seem.

There you go again. Who has demonstrated childish behavior in this
thread?

If someone came in here and asked, "Should I use Prototype?", a more

There is no need to pose that as a hypothetical. That is exactly how
this very thread started.

productive response than usually comes from here might start, "well, a
lot of people are using it, but here are my concerns with it..."

See the very first response.

I've been watching the activity on clj vs. just the main jQuery group.
There has been more action there than here. And that's just one

What sort of "action" do you mean?

library. So clj can't win just by being big and angry--it's not big

This isn't a contest, but a discussion group. And again, who is
angry?

enough. Instead, it has to be convincing. And to be convincing, it
needs to be a bit less foamy around the mouth.

Believe what you wish. I am through attempting to convince you of
anything as I suspect you just like to argue.

 

[Richard Cornford]

David Mark said the following on 2/18/2008 5:25 AM:

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

It would be unfortunate for anyone to fall victim to the delusion that a
statement could be worth more, more true or more significant as a
consequence of who made it.

Richard.

 

[Richard Cornford]

I think statements like this are what drive people away
from this group.

Even if true, you imagine individual who are so easily driven represent a
loss?

Just because libraries typically have technical "problems"
or don't get everything right doesn't classify them as
"junk" IMO.

Identifying problems with something may not be sufficient to conclude that
it would be junk, but the do push the odds in that direction.

Consider the position on Prototype.js; it is asserted that Prototype.js
suffers from fundamental and serious design flaws that would not be expected
in the product of a more experienced/knowledgeable designer. That is a
subjective judgement, fine. But it has been objectively demonstrated that
the people writing the recent versions of Prototype.js don't understand the
javascript they are writing and instead of programming they are creating
structures that only work by coincidence. Now if you can demonstrate that
the people writing Prototype.js now are demonstrating a lack of experience
of, and knowledge about, javascript, the odds are that at the time of
designing Prototype.js they had less knowledge and experience, which suggest
that the subjective judgement that it is poorly designed is justified.

An objective examination of dojo source has revealed similar knowledge
shortfalls it its authors, and in 2006 John Resig wrote (in his "Pro
JavaScript Techniques" book):-

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

While some of the possible quibbles with that statement may be questionable
(such as the use of "evaluate", which could be taken in the sense used in
ECMA 262 making "all evaluate to false" objectively false, or taken as
something other than a technical term, and so more subject to ambiguous
interpretation), the meat of that statement is absolutely and objectively
false. Anyone can execute code such as - null == false - and see examples of
"all" of those listed values not being "equal (==) to each other".

So when was JQuery originally designed? Did he have time learn the
fundamentals of javascript between writing his book in 2006 and designing
JQuery? Or did JQuery come first, at a time when he can be demonstrated to
be suffering a knowledge shortfall?

Thus an assertion that Protoype.js, dojo or JQuery may not be well designed
could be backed up with objective demonstrations that the people doing the
deigning did not even have enough experience to actually understand the
language the were implementing them in.

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.

A position that takes more into account does not necessarily 'ignore the
real world benefits of generalised libraries' while still drawing negative
conclusions about them.

I consider myself very knowledgeable about js

Above average maybe. You are not in the very knowledgeable ballpark yet.
Your AJAX library, for example, could be half the size and twice as fast if
you understood it a little better.

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.

You mean that you are using something that is criticised as being inadequate
for a general web environment in a controlled Intranet environment and not
(yet) seeing issues? But haw many browsers are used on your Intranet? If
people are not using Opera or Safari you are still putting up with a lot of
unnecessary runtime testing and branching for no good reason.

The library could certainly benefit from some technical
improvements, but dismissing it as "junk" is ridiculous.

It is just a shorthand.

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.

Presumably you are assuming these things are not taken into account based
upon the largely negative conclusions. That would not be reasonable, as it
is possible to take these things into account and still come to a negative
conclusion. I, for one, have cited circumstances under which I would happily
use Prototype.js; they were when part of the design requirement was to
provide supplementary room heating for users living on cold climates. So the
possibilities offered have been considered.

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.

But it is a long and involved discussion that has been held over many years
so repeating it all every week or two for the benefit of individuals who
will not do their own research can get tedious. A shorthand is the likely
outcome.

Richard.

 

[David Mark]

Not really. Saying something "is junk" is meaningless. I could say

Did it occur to you that the "is junk" comment(s) came long after more
detailed criticism had been posted in this thread (and others.) Do we
really need to revisit these points over and over?

your code is junk without any arguments to back it up and that would

LOL. You would clearly be ill-advised to say such a thing.

be just as pointless. Labeling something "junk" doesn't really mean
anything, and should rightly be ignored.

As mentioned, such comments are not likely meant as stand-alone
commentary. We've been over the specific deficiencies ad nauseum.

Depends on your viewpoint. It's obvious that you think your
perspective is the only valid one, but that is your bias.

Obvious to whom? Perhaps you don't read this group as much as you
should. I have no problem admitting when I am wrong and have done so
numerous times. The fact that I do so less frequently these days
indicates that I have learned from my mistakes. Contrast that to the
"perspective" of your chosen library's author, who dismisses any and
all criticism out of hand.

The "Real world" is what makes jquery a viable option. If you're just

That's enough of that nonsense. I won't response any further to non-
arguments involving your conception of the "Real world."

judging pure technical quality and robustness, I'm not sure jquery
would ever win or be the best choice. When you factor in other very
important considerations, it becomes viable and in some cases, IMO,
the best choice.

IIRC, your argument is that your ten-user Intranet applications only
need to support a couple of browsers in their default configurations.
I put it to you that you shouldn't need to lean on a browser-sniffing
library at all to develop for such an audience. Furthermore, by
leaning on such a thing, you are programming for future failure.

I would argue that the need to correct misconceptions is more about
feeding personal egos.

That is ridiculous and tiresome. My ego, for one, is quite well-fed
by other sources. I correct people when I feel they need to be
corrected (as is the case here.) I suspect that most of other regular
contributors similarly see Usenet posting as less than a core part of
their identities. Hint: this is a technical newsgroup, not the "Real
world." Even among JavaScript programmers, the majority has never
heard of it. Fewer still actually read it.

That's because you choose to ignore anything that doesn't fit without
your pre-determined conclusions. I'm sure it must be difficult for you
to resolve the apparent conflict of a knowledgeable person using a
library. So it's easier just to dismiss one as being wrong rather than
trying to understand.

No, I base my opinion of your relative expertise on the arguments
posed in your posts. I have long since dismissed any notion that you
know what you are talking about.

Are you sure that will happen? I don't even see an upgrade to IE7

Of course not. But some might see it as inevitable. How many Windows
3.1 boxes are in current use at your shop?

happening in the next year or two. Worrying about that is such a minor

So all of your applications have roughly a two-year expiration date?
That is not exactly forward-thinking.

consideration compared to the benefits we have received. It's all
about balancing pros and cons, isn't it?

Yes, and in summation of this seemingly endless debate, I believe the
obvious cons outweigh any perceived pros, even for a ten-user Intranet
application.

Nope, won't happen. If that were a consideration then I may have
chosen a different solution, don't you think?

I have no idea what you might have done.

No they don't. They illustrate that you don't understand the specific
applications for which I have chosen to implement jquery and why your
points are not at all relevant. If they were, don't you think I would
have chosen not to use jquery to begin with? I haven't yet created a

Again, I am hardly in a position to theorize about what you might have
done or why you might have done it.

public site using jquery because I'm aware of its limitations. I know

Then please stop mindlessly advocating jQuery (as you have in the
past) as it seems most people who ask about such libraries aspire to
build a public "Ajax site." And again, I don't see it as a practical
solution for Intranets either.

when it works and when it doesn't. But just because it doesn't work in

You didn't have a very good grasp on them a few months back. It seems
you should be grateful for the critical discussion that opened your
eyes to numerous issues with your library of choice.

ALL cases doesn't mean it's not a great fit for SOME cases.

Name one.

a) I do not use it on an intranet, but rather a web application

And is this Web application hosted on the public Internet? If so,
then you really haven't got a leg to stand on. Does the login page
have a "best used with the default configuration of IE6/7" placard?
If so, then your service is really a disservice. What if one of your
users decides to upgrade Windows without asking you first? Or do you
also warn about such inconceivable eventualities?

b) I'm not sure I've ever said that I would use jquery on a public
internet site, or that I would recommend it. I would certainly only do
so in rare cases, under specific circumstances.

Recommending jQuery for any site, public or not, is ridiculous. It is
like recommending arsenic as an appetizer (I don't care what
restaurant you are in.)

Again, if you are judging libraries based only on technical robustness
and correctness, I can see your argument (although I would still never

And what other criteria would you consider? If something is brittle
and wrong, it is a fair bet that recommending it is ill-advised.

use the label "junk"). But technical robustness is never the only
factor in the real world.

See above.

In fact, just the other day I got an email from John Resig about
working on an effort to make technical improvements to jquery. Things
take time. I'm fine with that.

After being numbed by jQuery usage for years, are you really sharp
enough to make a significant difference at this point? Perhaps he
should have asked for help before subjecting the Web to his folly.
The first improvement should be to issue a public recall (and
apology.) Then tell him to close down all of his blogs and to stop
writing books on browser scripting, at least until he understands the
basic concepts. Are you strong enough to do that? Such a cold dose
of reality is what he sorely needs. If you water down your efforts
with coddling and back-slapping, then you are just going to waste your
time.

I'm sure things like that will be addressed. Personally, I'm in no

LOL. It, among other things, *was* addressed (here and there) ad
nausem. Do you mean to say that that odious bit of "logic" is still
present in the code? You have made my argument for me. People who do
not understand browser scripting should not be charged with building
browser scripting libraries. People who fail to demonstrate an
ability for critical thought and analysis should be nowhere near
software development. Yet, these are just the sort of people who seem
to gravitate to open source browser scripting projects (much to the
detriment of people who use the Internet as a tool, rather than a
playground.)

hurry. I see no browser upgrade in my future for a year or two, and I

Are you the sole user of the application?

haven't updated the version of jquery that I'm using in over a year.

Even after the discussion a few months back? Are you kidding?!

Still works great for what I use it for. I'm sure that must just rock
your world!

We are done here.

 

[Matt Kruse]

While some of the possible quibbles with that statement may be questionable
(such as the use of "evaluate", which could be taken in the sense used in
ECMA 262 making "all evaluate to false" objectively false, or taken as
something other than a technical term, and so more subject to ambiguous
interpretation), the meat of that statement is absolutely and objectively
false. Anyone can execute code such as - null == false - and see examples of
"all" of those listed values not being "equal (==) to each other".

Of course his statement is incorrect, but I think the real problem is
that the intended point was not properly worded.

So when was JQuery originally designed? Did he have time learn the
fundamentals of javascript between writing his book in 2006 and designing
JQuery? Or did JQuery come first, at a time when he can be demonstrated to
be suffering a knowledge shortfall?

I'll judge the code by the code, not by what the author may have mis-
worded in a printed book that I don't care about.

Your AJAX library, for example, could be half the size and twice as fast if
you understood it a little better.

True, I do, and I could make a lot of improvements. Probably a re-
write. I just have no real desire to.

You mean that you are using something that is criticised as being inadequate
for a general web environment in a controlled Intranet environment and not
(yet) seeing issues? But haw many browsers are used on your Intranet? If
people are not using Opera or Safari you are still putting up with a lot of
unnecessary runtime testing and branching for no good reason.

Does it matter? There are no performance problems. I typically use
jquery in an environment where there is only a single browser and
platform.

But it is a long and involved discussion that has been held over many years
so repeating it all every week or two for the benefit of individuals who
will not do their own research can get tedious. A shorthand is the likely
outcome.

I think a table of pros/cons for library use in general, and a pro/con
list for major libraries would be a good thing. You could be in charge
of the 'con' list for all

Matt Kruse

 

[Matt Kruse]

That's enough of that nonsense. I won't response any further to non-
arguments involving your conception of the "Real world."

It's certainly easier to declare your conclusions as superior when you
dismiss the opposing viewpoint outright.

I have long since dismissed any notion that you
know what you are talking about.

I am surprised you still feel the need to respond to me, then.

So all of your applications have roughly a two-year expiration date?
That is not exactly forward-thinking.

No, I see an upgrade to IE7 happening in a year or two. I've already
tested with IE7 and the app and jquery work fine with it. A move to
IE8 may be many years off, and I don't predict any problems with that,
either.

Yes, and in summation of this seemingly endless debate, I believe the
obvious cons outweigh any perceived pros, even for a ten-user Intranet
application.

I should write something like this up in a page that could be
referenced when arguments like this come up...

I can think of a number of things that would need to be considered
when deciding what javascript strategy to use in a project. For
example,

a) What is the target audience? Is the user environment known? Is it
subject to change? Will js be required?
b) How critical is performance?
c) What types of things will javascript be used for now and in the
future?
d) How many developers will be writing javascript code?
e) How experienced are the developers with js coding?
f) What is the project's budget?
g) Are there any existing requirements or standards used by the
client, or by the development team?
h) What is the delivery schedule?
i) Will the developers rely on documentation for the js functionality
being used?
j) Is there a resource available to maintain, debug, and improve the
js code?
k) etc...

Now, I'll throw a hypothetical situation at you that comes from
experience in real projects, and you tell me what you would have done
differently or why the decision reached is the wrong one.

A project is to begin to develop an internal webapp to be used by 25
users at a single location for a single client. All users have XP and
IE6. The project budget and timeline are very tight and success is
critical. You are the technical lead in the US and you have 20
developers in India who will do the coding. All of them are decent
Java/web programmers with average javascript knowledge. The
application requires a good amount of js coding for ajax, form
validation, some dynamic UI elements, etc. It has been partially
mocked up in plain HTML but almost no actual js has been written to
drive it. You can't quit, and you have to make this project a success.
Go.

There are a couple of different ways you could approach this. Some of
them:

a) Demand that an experienced js developer be hired and added to the
team. Good luck. Resources are limited and hiring someone would take
too long. Work with the resources you have.

b) Pick the most knowledgeable js coder in the group and put him in
charge of writing all the js from scratch. It's hard to say what
you'll end up with. That's a risk.

c) Try to find existing code from experts on the web and mash it
together to be used. Oh, wait, there aren't many actual code resources
available from the "experts" and even finding the right "experts" is
difficult. That scrolling table body you want to create in your app?
That one expert, Richard Cornford, has an example of that but it's not
documented and as far as you can tell you aren't even allowed to
legally use it. Trying to find code written by experts that could be
put together into a real app by amateurs will end up in a mess.

d) Pull existing, proven code from other projects into this one and do
a lot of copy and pasting. The developers will need to do their own
trial and error, because none of the code is well documented and there
is no overall API or design to make the pieces fit together.

e) Use a library like jquery. The browser environment is fixed and
supported by the library. The library is very well documented. There
are tons of examples. There is a support group where questions are
quickly answered. It's free. The API is easily understood. The file
size is minimal. The amount of code to be written from scratch is
greatly reduced and the potential for bugs is greatly reduced. It can
be used from day 1 rather than waiting for a home-grown library to be
created. It will be maintained and tested by others who will find bugs
and fringe cases that you would never think of - at no cost to you.

Now, maybe you have a different perspective, but it's situations like
this that make me conclude that using a library like jquery is the
best choice. It would let me focus on bigger problems that are more
complex, and put the load of generalized javascript development and
browser debugging on to someone else's hands. Is jquery perfect? Hell
no. But it's probably better than what would have been written by my
offshore team. And it works without a single problem in the target
environment, enabling animations, effects, and functionality that
would have been out of the question if it needed to be coded from
scratch.

Could it break in browser X in 2 years? Perhaps. But hopefully that
will mean just popping in an updated version of the library with the
same API. If it means taking a look at the code to try to fix a bug in
the library itself, so be it. It's still way more economical than
coding from scratch. And it helps to manage risk, because jquery is
known to work right now, whereas writing code from scratch has a risk
of failing or not being delivered in time or being unmaintainable.
JQuery isn't perfect. But it's way better than the alternatives that I
can see.

This is what I call the "real world". As you can see, it has little to
do with whether or not a specific browser sniff is required or if a
particular code branch is actually unreachable. While getting that
stuff perfect is a great goal too, there are bigger and more important
issues to be considered.

I would love to work on projects where everyone knows exactly what
they are doing and there are dedicated JS developers who have
developed a robust internal set of tools that are documented and have
a solid API. So far that hasn't happened for me, and I haven't known
many places where that is the norm.

Then please stop mindlessly advocating jQuery (as you have in the
past) as it seems most people who ask about such libraries aspire to
build a public "Ajax site."

I don't mindlessly advocate jquery. I'm not sure if I've ever
recommended it. What I have done, occasionally, is defend it for use
in situations where I think it solves a problem well.

And is this Web application hosted on the public Internet?

Of course not.

What if one of your
users decides to upgrade Windows without asking you first? Or do you
also warn about such inconceivable eventualities?

Never going to happen. And can you believe that I actually use ActiveX
quite a bit? To access the filesystem, even? Unbelievable!

And what other criteria would you consider? If something is brittle
and wrong, it is a fair bet that recommending it is ill-advised.

See above.

Even after the discussion a few months back? Are you kidding?!

No! And can you believe that things still work perfectly?! Oh My God!
Inconceivable!

Matt Kruse

 

[David Mark]

It's certainly easier to declare your conclusions as superior when you
dismiss the opposing viewpoint outright.

I thought I dismissed you outright, but like a bad penny, you have
turned up again to suck all of the rational thought out of this
discussion.

Declaring that development in the "Real world" requires something like
jQuery does not represent a rational viewpoint. It is a frequently
(and irritating) mantra spewed by those who have neither rational
views nor points. I don't care to counter such non-arguments any
further.

I am surprised you still feel the need to respond to me, then.

I feel the need to stop the spread of misinformation and bad advice
related to browser scripting. I, for one, am tired of tripping over
easily preventable mistakes every time I browse the Web. It sometimes
seems there is not a usable page on the Internet. Even worse,
disabling scripting does not typically increase usability, but only
serves to expose additional misconceptions of the responsible
designers and developers. And most irritating of all, any attempt to
dispel myths and ill-conceived notions about Web development seems to
draw legions of half-wits who proceded to dilute relevant criticism
with irrational (and often nonsensical) ramblings. Call it "esprit de
twits."

No, I see an upgrade to IE7 happening in a year or two. I've already
tested with IE7 and the app and jquery work fine with it. A move to

If your app works in IE6, then it should almost certainly work in
IE7. Despite a half-dozen year gap between the two releases, MS
changed virtually nothing in their ECMAScript implementation.

IE8 may be many years off, and I don't predict any problems with that,
either.

Your prediction seems short-sighted to me. If, as reported, IE8 will
be markedly closer to the standards-based browsers, then your only
recourse when using an IE-sniffer like jQuery will be to force your
pages to "thunk" back to IE7 compatibility mode. In other words, you
have painted yourself into a corner where your code cannot take
advantage of future improvements to a user agent that is currently
riddled with flaws and outright failures. While the rest of the world
moves on (at least those who had the good sense to avoid browser
sniffing libraries), your application will be forever stuck in the IE
dark ages.

I should write something like this up in a page that could be
referenced when arguments like this come up...

Something like what? How to leverage the inherent obsolescence in
libraries like jQuery to maximize past, present and future
incompatibilities? There are enough half-baked browser scripting
articles out there as it is.

I can think of a number of things that would need to be considered
when deciding what javascript strategy to use in a project. For
example,

The first of which is to define the goals of the project.

a) What is the target audience? Is the user environment known? Is it
subject to change? Will js be required?

Well, if JavaScript will not be required (and it should rarely be an
absolute requirement), then you don't need a JavaScript strategy.

b) How critical is performance?

Performance of what? You haven't defined what the project is supposed
to do.

c) What types of things will javascript be used for now and in the
future?

Hard to say at this unspecified project.

d) How many developers will be writing javascript code?

As many as it will take to reach your unspecified goal within an also
unspecified period of time.

e) How experienced are the developers with js coding?

The developers should be chosen according to the goals of the
project. You don't bend a project to suit arbitrary developers.

f) What is the project's budget?

It seems you are getting further and further off the subject at hand.
What is the point of this checklist?

g) Are there any existing requirements or standards used by the
client, or by the development team?

Again, you are trying to bend a project to best match an arbitrary
team of developers. This is ridiculous advice.

h) What is the delivery schedule?

What is the price of beans in Somaliland? Could this be any more
irrelevant to the current discussion?

i) Will the developers rely on documentation for the js functionality
being used?

Documentation is typically done after the development has been
finalized. Otherwise, what would you document?

j) Is there a resource available to maintain, debug, and improve the
js code?

How can there be a resource available to maintain, debug and improve
code that has yet to be designed?

k) etc...

That one is as useful as any that preceded it.

Now, I'll throw a hypothetical situation at you that comes from
experience in real projects, and you tell me what you would have done
differently or why the decision reached is the wrong one.

Oh, yes sir. I'll get right on that.

A project is to begin to develop an internal webapp to be used by 25
users at a single location for a single client. All users have XP and
IE6. The project budget and timeline are very tight and success is

Are you serious?

critical. You are the technical lead in the US and you have 20
developers in India who will do the coding. All of them are decent

LOL. Thanks for the keen insight into your shop.

Java/web programmers with average javascript knowledge. The
application requires a good amount of js coding for ajax, form
validation, some dynamic UI elements, etc. It has been partially
mocked up in plain HTML but almost no actual js has been written to
drive it. You can't quit, and you have to make this project a success.
Go.

Sorry, I don't care to join your developer fantasy league.

There are a couple of different ways you could approach this. Some of
them:

a) Demand that an experienced js developer be hired and added to the
team. Good luck. Resources are limited and hiring someone would take
too long. Work with the resources you have.

You are inventing a scenario which you hope will lead to a
hypothetically optimal solution that involves jQuery. I'll ask again:
are you serious?

b) Pick the most knowledgeable js coder in the group and put him in
charge of writing all the js from scratch. It's hard to say what
you'll end up with. That's a risk.

It is hard to say why I am still reading this. I want the last five
minutes of my life back.

c) Try to find existing code from experts on the web and mash it
together to be used. Oh, wait, there aren't many actual code resources
available from the "experts" and even finding the right "experts" is

LOL. Who told you that? And do the quotes indicate some unfulfilled
desire to be taken seriously as an "expert."

difficult. That scrolling table body you want to create in your app?

Are you talking to me? I don't want a scrolling table body.

That one expert, Richard Cornford, has an example of that but it's not
documented and as far as you can tell you aren't even allowed to
legally use it. Trying to find code written by experts that could be

How much documentation do you need for the scrolling table body that
you presume I want?

put together into a real app by amateurs will end up in a mess.

So it is your presumption that the hypothetical developers in India
are amateurs. Why did you hypothetically hire them?

d) Pull existing, proven code from other projects into this one and do
a lot of copy and pasting. The developers will need to do their own
trial and error, because none of the code is well documented and there
is no overall API or design to make the pieces fit together.

Are you familiar with the term "loaded question?"

e) Use a library like jquery. The browser environment is fixed and

And of course, here is the self-serving "answer."

supported by the library. The library is very well documented. There

So was the Holocaust.

are tons of examples. There is a support group where questions are

Bad examples. The support group has been shown to be made up of
people who regularly use jQuery.

quickly answered. It's free. The API is easily understood. The file

You get what you pay for of course. And the API is a horrible
abstraction. The solution to virtually everything is to call a
function named $. How intuitive. Not to mention the fact that lots
of other libraries use the same symbol for very different purposes.
No chance of confusion (or collision) there.

size is minimal. The amount of code to be written from scratch is

We've been over that. It is a 50K (minified) library that is all over
the map in terms of functionality. Chances are that your hypothetical
project will download lots of unused code.

greatly reduced and the potential for bugs is greatly reduced. It can

What?! The library that you have chosen to buttress your hypothetical
project is teeming with bugs of all shapes and sizes. How is starting
out with something that is buggy going to reduce the potential for
bugs?

be used from day 1 rather than waiting for a home-grown library to be

Who says this hypothetical project needs a library at all? You
haven't defined its goals at all.

created. It will be maintained and tested by others who will find bugs
and fringe cases that you would never think of - at no cost to you.

But wait, there's more! Act now and we will throw in a set of jQuery
commemorative steak knives. Lifetime warranty included. No payments
ever! This offer is void where prohibited. Warning: library may
explode.

Now, maybe you have a different perspective, but it's situations like
Maybe?

this that make me conclude that using a library like jquery is the
best choice. It would let me focus on bigger problems that are more

And what about the above drivel leads you to that conclusion?

complex, and put the load of generalized javascript development and
browser debugging on to someone else's hands. Is jquery perfect? Hell

Whose hands? The jQuery guy? Post back when your shuttle lands.

no. But it's probably better than what would have been written by my
offshore team. And it works without a single problem in the target

But you are the one who hypothetically hired the imagined team of
Indians to develop your undefined project. How can you say that
jQuery would be the best way to rectify what could hypothetically be
considered a mistake?

environment, enabling animations, effects, and functionality that

LOL. The jQuery animations are the worst of the lot. And where in
the unspecified specs did it say that the project required animations?

would have been out of the question if it needed to be coded from
scratch.

Oh absolutely. Animations would have been hypothetically out of the
question. The fact that even novices can produce simple animations,
like those found in jQuery, must have escaped you.

Could it break in browser X in 2 years? Perhaps. But hopefully that

But that isn't a hypothetical concern. You can just jump in your time
machine and retroactively fix them.

will mean just popping in an updated version of the library with the
same API. If it means taking a look at the code to try to fix a bug in

That assumes that people who cannot write a competent library today
are well-suited to create a competent library in the future, when
browser sniffing will be even less viable due to a proliferation of
devices that utilize embedded browsers. The authors' current stance
of "we don't care about those" wouldn't seem to justify this
assumption.

the library itself, so be it. It's still way more economical than

Voodoo economics.

coding from scratch. And it helps to manage risk, because jquery is
known to work right now, whereas writing code from scratch has a risk

That must be some newfangled usage of the words "known" and "work"
that I am unfamiliar with.

of failing or not being delivered in time or being unmaintainable.

So it is your position that code written and documented in-house by a
team that is picked according to their suitability for a given project
is harder to maintain than an open source black box that was written
by some random amateur with a blog.

JQuery isn't perfect. But it's way better than the alternatives that I
can see.

Your myopia is well-documented in this area. Did it occur to you that
there might be other alternatives for your hypothetical project?

This is what I call the "real world". As you can see, it has little to

See previous post.

do with whether or not a specific browser sniff is required or if a
particular code branch is actually unreachable. While getting that
stuff perfect is a great goal too, there are bigger and more important
issues to be considered.

You need to prove some points before launching into a summation.

I would love to work on projects where everyone knows exactly what
they are doing and there are dedicated JS developers who have
developed a robust internal set of tools that are documented and have
a solid API. So far that hasn't happened for me, and I haven't known
many places where that is the norm.

Then perhaps those places are in the wrong business?

I don't mindlessly advocate jquery. I'm not sure if I've ever

What do you call this post? It is no more cerebral than one of Mr.
Haney's sales pitches on Green Acres (Mr. Douglas, this library was
designed by John Resig and used to fend off twenty Indians in that
great hypothetical siege at jQuery junction.)

recommended it. What I have done, occasionally, is defend it for use
in situations where I think it solves a problem well.

But you never offer a clear explanation of what the problem is and why
your favorite library is the best way to tackle it.

Of course not.

So it isn't on an Intranet and it isn't on the Internet. Ah, I get it
now. It is another hypothetical.

Never going to happen. And can you believe that I actually use ActiveX
quite a bit? To access the filesystem, even? Unbelievable!


See above.

No thanks. I don't care for a rerun.

No! And can you believe that things still work perfectly?! Oh My God!
Inconceivable!

Not really. You stated that you only support IE6 (and likely only a
handful of its myriad configurations.) If you use a cinder block to
squash a fly, it will likely remain dead forever, but that doesn't
indicate that you needed the cinder block to accomplish this feat.

I am asking you nicely. Please stop posting your hypothetical
nonsense to this newsgroup. Thanks in advance for your cooperation.

 

[Matt Kruse]

I feel the need to stop the spread of misinformation and bad advice
related to browser scripting. I, for one, am tired of tripping over
easily preventable mistakes every time I browse the Web. It sometimes
seems there is not a usable page on the Internet.

I don't see all these errors that annoy you. I browse the web every
day, and sometimes I see the error count tick in my firebug bar, but I
rarely have any problems actually using any sites. Perhaps your
favorite midget porn sites are just poorly coded?

What is the point of this checklist?

The point was to list some things that need to be considered when
choosing a javascript strategy in addition to just the internal
technical quality of a library.

Again, you are trying to bend a project to best match an arbitrary
team of developers. This is ridiculous advice.

Have you never faced a situation where you needed to do so? Consider
yourself lucky. And inexperienced.

LOL. Thanks for the keen insight into your shop.

This is not insight into my shop, but into the reality that faces
many, many development efforts out there. Perhaps you work in an ideal
situation where you have lots of funding, adequate staff, and very
experienced developers for each piece of what you are building. I
would say that many people doing web development do not have such
luxuries. Of course, you are welcome to just ignore this fact if it is
inconvenient to your argument.

You are inventing a scenario which you hope will lead to a
hypothetically optimal solution that involves jQuery. I'll ask again:
are you serious?

I am pointing out a potentially REAL scenario where using a library
like jQuery is a benefit. If you choose to simply not believe that
this is a real situation that requires a real solution, then obviously
it's easy for you to maintain your naive beliefs.

Your myopia is well-documented in this area. Did it occur to you that
there might be other alternatives for your hypothetical project?
Like?

Then perhaps those places are in the wrong business?

I don't know why I hold out hope that you will someday be rational and
understand the bigger picture of what people struggle with who are not
you. If ignorance is bliss, you must be the happiest person on earth.

The reason that I can easily dismiss your views, and why others
reading this thread now or in the future should do the same, is
because you refuse to consider scenarios that don't fit within your
ideal model.

If your project can have a javascript expert on the team who can write
robust, customized, reusable code and evolve an in-house library of
sorts that can be documented, tested, and applied to future projects,
then OF COURSE that would be the best option. I would never consider
using a public javascript library in such a situation. Your conclusion
that no one should use generalized libraries seems to stem from the
assumption that everyone has this kind of development environment
available to them.

This, of course, is completely not true.

The reason I lay out this kind of "hypothetical" situation is because
it's closer to what many people deal with when creating web sites and
applications.
Perhaps a single guy is working for free for his public library.
Perhaps a small team at a private company is trying to build some web
apps for internal use and additional resources or funding is not even
an option.
Perhaps an established team is asked to put new client-side
functionality in an existing app ASAP and is looking for the fastest,
easiest, cheapest way to do it.
Perhaps a local non-profit organization is trying to create a little
intranet for themselves using the people they have on staff who have
limited web development experience.

There are all kinds of real-world development situations where your
"solutions" are not even an option. For these people, you simply have
no answer. You have no solution. You cannot offer a plan that will do
what they want and also fit within existing constraints. Your only
answer to them seems to be "You're stupid for trying to do that.
Either do it right or don't do it at all."

THESE are the situations and THESE are the people who benefit from
generalized libraries. They can achieve their goals and stay within
their limitations, and in most cases never have a problem. How can you
argue that this is not a good answer for them? You would offer them
nothing. At least if they use a generalized library they will get most
of what they want. If their site doesn't work in a browser that .5% of
visitors use, they may not even care. If it has a glitch that causes
something to be off by a few pixels, that may be easily ignored
because of all the benefits they've gained. If in 2 years their site
doesn't work with IE8 they may simply re-write it, or not even care at
all if the app is no longer being used.

The point is, you choose to dismiss generalized libraries as solutions
because you prefer to bury your head in the sand and pretend that the
situations where they are actually beneficial do not exist.

If you choose to be naive and believe that everyone in the world
develops in the utopia that you apparently do, then it's easy to see
why you can hold on to your opinion.

I post things like this for the benefit of others who may read this
now or in the future, trying to get an understanding of the pros and
cons of using generalized libraries. I'm not going to waste any more
of my time trying to convince you that there is a world out there that
is not and will never be your ideal development environment. Until you
realize that, your opinion on the use of generalized libraries is
uninformed and without value.

Matt Kruse

 

[timothytoe]

I feel the need to stop the spread of misinformation and bad advice
related to browser scripting. I, for one, am tired of tripping over
easily preventable mistakes every time I browse the Web. It sometimes
seems there is not a usable page on the Internet. Even worse,
disabling scripting does not typically increase usability, but only
serves to expose additional misconceptions of the responsible
designers and developers. And most irritating of all, any attempt to
dispel myths and ill-conceived notions about Web development seems to
draw legions of half-wits who proceded to dilute relevant criticism
with irrational (and often nonsensical) ramblings. Call it "esprit de
twits."

half-wits, twits

This is a great example of the personal insults that keep this thread
in the gutter. Attack the bad work, not the people.

 

[David Mark]

I don't see all these errors that annoy you. I browse the web every
day, and sometimes I see the error count tick in my firebug bar, but I

I had to close two error alerts in IE just to navigate to this post in
Google Groups.

rarely have any problems actually using any sites. Perhaps your
favorite midget porn sites are just poorly coded?

You don't help yourself do you? Such an ill-advised attempt at humor
smacks of desperation.

The point was to list some things that need to be considered when
choosing a javascript strategy in addition to just the internal
technical quality of a library.

It played more like an informercial for jQuery to me.

Have you never faced a situation where you needed to do so? Consider
yourself lucky. And inexperienced.

LOL. Consider yourself lucky that I even respond to your nonsensical
ramblings. If it weren't for the fact that you could potentially
poison the thinking of others, you would be talking to a dial tone at
this point.

This is not insight into my shop, but into the reality that faces
many, many development efforts out there. Perhaps you work in an ideal

Your "argument" has many, many holes in it.

situation where you have lots of funding, adequate staff, and very
experienced developers for each piece of what you are building. I
would say that many people doing web development do not have such

Then they should constrain the scope of their development to areas
that they are competent to handle. That might cut down on the errors
per page viewed on the Internet.

luxuries. Of course, you are welcome to just ignore this fact if it is
inconvenient to your argument.

You are like a broken record. And what "fact" are you referring to?
What you "would say" does not constitute a fact but something you
could be expected to say. If it did, then "jQuery is really cool
library that works great" would be a fact.

I am pointing out a potentially REAL scenario where using a library

Shouting won't help either.

like jQuery is a benefit. If you choose to simply not believe that
this is a real situation that requires a real solution, then obviously

I never said it wasn't a real situation, nor that there was no real
way to remedy it. What I basically said is that jQuery is a problem,
not a solution.

it's easy for you to maintain your naive beliefs.

Weren't you the one who contended that jQuery used "very limited"
browser sniffing and was "not full of mistakes", just a few months
back. Who was it that set you straight on these very naive beliefs?
You're welcome.

Like?

Like anything. You didn't define your hypothetical project in any
sort of meaningful way, so it would be silly to pose concrete
solutions. The basic theme here is that jQuery is a problem, not a
solution.

I don't know why I hold out hope that you will someday be rational and
understand the bigger picture of what people struggle with who are not

Those who embark on enterprises that require skills and experience
that they don't have (or can't buy) create their own struggles. For
example, you might have made a first class ditch digger, but you
decided to build Web applications instead. The fact that you require
a crutch like jQuery to write scripts targeted for a single version of
IE is indicative of your relative lameness in this area and I predict
you will continue to struggle until you recognize this.

you. If ignorance is bliss, you must be the happiest person on earth.

You would have to be roughly 100% more humorous to be considered a
half-wit. Why struggle to be a Web developer-cum-comedian? Aren't
there any excavators hiring in your area?

The reason that I can easily dismiss your views, and why others

Dismiss all you want. I'll make more.

reading this thread now or in the future should do the same, is

Give it up. Your potential for influence is minimal at best.

because you refuse to consider scenarios that don't fit within your
ideal model.

I refuse to consider non-specific, hypothetical scenarios that seem to
be presented solely to promote your favorite library.

If your project can have a javascript expert on the team who can write
robust, customized, reusable code and evolve an in-house library of
sorts that can be documented, tested, and applied to future projects,
then OF COURSE that would be the best option. I would never consider

More drumbeat repetition and shouting. You've got nothing to say and
repeating it at a higher volume will not make it something.

using a public javascript library in such a situation. Your conclusion
that no one should use generalized libraries seems to stem from the

This discussion pertains to a handful of notorious libraries that are
known to be unusable.

assumption that everyone has this kind of development environment
available to them.

I neither assumed nor said anything of the sort.

This, of course, is completely not true.

Which, of course, doesn't matter as it isn't a view I expressed.
Hypothetically, it might matter if I had said such a thing, but in
reality, I did not. See the difference?

The reason I lay out this kind of "hypothetical" situation is because

What do the quotes indicate? You said yourself that the scenario was
made up.

it's closer to what many people deal with when creating web sites and
applications.

As opposed to "many, many" people. Can you quantify either of those
estimations? In a relative sense, I assume you are now speaking of
half the number of people as before.

Perhaps a single guy is working for free for his public library.

Your time might be better served volunteering at your local public
library.

Perhaps a small team at a private company is trying to build some web
apps for internal use and additional resources or funding is not even
an option.

Perhaps they'd be ill-advised to make design decisions concerning
JavaScript libraries without consulting free resources like this group
(your posts excluded of course.)

Perhaps an established team is asked to put new client-side
functionality in an existing app ASAP and is looking for the fastest,
easiest, cheapest way to do it.

And you purport that downloading and learning to use a monolithic and
alien JavaScript library is the fastest, easiest and cheapest way to
achieve some unspecified functionality for this hypothetical app?
Muddled point taken and discarded as rubbish.

Perhaps a local non-profit organization is trying to create a little
intranet for themselves using the people they have on staff who have
limited web development experience.

What, pray tell, would they need with Ajax and animations (your
typical selling points for jQuery.) And why would they need cross-
browser JavaScript (or scripted enhancements of any kind?)
Furthermore, are volunteers at this hypothetical soup kitchen likely
to be in a position to make informed decisions about JavaScript
libraries? You have gone around the bend at this point.

There are all kinds of real-world development situations where your
"solutions" are not even an option. For these people, you simply have

Again, what do the quotes indicate? You are hardly in a position to
mock my solutions (if that was your intention.)

no answer. You have no solution. You cannot offer a plan that will do

What people? What specific problem?

what they want and also fit within existing constraints. Your only
answer to them seems to be "You're stupid for trying to do that.

Who do you perceive that I would call stupid? Then again, never
mind. Your perceptions are beyond the scope of my interest at this
point.

Either do it right or don't do it at all."

It is folly to put words in my mouth when my real words are publicly
available.

THESE are the situations and THESE are the people who benefit from

Oh you miserable... Lower your voice and stop repeating everything to
death.

generalized libraries. They can achieve their goals and stay within
their limitations, and in most cases never have a problem. How can you
argue that this is not a good answer for them? You would offer them

What was the specific question? Who asked it?

nothing. At least if they use a generalized library they will get most
of what they want. If their site doesn't work in a browser that .5% of
visitors use, they may not even care. If it has a glitch that causes

Here we go. Back to browser statistics again. Are you kidding?

something to be off by a few pixels, that may be easily ignored
because of all the benefits they've gained. If in 2 years their site

What hypothetical benefits? What were the goals of this imagined
project again? Did it involve pixel-perfect positioning?

doesn't work with IE8 they may simply re-write it, or not even care at

Sure. Rewrite the whole thing in two years, perhaps with some other
library (jQuery will likely be a memory by then.) Why not give back
most or all of the time that was hypothetically saved?

all if the app is no longer being used.

Hypothetically, that's possible. Of course, hypothetically, you could
know what you are talking about and possess the ability to communicate
it to others in a clear and concise fashion. It hasn't been
demonstrated here, but it is a remote, hypothetical possibility.

The point is, you choose to dismiss generalized libraries as solutions

I think this is where I came in.

because you prefer to bury your head in the sand and pretend that the
situations where they are actually beneficial do not exist.

Yep. I remember this part.

If you choose to be naive and believe that everyone in the world
develops in the utopia that you apparently do, then it's easy to see
why you can hold on to your opinion.

Time to go. This part is really boring.

I post things like this for the benefit of others who may read this
now or in the future, trying to get an understanding of the pros and
cons of using generalized libraries. I'm not going to waste any more

Thumbs down. The main character was not believable. I just didn't
buy him as a present or future influence of note. He came off as a
repetitious rube.

of my time trying to convince you that there is a world out there that
is not and will never be your ideal development environment. Until you

What did I tell you about the your real world vs. utopia non-
argument? You should cut that particular bait.

realize that, your opinion on the use of generalized libraries is

Your perception of my opinions are skewed, much like your thinking.

uninformed and without value.

Your appraisal of the value of your perception of my opinions about
hypothetical situations seems to be inaccurate. Of course, it is hard
to quantify such things.

 

[David Mark]

half-wits, twits

This is a great example of the personal insults that keep this thread
in the gutter. Attack the bad work, not the people.

Don't take my general comments personally "TimothyToe." They weren't
specifically aimed at you (though some of your trolling posts in this
thread do resemble my remarks.)

 

[Matt Kruse]

I had to close two error alerts in IE just to navigate to this post in
Google Groups.

You should have saved your time and not bothered.

Matt Kruse