Javascript Library

[shapper]

Hello,

I would like to use a javascript library to simplify my coding
process.
I know a few: JQuery, Dojo, Yahoo UI, ...

Which one do you advice me to use?

Thanks,
Miguel

[Thomas 'PointedEars' Lahn]

shapper wrote:

I would like to use a javascript library to simplify my coding
process. I know a few: JQuery, Dojo, Yahoo UI, ...

Which one do you advice me to use?

Until further notice: yours.
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16

[Peter Michaux]

On Oct 28, 5:48 pm, shapper <[e-mail]:

Hello,

I would like to use a javascript library to simplify my coding
process.
I know a few: JQuery, Dojo, Yahoo UI, ...

Which one do you advice me to use?

This question comes up frequently on comp.lang.javascript. There is
currently a thread that shows the feeling of many of the regulars here
that none of these libraries will do...

<URL: http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/0939ea42f3f7647f/7913289a7a41be97#7913289a7a41be97>

Peter

[Brian Adkins]

On Oct 28, 8:50 pm, Thomas 'PointedEars' Lahn <[e-mail]>
wrote:

shapper wrote:

I would like to use a javascript library to simplify my coding
process. I know a few: JQuery, Dojo, Yahoo UI, ...

Which one do you advice me to use?

Until further notice: yours.

Richard, do you still assert that no one is saying "write it all
yourself"?

[David Mark]

On Oct 29, 11:26 am, Brian Adkins <[e-mail]:

On Oct 28, 8:50 pm, Thomas 'PointedEars' Lahn <[e-mail]>
wrote:

shapper wrote:

I would like to use a javascript library to simplify my coding
process. I know a few: JQuery, Dojo, Yahoo UI, ...

Which one do you advice me to use?

Until further notice: yours.

Richard, do you still assert that no one is saying "write it all
yourself"?

I don't see Richard in this thread. Regardless, your library does not
have to be 100% self-written. IIRC, Richard stated something to that
effect in the other "please recommend a library" thread.

[Matt Kruse]

On Oct 28, 7:48 pm, shapper <[e-mail]:

I would like to use a javascript library to simplify my coding
process.
I know a few: JQuery, Dojo, Yahoo UI, ...
Which one do you advice me to use?

There are pros and cons to each, but I recommend jQuery. It is
powerful, compact, easy to understand, and has an active support
community.

Matt Kruse

[David Mark]

On Oct 29, 12:01 pm, Matt Kruse <[e-mail]:

On Oct 28, 7:48 pm, shapper <[e-mail]:

I would like to use a javascript library to simplify my coding
process.
I know a few: JQuery, Dojo, Yahoo UI, ...
Which one do you advice me to use?

There are pros and cons to each, but I recommend jQuery. It is

The first two are right out. Why take the time to learn an API that
has terrible code behind it. People would be better off spending time
writing their own terrible code. At least they would learn something
worthwhile in the process.

powerful, compact, easy to understand, and has an active support
community.

Powerful perhaps, but the copy I have here is 82K. Perhaps it would
lose 30K or so minified.

Having recently looked over the code, I can tell you it is poorly
written and full of mistakes. Any time saved coding will come back to
you in maintenance and trouble-shooting.

[Matt Kruse]

On Oct 29, 11:25 am, David Mark <[e-mail]:

The first two are right out. Why take the time to learn an API that
has terrible code behind it. People would be better off spending time
writing their own terrible code.

Learning the API takes, perhaps, a few hours. Even if it does have
terrible code behind it (it does not), the improvement in end result
will still be beneficial to most, because most are already writing
terrible code that doesn't even have the benefit of working most of
the time.

Powerful perhaps, but the copy I have here is 82K. Perhaps it would
lose 30K or so minified.

There is a minified download option. Check it out.

Having recently looked over the code, I can tell you it is poorly
written and full of mistakes.

Without any examples or real critiques to back up that broad
statement, it's worthless.

I've been writing javascript for over 10 years, and I've seen poorly
written code. jQuery is not poorly written. Nor is it "full of
mistakes".

I can see things in the code that I would change and improve, and a
number of them are actually already in as tickets for changes in
future versions. No free collaborative effort is without its problems.

Would you also throw out the Wikipedia as "junk" because you find an
article with technical errors?

Any time saved coding will come back to
you in maintenance and trouble-shooting.

My real-world experience differs from your hypothesis. I can measure
the _huge_ benefits of using jQuery in real dollars, and it is
significant.

I'd love to hear about your experience with jQuery and the maintenance
and trouble-shooting that you were required to do.

Matt Kruse

[David Mark]

On Oct 29, 12:47 pm, Matt Kruse <[e-mail]:

On Oct 29, 11:25 am, David Mark <[e-mail]:

The first two are right out. Why take the time to learn an API that
has terrible code behind it. People would be better off spending time
writing their own terrible code.

Learning the API takes, perhaps, a few hours. Even if it does have
terrible code behind it (it does not), the improvement in end result

Run it through JSLint. Then search it for "userAgent." Then look at
the logic that tests for a function. That's three strikes right
there.

will still be beneficial to most, because most are already writing
terrible code that doesn't even have the benefit of working most of
the time.

How is it beneficial to swap one's own terrible code for the terrible
code of another. Is it easier to debug somebody else's code?

>

Powerful perhaps, but the copy I have here is 82K. Perhaps it would
lose 30K or so minified.

There is a minified download option. Check it out.

Isn't that what I said? Running it through a minifier will lose about
30K. I just tried it here and my estimation was almost exactly right.

>

Having recently looked over the code, I can tell you it is poorly
written and full of mistakes.

Without any examples or real critiques to back up that broad
statement, it's worthless.

Try searching this very newsgroup for jQuery. You will find lots of
examples.

>
I've been writing javascript for over 10 years, and I've seen poorly

Lots of people can make that claim. How many of them are competent to
script browsers?

written code. jQuery is not poorly written. Nor is it "full of
mistakes".

Then despite your vast experience with JavaScript, you still don't get
it.

>
I can see things in the code that I would change and improve, and a
number of them are actually already in as tickets for changes in

That's comforting.

future versions. No free collaborative effort is without its problems.

Would you also throw out the Wikipedia as "junk" because you find an
article with technical errors?

That is an odd comparison.

>

Any time saved coding will come back to
you in maintenance and trouble-shooting.

My real-world experience differs from your hypothesis. I can measure
the _huge_ benefits of using jQuery in real dollars, and it is
significant.

And how would you quantify the benefits of "using jQuery" in dollars?

>
I'd love to hear about your experience with jQuery and the maintenance

Having read the script, I concluded it was worthless. Therefore, I do
not use it.

and trouble-shooting that you were required to do.

By the same token, I do not have to trouble-shoot it.

[Matt Kruse]

On Oct 29, 12:42 pm, David Mark <[e-mail]:

Run it through JSLint.

Which is about as useful as validating HTML. Great for academic
purposes, perhaps it will catch a few errors, etc.
But in the end it doesn't matter if code passes analytics, just if it
accomplishes the goal or not. My goal never includes "pass
validation". Validation is merely a tool to reach my goal, when
needed.

Then search it for "userAgent."

Browser sniffing is not encouraged, and in some cases in jQuery it is
really unnecessary. There are cases where it is beneficial.
Rather than writing lengthy logic to solve for every possible case,
you can write shorter logic to solve for a subset of cases you care
about.
It's not ideal, but it is a strategy. The amount of browser sniffing
in jQuery is minimal.

Then look at the logic that tests for a function.

It may not be perfect, but have you ever come across a real-world case
where it has failed for you?

Me neither.

How is it beneficial to swap one's own terrible code for the terrible
code of another. Is it easier to debug somebody else's code?

jQuery's code is not terrible. It is a substantial improvement over
most javascript code written by average developers. In my experience.

There is a minified download option. Check it out.

Isn't that what I said? Running it through a minifier will lose about
30K. I just tried it here and my estimation was almost exactly right.

The packed version is 26kb. Plenty small.

Having recently looked over the code, I can tell you it is poorly
written and full of mistakes.

Without any examples or real critiques to back up that broad
statement, it's worthless.

Try searching this very newsgroup for jQuery. You will find lots of
examples.

But why should I look up past examples? You said you recently looked
over the code and found that it was poorly written and full of
mistakes.
Surely you could provide some examples from your recent investigation?

I've been writing javascript for over 10 years, and I've seen poorly

Lots of people can make that claim. How many of them are competent to
script browsers?

I'm not sure "lots of people can make that claim". I consider myself
to be very knowledgeable about Javascript development, and I disagree
with your conclusions. Surely not everyone who disagrees with you is
categorically an amateur?

written code. jQuery is not poorly written. Nor is it "full of
mistakes".

Then despite your vast experience with JavaScript, you still don't get
it.

What don't I get? You are not providing any actual arguments. You
might as well just say "You're stupid!" and stick your tongue out.

Further, have you considered that perhaps it is you who just doesn't
get it?

Would you also throw out the Wikipedia as "junk" because you find an
article with technical errors?

That is an odd comparison.

Perhaps. The point is, just because you notice a few flaws in
something does not mean it is worthless. It merely means it has flaws.
Which means it was probably developed by humans. If your goal is
perfection, you'll never find it.

My real-world experience differs from your hypothesis. I can measure
the _huge_ benefits of using jQuery in real dollars, and it is
significant.

And how would you quantify the benefits of "using jQuery" in dollars?

#1:
(Previous time to develop functionality) - (current time to develop
similar functionality) = Time Savings
Time Savings * Pay Rate = Money Saved

#2:
(Number of JS bugs before) - (Number of JS bugs now) = Bug Savings
(Bug Savings) * (Avg Time to Fix JS Bugs) * Pay Rate = Money Saved

Consider the effects of introducing jquery to a large development
team:
1) Reduced time implementing similar functionality as before
2) Reduced number of bugs
3) Improvement of UI because developers have access to pre-made
plugins
4) Less time needed to write functionality from scratch and research
browser quirks
5) No problem reports from any end users

Now, how are you arguing that using jquery is not a huge benefit?

You would recommend that we stop using it and start coding from
scratch?

I'd love to hear about your experience with jQuery and the maintenance

Having read the script, I concluded it was worthless. Therefore, I do
not use it.

Then how would you know anything about an increase in maintenance
caused by using jQuery?
Can you quote the experience of anyone else who has used it and found
it to be a maintenance problem?
Or hell, can you quote anyone who has used it and found it to be a bad
decision for any reason?
Do you have any real-world experience with it?
If not, how do you possibly feel justified in criticizing it?

Matt Kruse

[Jeff North]

On Mon, 29 Oct 2007 14:42:48 -0700, in comp.lang.javascript David Mark
<dm***********@gmail.com>
<11**********************@22g2000hsm.googlegroups. comwrote:

Thank you for the insightful review of jQuery.
Could you please tell me where I can get a copy of your js library?
-- -------------------------------------------------------------
jn******@yourpantsyahoo.com.au : Remove your pants to reply
-- -------------------------------------------------------------

[Evertjan.]

Jeff North wrote on 30 okt 2007 in comp.lang.javascript:

Thank you for the insightful review of jQuery.
Could you please tell me where I can get a copy of your js library?

What and to who are you replying, Jeff?

[please always quote on usenet]

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[David Mark]

On Oct 30, 7:50 am, Jeff North <[e-mail]:

On Mon, 29 Oct 2007 14:42:48 -0700, in comp.lang.javascript David Mark
<[e-mail]>

<[e-mail]. comwrote:

Thank you for the insightful review of jQuery.
Could you please tell me where I can get a copy of your js library?

You cannot. Though I have recently considered posting the basic
essentials as a foundation for those who wish to write their own
libraries.

[Matt Kruse]

On Oct 29, 4:42 pm, David Mark <[e-mail]:

[jQuery criticisms]
Enough is enough. If you use jQuery after reading this, you are
deserve everything you get.

Thank you for your detailed reply. I am going to investigate these
things further and find out if jQuery can be improved.

I haven't done an extensive look "under the hood" of jQuery, but I
have looked at some of the code. I've also noticed examples of
questionable code, but I assumed there was a reason for them doing
things the way they do. I've never had a problem with jQuery not
functioning correctly. As long as I see the expected behavior right
now, the underlying code can be streamlined and improved. All the
issues you mention can be fixed and improved while still maintaining
the same API, making the library more solid without the end-user even
knowing about the changes.

If
you take an average JavaScript developer and give them this mess to
play with, are you really empowering them to write competent
applications?

I still think so, yes. Having a developer program to the API to
simplify their development is a good thing. It's a layer over the low-
level stuff, but that enables them to be much more productive. If
there is a problem found in the library behavior, it can be fixed.

If you use or advocate jQuery after today, you are stupid.

I will continue to use it and advocate it. I'll also try to improve
it.

I guess I'm stupid.

(Previous time to develop functionality) - (current time to develop
similar functionality) = Time Savings
Time Savings * Pay Rate = Money Saved

Oversimplification.

Really?

You would recommend that we stop using it and start coding from
scratch?

Why do library-advocates invariably see just those two choices?

Because library-critics rarely provide any real answers or
suggestions. Just criticisms.

It's easy to question everything. It's much harder to provide a real
answer.

I have little respect for people who constantly bitch about what
everyone else provides for free to the world, yet never actually
provide anything themselves.

If everyone else is doing it wrong, and you know how to do it right,
why don't you show the world how it should be done? Those who are the
supposed "experts" that bash everyone else rarely put their own
libraries and code up for public consumption and criticism. I have
respect for people like Peter who is obviously an intelligent and
knowledgeable contributor to this group and has also put his own
library out there. If the more vocal critics would do the same,
perhaps these other "horrible" libraries would die out and the world
would be a better place.

Matt Kruse

[Evertjan.]

vbgunz wrote on 30 okt 2007 in comp.lang.javascript:

there needs to be a DOM library.

Why?

anyone know of one?

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[Doug Miller]

In article <11**********************@22g2000hsm.googlegroups. com>, David Mark <dm***********@gmail.comwrote:

>On Oct 30, 12:12 pm, Matt Kruse <[e-mail]:

>On Oct 30, 9:50 am, David Mark <[e-mail]:

Could you please tell me where I can get a copy of your js library?
You cannot.

Why not?

Because I don't want to give it to him.

So sell it. <g>

--
Regards,
Doug Miller (alphageek at milmac dot com)

It's time to throw all their damned tea in the harbor again.

[David Mark]

On Oct 30, 1:27 pm, [e-mail] (Doug Miller) wrote:

In article <[e-mail]. com>, David Mark <[e-mail]:

On Oct 30, 12:12 pm, Matt Kruse <[e-mail]:

On Oct 30, 9:50 am, David Mark <[e-mail]:

Could you please tell me where I can get a copy of your js library?
You cannot.

Why not?

Because I don't want to give it to him.

So sell it. <g>

I have, in the past, considered selling JavaScript libraries and
widgets, but it seems to me that too many people are giving them
away. Factor in that most potential customers are unable to evaluate
code quality and you get a pretty lousy market outlook.

[Jeff North]

On Tue, 30 Oct 2007 14:54:20 -0000, in comp.lang.javascript Matt Kruse
<ma**@mattkruse.com>
<11*********************@o3g2000hsb.googlegroups.c omwrote:

>| On Oct 29, 4:42 pm, David Mark <[e-mail]:
| [jQuery criticisms]
| Enough is enough. If you use jQuery after reading this, you are
| deserve everything you get.
|
| Thank you for your detailed reply. I am going to investigate these
| things further and find out if jQuery can be improved.
|
| I haven't done an extensive look "under the hood" of jQuery, but I
| have looked at some of the code. I've also noticed examples of
| questionable code, but I assumed there was a reason for them doing
| things the way they do. I've never had a problem with jQuery not
| functioning correctly. As long as I see the expected behavior right
| now, the underlying code can be streamlined and improved. All the
| issues you mention can be fixed and improved while still maintaining
| the same API, making the library more solid without the end-user even
| knowing about the changes.
|
| If
| you take an average JavaScript developer and give them this mess to
| play with, are you really empowering them to write competent
| applications?
|
| I still think so, yes. Having a developer program to the API to
| simplify their development is a good thing. It's a layer over the low-
| level stuff, but that enables them to be much more productive. If
| there is a problem found in the library behavior, it can be fixed.
|
| If you use or advocate jQuery after today, you are stupid.
|
| I will continue to use it and advocate it. I'll also try to improve
| it.
|
| I guess I'm stupid.
|
| (Previous time to develop functionality) - (current time to develop
| similar functionality) = Time Savings
| Time Savings * Pay Rate = Money Saved
| Oversimplification.
|
| Really?
|
| You would recommend that we stop using it and start coding from
| scratch?
| Why do library-advocates invariably see just those two choices?
|
| Because library-critics rarely provide any real answers or
| suggestions. Just criticisms.
|
| It's easy to question everything. It's much harder to provide a real
| answer.
|
| I have little respect for people who constantly bitch about what
| everyone else provides for free to the world, yet never actually
| provide anything themselves.
|
| If everyone else is doing it wrong, and you know how to do it right,
| why don't you show the world how it should be done? Those who are the
| supposed "experts" that bash everyone else rarely put their own
| libraries and code up for public consumption and criticism. I have
| respect for people like Peter who is obviously an intelligent and
| knowledgeable contributor to this group and has also put his own
| library out there. If the more vocal critics would do the same,
| perhaps these other "horrible" libraries would die out and the world
| would be a better place.
|
| Matt Kruse

Couldn't agree more.
What better place (c.l.j.) to show novice programmers the correct way
to code and also provide a resource of a robust library.
-- -------------------------------------------------------------
jn******@yourpantsyahoo.com.au : Remove your pants to reply
-- -------------------------------------------------------------

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn wrote:

[...] You may rest assured that I will continue to review
and, where necessary, refactor the code on a regular basis.

I would like to add that any constructive feedback regarding my code
between review cycles is appreciated of course. Thank you in advance.
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann

[Doug Miller]

In article <11**********************@y42g2000hsy.googlegroups .com>, David Mark <dm***********@gmail.comwrote:

>On Oct 30, 1:27 pm, [e-mail] (Doug Miller) wrote:

>In article <[e-mail]. com>, David Mark

<[e-mail]:

>>

>On Oct 30, 12:12 pm, Matt Kruse <[e-mail]:
On Oct 30, 9:50 am, David Mark <[e-mail]:

Could you please tell me where I can get a copy of your js library?
You cannot.

>Why not?

>Because I don't want to give it to him.

So sell it. <g>

I have, in the past, considered selling JavaScript libraries and
widgets, but it seems to me that too many people are giving them
away. Factor in that most potential customers are unable to evaluate
code quality and you get a pretty lousy market outlook.

Free stuff is often worth not much more than the price paid. If yours is
enough better than the free stuff, your market might be larger than you think.

--
Regards,
Doug Miller (alphageek at milmac dot com)

It's time to throw all their damned tea in the harbor again.

[David Mark]

On Oct 30, 6:09 pm, [e-mail] (Doug Miller) wrote:

In article <[e-mail] .com>, David Mark <[e-mail]:

On Oct 30, 1:27 pm, [e-mail] (Doug Miller) wrote:

In article <[e-mail]. com>, David Mark

<[e-mail]:

On Oct 30, 12:12 pm, Matt Kruse <[e-mail]:
On Oct 30, 9:50 am, David Mark <[e-mail]:

Could you please tell me where I can get a copy of your js library?
You cannot.

Why not?

Because I don't want to give it to him.

So sell it. <g>

I have, in the past, considered selling JavaScript libraries and
widgets, but it seems to me that too many people are giving them
away. Factor in that most potential customers are unable to evaluate
code quality and you get a pretty lousy market outlook.

Free stuff is often worth not much more than the price paid. If yours is
enough better than the free stuff, your market might be larger than you think.

But don't you think a large portion of that market would just steal
the code?

[tony.gurnick]

you could also argue that an "Ultimate Javascript Library" that I cant
have is infinitley more useless than a badly coded, in-efficient
library that I can have.

[Brian Adkins]

On Oct 31, 12:32 am, Peter Michaux <[e-mail]:

On Oct 30, 8:26 pm, Brian Adkins <[e-mail]:
It was intended to be obviously unreasonable.

Thank you for your honesty.

Do you reuse code from others? If so, what are the sources of code
that you've found valuable.

YUI and other libraries

Care to name even one in addition to YUI. Don't worry about
requirements, specs, contexts. Since YUI is the only one folks have
offered up, I'm just curious if another exists. Even a small one
that's used by more than a handful of people would be good.

I was being an ass

Agreed.

Perhaps "valuable, time saving libraries" are readily available in the
Common Lisp world but not in the JavaScript world.

Gee, do you think that's the question I've been vainly trying to get
answered? But Peter, how can you make that conjecture without a spec,
requirement or context? That's a joke - don't answer it.

Somewhere communication has broken down.

Yes.

It seems you think you have
clearly stated your library specs.

Peter, only an idiot would think that I had clearly stated "library
specs", or more importantly that it was my intention to do so, so I
must assume that you consider me an idiot. There will be no Christmas
card forthcoming.

How can you miss something so simple? I am^H^Hwas simply trying to get
a feel for which "preexisting code written by people other than me" is
worthwhile to consider using in future projects before I reinvent the
wheel myself. Does that make sense to you? It makes sense to others.
Does it seem like a reasonable quest? It does to others.

Really - ask some people at your workplace as a poll. This group is
biased beyond hope at this point. Just ask them, "Hey, some guy on
comp.lang.javascript asked whether there were any publicly available
JavaScript libraries that were worthwhile to use. So he's an idiot,
right? I mean, he didn't even provide a spec or set of requirements
for that question! How can we possibly interpret that question without
a spec. So, really, he's an idiot, right? There was no context to
guides us or anything." Something like that. Let me know how it goes.

You've assumed people will imply
the same things you have implied in you requirements but that hasn't
appeared to be the case.

Wrong, and you know it, as you admitted with respect to your little
game with the logging code. You knew that was ridiculous, yet you
couldn't think of something that wasn't? Peter, you act as if the
question was so vague as to imply there were far too many answers to
post, and yet the only thing mentioned in hundreds of posting is that
YUI might be worth checking out. Imagine if I had provided a detailed
set of requirements - the options would have been narrowed from 1 to
0.

Currently it takes a newcomer an
unreasonably long time to gather all the information.

I wonder why that is? ;)

[Doug Miller]

In article <11**********************@o3g2000hsb.googlegroups. com>, David Mark <dm***********@gmail.comwrote:

>On Oct 30, 6:09 pm, [e-mail] (Doug Miller) wrote:

>In article <[e-mail] .com>, David

Mark <[e-mail]:

>>

>On Oct 30, 1:27 pm, [e-mail] (Doug Miller) wrote:
In article <[e-mail]. com>, David

Mark

<[e-mail]:

>On Oct 30, 12:12 pm, Matt Kruse <[e-mail]:
On Oct 30, 9:50 am, David Mark <[e-mail]:

Could you please tell me where I can get a copy of your js library?
You cannot.

>Why not?

>Because I don't want to give it to him.

>So sell it. <g>

>I have, in the past, considered selling JavaScript libraries and
widgets, but it seems to me that too many people are giving them
away. Factor in that most potential customers are unable to evaluate
code quality and you get a pretty lousy market outlook.

Free stuff is often worth not much more than the price paid. If yours is
enough better than the free stuff, your market might be larger than you

think.

>>

But don't you think a large portion of that market would just steal
the code?

Well, sure, if you're silly enough to post it someplace where it can be
downloaded without paying for it first.

--
Regards,
Doug Miller (alphageek at milmac dot com)

It's time to throw all their damned tea in the harbor again.

[Peter Michaux]

On Oct 30, 10:12 pm, Brian Adkins <[e-mail]:

On Oct 31, 12:32 am, Peter Michaux <[e-mail]:

On Oct 30, 8:26 pm, Brian Adkins <[e-mail]:
It was intended to be obviously unreasonable.

Thank you for your honesty.

Do you reuse code from others? If so, what are the sources of code
that you've found valuable.

YUI and other libraries

Care to name even one in addition to YUI. Don't worry about
requirements, specs, contexts. Since YUI is the only one folks have
offered up, I'm just curious if another exists. Even a small one
that's used by more than a handful of people would be good.

I already offered mine and the code in the group's faq notes. Also
checkout JavaScript toolbox and Ajax Toolbox my Matt Kruse. Google
will help you find them. I don't know if any of them will be helpful
with your task at hand.

It seems you think you have
clearly stated your library specs.

Peter, only an idiot would think that I had clearly stated "library
specs", or more importantly that it was my intention to do so, so I
must assume that you consider me an idiot. There will be no Christmas
card forthcoming.

How can you miss something so simple? I am^H^Hwas simply trying to get
a feel for which "preexisting code written by people other than me" is
worthwhile to consider using in future projects before I reinvent the
wheel myself. Does that make sense to you? It makes sense to others.
Does it seem like a reasonable quest? It does to others.

But "reasonable scope" and "any scope" have both been part of the
requirements. Its been a moving target.

People are very reluctant to give such general recommendations. There
must be a reason for being so cautious.

It seems now you've made it concrete and want to know if there is
*any* code at all worth reusing with no other requirements at all.

There is almost an infinite amount of JavaScript code available. Use
google to find code related to your task and evaluate the code if it
is worth reuse. You can at least use reuse the code educationally.

Really - ask some people at your workplace as a poll. This group is
biased beyond hope at this point. Just ask them, "Hey, some guy on
comp.lang.javascript asked whether there were any publicly available
JavaScript libraries that were worthwhile to use. So he's an idiot,
right? I mean, he didn't even provide a spec or set of requirements
for that question! How can we possibly interpret that question without
a spec. So, really, he's an idiot, right? There was no context to
guides us or anything." Something like that. Let me know how it goes.

You've assumed people will imply
the same things you have implied in you requirements but that hasn't
appeared to be the case.

Wrong, and you know it,

Actually I think that has been the problem.

as you admitted with respect to your little
game with the logging code. You knew that was ridiculous, yet you
couldn't think of something that wasn't?

That is how difficult the question was.

Peter, you act as if the
question was so vague as to imply there were far too many answers to
post, and yet the only thing mentioned in hundreds of posting is that
YUI might be worth checking out.

Take something from that.

Imagine if I had provided a detailed
set of requirements - the options would have been narrowed from 1 to
0.

If you had said form validation then YUI would not have been
mentioned. If you said event libraries it might.

Currently it takes a newcomer an
unreasonably long time to gather all the information.

I wonder why that is? ;)

When new, it is difficult to even know the questions to ask. That was
a big problem for me.

I don't know if it will help with your task I think you should use YUI
for a while.

Peter

[Brian Adkins]

On Oct 31, 8:24 am, Peter Michaux <[e-mail]:

I already offered mine and the code in the group's faq notes.

I did bother to check http://www.jibbering.com/faq/ before posting and
didn't find anything. That site mentions faq_notes here:
http://www.jibbering.com/faq/faq_notes/faq_notes.html

but I didn't see your code there, nor were you listed as a
contributor, so maybe there's another set of "group's faq notes"
somewhere?

Also
checkout JavaScript toolbox and Ajax Toolbox my Matt Kruse.

Thanks

It seems now you've made it concrete and want to know if there is
*any* code at all worth reusing with no other requirements at all.

That's been that case for quite some time. I proceeded as follows:

1) it seems people here think all libraries suck
*therefore*
2) I wonder if there is *any* code that can be recommended

If the responses showed that there were many libraries worth looking
into, then I naturally would need to ask a more specific question, but
that has hardly been the case.

There is almost an infinite amount of JavaScript code available. Use
google to find code related to your task and evaluate the code if it
is worth reuse.

Peter, I don't understand why you made this statement. The purpose in
asking a question such as the one I asked is to avoid spending an
"infinite" amount of time evaluating code, but instead to attempt to
gain from the experience of others. The value of the experience of
other people can range from harmful to helpful, but it can sometimes
narrow down the search to a feasible set of candidates nonetheless.

That is how difficult the question was.

I'm still waiting for the workplace poll results ;)

[Peter Michaux]

On Oct 31, 7:43 am, Brian Adkins <[e-mail]:

On Oct 31, 8:24 am, Peter Michaux <[e-mail]:

I already offered mine and the code in the group's faq notes.

I did bother to check http://www.jibbering.com/faq/ before posting and
didn't find anything. That site mentions faq_notes here:http://www.jibbering.com/faq/faq_notes/faq_notes.html

There are many code snips on those pages and on the pages to which
they link. You have to at least want to see the code for which you
search. For example, the FAQ has three functions for trimming string
whitespace without using regular expressions.

function LTrim(str) {
for (var k=0; k<str.length && str.charAt(k)<=" " ; k++) ;
return str.substring(k,str.length);
}
function RTrim(str) {
for (var j=str.length-1; j>=0 && str.charAt(j)<=" " ; j--) ;
return str.substring(0,j+1);
}
function Trim(str) {
return LTrim(RTrim(str));
}
Perhaps you have a particular format in which you need to see the code
libraries you are after. That could be baggage you carry coming from
another programming language and development style. There is no
established CPAN or PEAR for JavaScript. There is an attempt called
JSAN but that hasn't gained much traction and likely has not been
evaluated by many regulars here so has not been even a candidate for
recommendation in this thread. The baggage you carry could prevent you
from finding what you are after.

but I didn't see your code there, nor were you listed as a
contributor, so maybe there's another set of "group's faq notes"
somewhere?

There is only one set.

It seems now you've made it concrete and want to know if there is
*any* code at all worth reusing with no other requirements at all.

There is plenty in the group faq and faq notes. There is plenty in the
group archives. There is plenty on the web. There is plenty in the big
name libraries. It may not be in the finalized "library" format you
have been after at certain times in these threads but if you've
removed that requirement then there is plenty. It should be clear now
that there is not some ready made library that can be handed to the
newcomer that is "approved" for reuse in all situations. That is
either unfortunate or impossible.

That's been that case for quite some time. I proceeded as follows:

1) it seems people here think all libraries suck

They don't. They do see many flaws in the big name libraries and
prefer to use their own libraries. Some people use their own libraries
as modules they use as is and release versions to themselves. Some
people use their libraries as cut and paste resources.

*therefore*
2) I wonder if there is *any* code that can be recommended

I hope it is quite clear now that there is at least some code that can
be recommended and this question can die. The trim examples above are
enough to show there is some code that can be recommended.

If the responses showed that there were many libraries worth looking
into, then I naturally would need to ask a more specific question, but
that has hardly been the case.

There is almost an infinite amount of JavaScript code available. Use
google to find code related to your task and evaluate the code if it
is worth reuse.

Peter, I don't understand why you made this statement. The purpose in
asking a question such as the one I asked is to avoid spending an
"infinite" amount of time evaluating code

Just because there is an plethora of JavaScript on the web to evaluate
it doesn't mean you have to spend much time evaluating it. You can
look at the first few hits that google returns and that is usually
sufficient.

>, but instead to attempt to
gain from the experience of others.

Much advice has been offered.

The value of the experience of
other people can range from harmful to helpful, but it can sometimes
narrow down the search to a feasible set of candidates nonetheless.

That is how difficult the question was.

I'm still waiting for the workplace poll results ;)

I'm not asking.

Peter

[David Mark]

On Oct 30, 9:00 pm, "tony.gurnick" <[e-mail]>
wrote:

you could also argue that an "Ultimate Javascript Library" that I cant
have is infinitley more useless than a badly coded, in-efficient
library that I can have.

There is no such thing as an "Ultimate JavaScript Library." Clearly
you can't have what doesn't exist. However, as noted several times,
there are other options besides using code that is known to be lousy.

[Matt Kruse]

On Oct 31, 5:36 pm, David Mark <[e-mail]:

Do you think you are solving extremely unique problems?

Yes.

How so? You don't deal with reading/writing attributes, positioning
elements, showing/hiding objects, animating objects, ajax, etc?

Why not stop badgering me to post all of my code and make do with what
I have posted to this point?

Because you continue to say my way is stupid and your way is far
better, but you refuse to actually show your cards.
I'm calling your bluff, and you have nothing to show.

Isn't that the trust. In fact, it will add 50K of weight to it. As
previously noted, your packer argument doesn't hold water.

Packed, jQuery is 26k. That has nothing to do with compression or gzip
or anything. It's ~26,000 bytes of code. Plain text. Ascii. How is
that confusing?

You are a moron. Perhaps it hasn't occurred to you (or the OP) that
if you have n libraries to research and somebody pokes a hundred holes
in one of them, then your task is reduced to n - 1 libraries. You are
just upset because it happened to be the one you recommended.

I'm sure you could poke similar ridiculous "holes" in other libraries.
You're just an anti-library zealot who likes to complain about others
and yet has nothing to show for himself.

And on that note, I've started a discussion on the jQuery dev group
about some of the points you've made, and also some of my own
observations about the attr() function you singled out. You seem to be
unaware of some browser quirks and special cases that jQuery attempts
to address, so I wonder how well your own low-level code handles these
cases. In any case, I've recommended some alternate ways of coding
some parts and hopefully the code will only continue to improve. Much
to your dismay, I'm sure.

Matt Kruse

[David Mark]

On Oct 31, 9:27 pm, Matt Kruse <[e-mail]:

On Oct 31, 5:36 pm, David Mark <[e-mail]:

Do you think you are solving extremely unique problems?

Yes.

How so? You don't deal with reading/writing attributes, positioning
elements, showing/hiding objects, animating objects, ajax, etc?

Why not stop badgering me to post all of my code and make do with what
I have posted to this point?

Because you continue to say my way is stupid and your way is far
better, but you refuse to actually show your cards.
I'm calling your bluff, and you have nothing to show.

LOL. You are obviously very desperate to see my "cards." The funny
thing is that if you actually read this newsgroup (other than threads
about JavaScript libraries), you could piece together a fair amount of
my code. You want me to put it all together in a pretty package for
you. Forget it.

>

Isn't that the trust. In fact, it will add 50K of weight to it. As
previously noted, your packer argument doesn't hold water.

Packed, jQuery is 26k. That has nothing to do with compression or gzip
or anything. It's ~26,000 bytes of code. Plain text. Ascii. How is
that confusing?

You don't get it. Packer has everything to do with compression. And
it makes the standard GZIP compression less effective. It's stupid.
Do you use it for your scripts? Does anybody of note? It is
misleading to throw this "packed" length out there. Does a 50K
minified script download any faster if it is "packed" to 30K? Of
course not. It may in fact download slower. So it is stupid to use
it as a comparison. jQuery is 50K. Prototype is 80K. A 20K image is
20K. A 10K HTML page is 10K. HTTP and/or modems will compress these
assets during delivery, but most people (and tools) disregard that
when figuring page weights. A meaningful comparison requires all
things equal.

>

You are a moron. Perhaps it hasn't occurred to you (or the OP) that
if you have n libraries to research and somebody pokes a hundred holes
in one of them, then your task is reduced to n - 1 libraries. You are
just upset because it happened to be the one you recommended.

I'm sure you could poke similar ridiculous "holes" in other libraries.

Ridiculous?

You're just an anti-library zealot who likes to complain about others
and yet has nothing to show for himself.

You sound desperate. Why don't you use your own "toolkit" and stop
trying to wheedle code out of me.

>
And on that note, I've started a discussion on the jQuery dev group
about some of the points you've made, and also some of my own
observations about the attr() function you singled out. You seem to be
unaware of some browser quirks and special cases that jQuery attempts
to address, so I wonder how well your own low-level code handles these

Wrong. Apart from library threads, do you read this group at all? I
know all too well what they were trying to do and not only did they
botch it, but their comments indicate they have no idea what they were
doing or why.

cases. In any case, I've recommended some alternate ways of coding

In other words, you took all of my suggestions and ran with them. I
am sure the jQuery group will be eternally grateful for "your"
vigilence. Now you want more help. I would give your toolkits the
treatment, but I don't specifically want to help you and I know they
have already been panned ad nauseum here.

some parts and hopefully the code will only continue to improve. Much
to your dismay, I'm sure.

Why would I care?

[Matt Kruse]

On Oct 31, 5:34 pm, John Resig <[e-mail]:

Asked and answered? I still want to know what reak-world you are
from.

Probably the same one that Google, Amazon, IBM, AOL, etc. are from.

I think this is a point that needs to be made again -

If your arguments are that:
1) Large "do-everything" libraries are a bad design decision and the
wrong way to develop javascript for public sites
and/or
2) Limiting "officially" supported browsers to a subset of all
browsers that cover all but the most fringe users is a bad decision
and/or
3) Writing generalized functions that solve common problems in most
contexts and applying them liberally is a terrible, bloated,
inaccurate way to write code

then you are calling some of the biggest players on the web idiots.
The arguments I'm presenting here are not just those of some random
developer on the web - these are some of the same arguments used by
Google, Yahoo, Amazon, etc, etc when they develop their own public
sites. To call my arguments in favor of using libraries stupid is to
also call all these other sites stupid for making similar decisions.
And these are sites making millions and billions of dollars on what
you consider to be "bad design decisions"!

And in spite of all this, you claim to have a better way... the
"right" way. Yet you won't post up your code to prove to everyone that
you have truly found something superior. You know what they say,
"extraordinary claims require extraordinary evidence". If you are to
claim that you have found a better way than all of these sites that
employee extremely intelligent people and have billions of dollars to
throw at development, then you need to either prove it to the world or
continue looking like an arrogant idiot. IMO.

Matt Kruse

[Brian Adkins]

On Oct 31, 10:34 pm, Matt Kruse <[e-mail]:

On Oct 31, 5:34 pm, John Resig <[e-mail]:

Probably the same one that Google, Amazon, IBM, AOL, etc. are from.

I think this is a point that needs to be made again -

If your arguments are that:

Matt, in my newsreader it appears you've quoted John, but you're
addressing David with your comments, right? Just wanted to clarify.

[Matt Kruse]

On Oct 31, 10:11 pm, Brian Adkins <[e-mail]:

Matt, in my newsreader it appears you've quoted John, but you're
addressing David with your comments, right? Just wanted to clarify.

Yeah, sorry, John quoted David and if there was an attribution it
didn't come through in my Google Groups reply. My comments were
directed towards David, not John.

Matt Kruse

[Peter Michaux]

On Oct 31, 3:34 pm, John Resig <[e-mail]:

>
To start with, jQuery only supports the following browsers:
- IE 6+
- Firefox 2+
- Opera 9
- Safari 2+

Anything outside that jurisdiction is not guaranteed to work.

But considering that that selection is something like 99% of all browsers

Web browser statistics have been claimed to be useless many times on
this newsgroup. I didn't claim that but I need to recognize that claim
before the following.

The w3schools site posts their statistics

http://www.w3schools.com/browsers/browsers_stats.asp

The browser subset you stated above is a maximum of 94.2%.

There was no automatic upgrade from FF1.5 to FF2.0 and all FF releases
have been lumped into the 35.4% for FF. Conservatively I would guess
that 10% of FF users are still on versions before FF2. I still have
friends using IE5 on Mac so I think many people using FF may not even
know that FF2 has been released. Think about parents who's children
installed FF for them a while ago. So now we are down to 84.2% in your
browser subset.

Safari and Opera versions are similarly lumped so I'll knock off 0.75%
there. We are down to 83.45%.

I'm going to assume that w3schools stats are based on substrings of
navigator.userAgent. We also need to subtract all the browsers that
have navigator.userAgent strings that the w3schools site is
misinterpreting to fall into your subset. For example, I'm told that
some cell phones claim to be in the IE6+ group but have very old
JavaScript capabilities. I don't have much confidence here but I'll
knock off 3.45% which leaves us at an even 80%. This is all very ball
park but even 85% is not close to 99%, in my opinion.

The w3schools site is a site for people interested in technology. On a
site about tomato soup, charity, travel or banking I would imagine the
percentage is substantially lower. It could be as low as 70%. That is
way too low and even if it is 85% that is still too low to call a
success. It is low enough to declare it a complete failure to write a
script applicable to the general web. jQuery might be fine for an
application behind a login but not for the general web.

Even if these statistics are way off, do you still think that your
browser subset represents 99% of all browsers? I don't.

Considering jQuery uses navigator.userAgent sniffing, there will
likely be problems in what now looks like a reasonably sized chunk of
the browsers out there. So what happens with a jQuery site that is
used outside the supported browser subset? A real problem occurs when
a script starts down an execution path and part way along the script
fails. If DOM manipulations are involved the page could be left in
some mangled state that is useless. This is more likely to happen then
not as the bulk of unsupported browsers will be just a little older
and only a little less capable than the supported browsers. Does
jQuery have features to help avoid this important problem?

(and considering that the selection of supported browsers is "good
enough" for Google, Amazon, NBC, IBM, Oracle, etc. etc.) I think it's
safe to say that we've made a good choice.

I don't think that is a strong argument at the very least from a
professional pride point of view. I use and like many pages from
google but their scripts throw many errors and screw up all the time
in FF2. If just dollars matter then it is a fine argument in some
peoples judgment but a colossal loss to others that would made enough
money to survive had they used no JavaScript at all. Regardless of
dollars, we are mainly having a discussion about library code quality
here.

Peter

[Jeff North]

On Wed, 31 Oct 2007 22:34:36 -0000, in comp.lang.javascript John Resig
<je*****@gmail.com>
<11**********************@e34g2000pro.googlegroups .comwrote:

[snip]

>|
| So besides .attr() needing a rewrite (I fully admit that) - I see
| absolutely no valid criticism of the library - and if anything, a
| gross misunderstanding of common cross browser issues and of how test
| driven development works.
|
| Let me know when you release your library, as I'd love to take a look
| and see what I've been missing.

John, I hope your not holding your breath for this event :-)
-- -------------------------------------------------------------
jn******@yourpantsyahoo.com.au : Remove your pants to reply
-- -------------------------------------------------------------

[Jeff North]

On Wed, 31 Oct 2007 23:06:39 -0700, in comp.lang.javascript David Mark
<dm***********@gmail.com>
<11**********************@y42g2000hsy.googlegroups .comwrote:

>| On Oct 31, 6:34 pm, John Resig <[e-mail]:

[snip]

>| Let me know when you release your library, as I'd love to take a look
| and see what I've been missing.
|
| I bet you would like to crib from me. And who said I was releasing a
| public general-purpose JavaScript library? Seems to me I said just
| recently that I would never do that (much to the chagrin of several
| people in this thread.) Apparently you don't read before you post.

LOL of course you wouldn't. You couldn't stand the criticism.
Why would anyone want to steal your code. If it is a superior product
than what is currently available people would start using your library
and forget about the others, right?
-- -------------------------------------------------------------
jn******@yourpantsyahoo.com.au : Remove your pants to reply
-- -------------------------------------------------------------

[David Mark]

On Nov 1, 7:05 am, Jeff North <[e-mail]:

On Wed, 31 Oct 2007 23:06:39 -0700, in comp.lang.javascript David Mark
<[e-mail]>

<[e-mail] .comwrote:

| On Oct 31, 6:34 pm, John Resig <[e-mail]:

[snip]

| Let me know when you release your library, as I'd love to take a look
| and see what I've been missing.
|
| I bet you would like to crib from me. And who said I was releasing a
| public general-purpose JavaScript library? Seems to me I said just
| recently that I would never do that (much to the chagrin of several
| people in this thread.) Apparently you don't read before you post.

LOL of course you wouldn't. You couldn't stand the criticism.

What does that mean? Just because I have no interest in peddling a
free library does not mean that I don't post code examples. I
absolutely welcome any (coherent) criticism.

Why would anyone want to steal your code. If it is a superior product

Why would anybody want to steal anything? So as to get it for free.
Somebody suggested I should sell JavaScript code without posting it.
That would be an interesting trick. As soon as you send it to the
wrong person to "try out", it is public domain.

than what is currently available people would start using your library
and forget about the others, right?

Some people would. The point is that I am not in the business of
giving away libraries for beer money donations. What I will do for
anybody who asks is perform a jQuery (or any library) abatement.
Though I prefer to build applications, I often find myself cleaning up
after clueless JavaScript/HTML/CSS "designers." Most of them use
Prototype or .NET. Occasionally Dojo pops up. jQuery, not so much.
Regardless, it isn't cheap labor, so in a way, I am grateful to the
John Resig's of the world.

[Matt Kruse]

On Nov 1, 5:21 pm, David Mark <[e-mail]:

Actually it does. When you create an input element, it starts off as
a text element.

Only if you don't create it as one to begin with.

You have to change its type to create a radio
button.

Which you can do only once.

If you don't do it exactly right, you will get a non-working
radio button.

It's not as tricky as you make it sound.

You must be a lousy "Googler." The first hit that comes up has most
of the answers you seek.

Negative.

I can replace the outerHTML of the element, obviously. But that just
creates a new element. It doesn't change the type of the existing

Semantics aside, it does exactly what you need.

It's not semantics. It creates a new object, rather than modifying an
existing one. Further, the outerHTML of an element in IE is not a fair
representation of how it was constructed in the source.

Matt Kruse

[Matt Kruse]

On Dec 4, 10:17 am, David Mark <[e-mail]:

You have no point. You are just repeating the same non-argument about
outerHTML creating a new element. Of course it creates a new element
and you have to deal with that fact in your code.

Any references to the original object will be lost.
Which means you haven't changed the type of an input, you've just
created a new one to replace it.
That's one way to accomplish a goal, but it's not an answer to
modifying an existing input.

It would seem you just want to argue with me.

What are you, my wife? ;)

Matt Kruse

[David Mark]

On Nov 1, 9:05 pm, Matt Kruse <[e-mail]:

On Nov 1, 5:21 pm, David Mark <[e-mail]:

Actually it does. When you create an input element, it starts off as
a text element.

Only if you don't create it as one to begin with.

What does that mean? MS extensions aside, you can't magically set the
type attribute on creation.

>

You have to change its type to create a radio
button.

Which you can do only once.

See the previous post.

>

If you don't do it exactly right, you will get a non-working
radio button.

It's not as tricky as you make it sound.

What is tricky about doing it right? In a nutshell, set the name
property first. Of course, the name property won't populate the
elements collection of the parent form (assuming there is one),
without a workaround (see the previous post.)

>

You must be a lousy "Googler." The first hit that comes up has most
of the answers you seek.

Negative.

Then you either can't read or are just trying to string out this
ridiculous "argument."

>

I can replace the outerHTML of the element, obviously. But that just
creates a new element. It doesn't change the type of the existing

Semantics aside, it does exactly what you need.

It's not semantics. It creates a new object, rather than modifying an
existing one. Further, the outerHTML of an element in IE is not a fair
representation of how it was constructed in the source.

It is semantics. See the previous post. And who said you should use
the outerHTML property to construct the replacement markup? You don't
need to read it, just loop through the specified attributes (assuming
you have a competent getAttribute wrapper) and build the string
yourself.

[Rozzy]

On Dec 4, 11:34 am, David Mark <[e-mail]:

On Nov 1, 9:05 pm, Matt Kruse <[e-mail]:

On Nov 1, 5:21 pm, David Mark <[e-mail]:

Actually it does. When you create an input element, it starts off as
a text element.

Only if you don't create it as one to begin with.

What does that mean? MS extensions aside, you can't magically set the
type attribute on creation.

You have to change its type to create a radio
button.

Which you can do only once.

See the previous post.

If you don't do it exactly right, you will get a non-working
radio button.

It's not as tricky as you make it sound.

What is tricky about doing it right? In a nutshell, set the name
property first. Of course, the name property won't populate the
elements collection of the parent form (assuming there is one),
without a workaround (see the previous post.)

You must be a lousy "Googler." The first hit that comes up has most
of the answers you seek.

Negative.

Then you either can't read or are just trying to string out this
ridiculous "argument."

I can replace the outerHTML of the element, obviously. But that just
creates a new element. It doesn't change the type of the existing
Semantics aside, it does exactly what you need.

It's not semantics. It creates a new object, rather than modifying an
existing one. Further, the outerHTML of an element in IE is not a fair
representation of how it was constructed in the source.

It is semantics. See the previous post. And who said you should use
the outerHTML property to construct the replacement markup? You don't
need to read it, just loop through the specified attributes (assuming
you have a competent getAttribute wrapper) and build the string
yourself.

Don't worry David, I got your back! I'll put these jerks in their
place

Yo guys, I don't care if it works in 99% of all browsers, I don't care
how much time or money I waste, at least I won't have to debug them
when all the browsers suddenly decide to drop their backwards-
capability and 99% of all sites crash, except mine and David's! Whose
gonna get all the hits then?? And I don't care if 90% of developers,
including "experts" like John Resig and huge corporations like Google
and IBM (who are they anyway?) use them, they're all wrong, me and
David got this javascript thing down, we get it, we know it. I mean
just because you practically invented the language doesn't mean you
know it. James Naismith was good a basketball was he?

[Rozzy]

On Dec 4, 11:34 am, David Mark <[e-mail]:

On Nov 1, 9:05 pm, Matt Kruse <[e-mail]:

On Nov 1, 5:21 pm, David Mark <[e-mail]:

Actually it does. When you create an input element, it starts off as
a text element.

Only if you don't create it as one to begin with.

What does that mean? MS extensions aside, you can't magically set the
type attribute on creation.

You have to change its type to create a radio
button.

Which you can do only once.

See the previous post.

If you don't do it exactly right, you will get a non-working
radio button.

It's not as tricky as you make it sound.

What is tricky about doing it right? In a nutshell, set the name
property first. Of course, the name property won't populate the
elements collection of the parent form (assuming there is one),
without a workaround (see the previous post.)

You must be a lousy "Googler." The first hit that comes up has most
of the answers you seek.

Negative.

Then you either can't read or are just trying to string out this
ridiculous "argument."

I can replace the outerHTML of the element, obviously. But that just
creates a new element. It doesn't change the type of the existing
Semantics aside, it does exactly what you need.

It's not semantics. It creates a new object, rather than modifying an
existing one. Further, the outerHTML of an element in IE is not a fair
representation of how it was constructed in the source.

It is semantics. See the previous post. And who said you should use
the outerHTML property to construct the replacement markup? You don't
need to read it, just loop through the specified attributes (assuming
you have a competent getAttribute wrapper) and build the string
yourself.

Don't worry David, I got your back! I'll put these jerks in their
place

Yo guys, I don't care if it works in 99% of all browsers, I don't care
how much time or money I waste, at least I won't have to debug them
when all the browsers suddenly decide to drop their backwards-
capability and 99% of all sites crash, except mine and David's! Whose
gonna get all the hits then?? And I don't care if 90% of developers,
including "experts" like John Resig and huge corporations like Google
and IBM (who are they anyway?) use them, they're all wrong, me and
David got this javascript thing down, we get it, we know it. I mean
just because you practically invented the language doesn't mean you
know it. James Naismith wasn't a good basketball player was he?

[Peter Michaux]

On Dec 4, 11:46 am, Rozzy <[e-mail]:

On Dec 4, 11:34 am, David Mark <[e-mail]:

On Nov 1, 9:05 pm, Matt Kruse <[e-mail]:

On Nov 1, 5:21 pm, David Mark <[e-mail]:

Actually it does. When you create an input element, it starts off as
a text element.

Only if you don't create it as one to begin with.

What does that mean? MS extensions aside, you can't magically set the
type attribute on creation.

You have to change its type to create a radio
button.

Which you can do only once.

See the previous post.

If you don't do it exactly right, you will get a non-working
radio button.

It's not as tricky as you make it sound.

What is tricky about doing it right? In a nutshell, set the name
property first. Of course, the name property won't populate the
elements collection of the parent form (assuming there is one),
without a workaround (see the previous post.)

You must be a lousy "Googler." The first hit that comes up has most
of the answers you seek.

Negative.

Then you either can't read or are just trying to string out this
ridiculous "argument."

I can replace the outerHTML of the element, obviously. But that just
creates a new element. It doesn't change the type of the existing
Semantics aside, it does exactly what you need.

It's not semantics. It creates a new object, rather than modifying an
existing one. Further, the outerHTML of an element in IE is not a fair
representation of how it was constructed in the source.

It is semantics. See the previous post. And who said you should use
the outerHTML property to construct the replacement markup? You don't
need to read it, just loop through the specified attributes (assuming
you have a competent getAttribute wrapper) and build the string
yourself.

Don't worry David, I got your back! I'll put these jerks in their
place

Yo guys, I don't care if it works in 99% of all browsers, I don't care
how much time or money I waste, at least I won't have to debug them
when all the browsers suddenly decide to drop their backwards-
capability and 99% of all sites crash, except mine and David's! Whose
gonna get all the hits then?? And I don't care if 90% of developers,
including "experts" like John Resig and huge corporations like Google
and IBM (who are they anyway?) use them, they're all wrong, me and
David got this javascript thing down, we get it, we know it. I mean
just because you practically invented the language doesn't mean you
know it. James Naismith wasn't a good basketball player was he?

Some people strive for excellence and constantly improvement. Others
are happy with mediocrity because it is good enough for everyone else.

Peter

[Peter Michaux]

On Dec 4, 12:32 pm, Rozzy <[e-mail]:

On Dec 4, 3:16 pm, Peter Michaux <[e-mail]:

Some people strive for excellence and constantly improvement. Others
are happy with mediocrity because it is good enough for everyone else.

Peter

Holy shit are you defending him,

It was a general comment.

Peter

[Randy Webb]

Peter Michaux said the following on 12/4/2007 3:16 PM:

<snip>

Some people strive for excellence and constantly improvement. Others
are happy with mediocrity because it is good enough for everyone else.

I think you failed to catch the sarcasm and irony in it.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Peter Michaux]

On Dec 4, 12:41 pm, Peter Michaux <[e-mail]:

On Dec 4, 12:32 pm, Rozzy <[e-mail]:

On Dec 4, 3:16 pm, Peter Michaux <[e-mail]:

Some people strive for excellence and constantly improvement. Others
are happy with mediocrity because it is good enough for everyone else.

Peter

Holy shit are you defending him,

It was a general comment.

It was not directed at Matt.

Peter

[David Mark]

On Dec 4, 2:46 pm, Rozzy <[e-mail]:

On Dec 4, 11:34 am, David Mark <[e-mail]:

On Nov 1, 9:05 pm, Matt Kruse <[e-mail]:

On Nov 1, 5:21 pm, David Mark <[e-mail]:

Actually it does. When you create an input element, it starts off as
a text element.

Only if you don't create it as one to begin with.

What does that mean? MS extensions aside, you can't magically set the
type attribute on creation.

You have to change its type to create a radio
button.

Which you can do only once.

See the previous post.

If you don't do it exactly right, you will get a non-working
radio button.

It's not as tricky as you make it sound.

What is tricky about doing it right? In a nutshell, set the name
property first. Of course, the name property won't populate the
elements collection of the parent form (assuming there is one),
without a workaround (see the previous post.)

You must be a lousy "Googler." The first hit that comes up has most
of the answers you seek.

Negative.

Then you either can't read or are just trying to string out this
ridiculous "argument."

I can replace the outerHTML of the element, obviously. But that just
creates a new element. It doesn't change the type of the existing
Semantics aside, it does exactly what you need.

It's not semantics. It creates a new object, rather than modifying an
existing one. Further, the outerHTML of an element in IE is not a fair
representation of how it was constructed in the source.

It is semantics. See the previous post. And who said you should use
the outerHTML property to construct the replacement markup? You don't
need to read it, just loop through the specified attributes (assuming
you have a competent getAttribute wrapper) and build the string
yourself.

Don't worry David, I got your back! I'll put these jerks in their
place

Put who where? From the looks of it, most people posting to and
reading this thread agree with me.

>
Yo guys, I don't care if it works in 99% of all browsers, I don't care

What works in 99% of all browsers?

how much time or money I waste, at least I won't have to debug them
when all the browsers suddenly decide to drop their backwards-
capability and 99% of all sites crash, except mine and David's! Whose

Oh I get it now. You are an idiot. And from the "JavaScript Forum"
no less. I recommend you go back.

gonna get all the hits then?? And I don't care if 90% of developers,
including "experts" like John Resig and huge corporations like Google
and IBM (who are they anyway?) use them, they're all wrong, me and

Google and John Resig are JavaScript experts?! Really?

David got this javascript thing down, we get it, we know it. I mean
just because you practically invented the language doesn't mean you

Who practically invented the language? John Resig? You are out of
your tiny little mind.

[David Mark]

On Dec 4, 4:19 pm, Randy Webb <[e-mail]:

Peter Michaux said the following on 12/4/2007 3:16 PM:

<snip>

Some people strive for excellence and constantly improvement. Others
are happy with mediocrity because it is good enough for everyone else.

I think you failed to catch the sarcasm and irony in it.

It would be hard to miss the sarcasm. The irony is that most of the
jQuery muppets think that their library works with "99% of all
browsers" and that it must be good because, after all, Google uses it.
(!)

Speaking of irony, a trip to the jQuery developer group reveals that
some of the issues raised here were debated (ad nauseum) and finally
pushed through. Others were ignored or shouted down with ludicrous
comments like "if it ain't broke, don't fix it." IIRC, that was in
response to the text node event target issue, which was described as a
"Safari bug" (it is neither.) Few over there seem to grasp that their
code will break constantly as browsers fix bugs and introduce new
ones. Why anybody would use code written by such people is beyond
me. Why they would bother trying to defend it here is an even greater
mystery.

BTW, where is the latest HikkScript test page? I was working on
something recently that used Ajax and innerHTML to update elements
periodically and it needed to have inline script execute (which seemed
like a silly idea to me.) I didn't have time to wade through the
hundreds of recent posts on the subject, so I recreated what I
remembered as the best strategy. I'd like to compare it to the
definitive version that has been tested on all of the weird Mac
browsers, etc.

[David Mark]

On Dec 5, 8:17 am, Rozzy <[e-mail]:

[snip]

>
btw, Randy Webb, nice job backing down from your response, "it was a
general comment", and then coming back later with your attempted

Idiot. Peter said that and I doubt he meant it as a vote of
confidence for your nonsensical ramblings.

[beegee]

On Oct 30, 1:46 pm, Matt Kruse <[e-mail]:

What would be your recommendation? I see some possibilities:

1. Use a freely-available library that isn't perfect, but has lots of
examples, speeds up development, and doesn't appear to break in any
cases
2. Write everything from scratch, which might be lower quality than
the libraries and take too long
3. Hire a competent developer to write everything from scratch, which
again might take too long and may not be an option financially
4. Make a post to comp.lang.javascript asking which library to use and
be told that they all suck, and awesome library code exists but you
can't have it.
5. ???

In a real case like this, how would you recommend that people proceed?

Matt Kruse

I have looked at all the libraries that have been mentioned here plus
mootools and scriptaculous. I use YUI now because a.) I know exactly
what it will give me (trees, menus, dialogs, and a pretty nice AJAX
wrapper and most importantly, it will not obfuscate the javascript
language) b.) people on this group haven't totally dissed it.

I am unable to see what the other libraries will give me. Could you
list (for me and the OP) what specific benefits jQuery, for example
will give me. I'm not angling here. If there is a great benefit I am
missing then I will switch over and damn the obfuscation and
"terrible" code.

Bob