Javascript Library
shapper
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
> 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
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...
Peter
Brian Adkins
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
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
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 28, 7:48 pm, shapper <mdmo...@gmail.com> 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?
>
> 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
> 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, 11:25 am, David Mark <dmark.cins...@gmail.com> wrote:
>
> > 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
> 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
David Mark
> On Oct 29, 12:42 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > Run it through JSLint.
>
> Which is about as useful as validating HTML. Great for academic
Invalid markup is certainly not useful.
> purposes, perhaps it will catch a few errors, etc.
In jQuery's case, virtually every line will have a problem (or
multiple problems.) That indicates a slap-dash effort.
> But in the end it doesn't matter if code passes analytics, just if it
It matters for the people who have to maintain it. And since you are
relying on these people, it matters to you.
> accomplishes the goal or not. My goal never includes "pass
> validation". Validation is merely a tool to reach my goal, when
> needed.
I don't know what that means. If you write invalid markup and messy
script, you invite problems.
>
> > 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.
It is never 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.
Which you could do without parsing the userAgent string.
> It's not ideal, but it is a strategy. The amount of browser sniffing
> in jQuery is minimal.
>
Hardly. It is woven into many important low-level functions. Here is
a particularly stupid snippet from the get/setAttribute wrapper called
attr:
} else if ( jQuery.browser.msie && name == "style" )
return jQuery.attr( elem.style, "cssText", value );
Do you have any idea how many agents jQuery will identify as IE? Do
you have any idea how trivial it is to properly feature detect IE's
broken get/setAttribute functionality?
Forget that for the moment, why is this function passing a style
object to itself? Its first parameter is supposed to be an element.
Later in the same function, it becomes apparent (that the author is
out of his mind.)
// IE elem.getAttribute passes even for style
else if ( elem.tagName ) {
...
// elem is actually elem.style ... set the style
} else {
There couldn't be a more critical function in the entire library and
it is pure gibberish. Even the comments are senseless. There are
several additional sniffs in this same function.
if ( jQuery.browser.msie && /href|src/.test(name) && !
jQuery.isXMLDoc(elem) )
return elem.getAttribute( name, 2 );
Just what sort of XML document runs script in IE? Certainly not an
XHTML document. Realize that this absurd line of code is evaluated
every time jQuery looks at an element's attribute.
Then there is this gem:
// Certain attributes only work when accessed via the old DOM 0 way
if ( fix[name] ) {
if ( value != undefined ) elem[fix[name]] = value;
return elem[fix[name]];
This demonstrates a stunning lack of understanding of attributes (and
IE's problems with them.) Where's the sniff (or feature detect) for
IE? This IE-specific workaround runs on everything.
Still in the same function:
else if ( value == undefined && jQuery.browser.msie &&
jQuery.nodeName(elem, "form") && (name == "action" || name ==
"method") )
return elem.getAttributeNode(name).nodeValue;
No comment for this magic spell, so there is no telling what it is
trying to do. One thing is certain. This code will run on lots of
non-IE agents.
It gets worse.
if ( value != undefined ) {
if ( name == "type" && jQuery.nodeName(elem,"input") &&
elem.parentNode )
throw "type property can't be changed";
elem.setAttribute( name, value );
}
Another example of confusing attributes with properties. This is also
an IE-specific workaround with no sniff (or feature detect.)
And just when you think you have seen every conceivable miscue (all in
a single function mind you.)
if ( name == "opacity" && jQuery.browser.msie ) {
if ( value != undefined ) {
// IE has trouble with opacity if it does not have layout
// Force it by setting the zoom level
elem.zoom = 1;
What in God's name do opacity (and other styles) have to do with
attributes?
That's enough of that function. Keep in mind that the code therein is
called constantly by jQuery. Unfortunately for those who rely on
jQuery, it is error-prone, confused, inefficient and convoluted. The
design (and documentation) is of such poor quality that it is an
assault on the senses of anyone unfortunate enough to glance at it.
And speaking of opacity. In the curCSS function:
if (prop == "opacity" && jQuery.browser.msie) {
ret = jQuery.attr(elem.style, "opacity");
return ret == "" ? "1" : ret;
}
So any agent that identifies as IE and will be re-routed to the attr
function, which has nothing to do with style, but does contain more
sniffing and some IE-specific DirectX twiddling, which will have no
(positive) effect on non-IE agents.
It would seem that querying style rules would be almost as critical to
querying attributes in a library like jQuery. Yet, in this same
function you find this gem:
// A helper method for determining if an element's values are broken
function color(a){
if ( !jQuery.browser.safari )
return false;
var ret = document.defaultView.getComputedStyle(a,null);
return !ret || ret.getPropertyValue("color") == "";
}
This is the author's idea of a feature detect for getComputedStyle.
Why Safari-like browsers are excluded is a mystery. After that
inauspicious start, it blunders into the defaultView, getComputedStyle
and getPropertyValue properties with the impunity of somebody who
hasn't got a clue as to what they are doing.
It goes on and on. From the clean function:
if ( jQuery.browser.msie ) { // String was a <table>, *may* have
spurious <tbody>
if ( !s.indexOf("<table") && s.indexOf("<tbody") < 0 )
tb = div.firstChild && div.firstChild.childNodes;
div *may* have a firstChild property.
>From the same function:
// IE can't serialize <link> and <script> tags normally
jQuery.browser.msie && [1, "div<div>", "</div>"]
You have to keep in mind while reading this stuff that
jQuery.browser.msie is meaningless on the Web. It isn't of much use
on an Intranet either, unless you use the same version and
configuration of IE forever.
>From merge:
// Also, we need to make sure that the correct elements are being
returned
// (IE returns comment nodes in a '*' query)
if ( jQuery.browser.msie ) {
for ( var i = 0; second[i]; i++ )
if ( second[i].nodeType != 8 )
first.push(second[i]);
} else
Same problem different function. What if some agent that doesn't
identify as IE has the same problem? Also note how hard it is to
follow with all of the missing brackets.
More madness:
var styleFloat = jQuery.browser.msie ? "styleFloat" : "cssFloat";
Obviously you should just check (or set) them both. What happens if
IE8 switches gears on this? And what of an IE-spoofing agent that
doesn't use "styleFloat?"
// Check to see if the W3C box model is being used
boxModel: !jQuery.browser.msie || document.compatMode == "CSS1Compat",
That could have far-reaching implications. A quick search found it in
an attempt to measure the viewport:
return this[0] == window ?
jQuery.browser.safari && self["inner" + name] || jQuery.boxModel &&
Math.max(document.documentElement["client" + name],
document.body["client" + name]) ||
document.body["client" + name] :
this[0] == document ?
Math.max( document.body["scroll" + name], document.body["offset" +
name] ) :
h == undefined ?( this.length ? jQuery.css( this[0], n ) : null ) :
this.css( n, h.constructor == String ? h : h + "px" );
I characterized this as a "million monkey" project earlier and I want
to take a moment to apologize to monkeys everywhere. I think even a
single monkey could write a better solution to this very common
problem. Certainly there are many better solutions floating around on
the Internet.
And boxmodel can also be observed in the positioning code:
// IE adds the HTML element's border, by default it is medium which is
2px
// IE 6 and IE 7 quirks mode the border width is overwritable by the
following css html { border: 0; }
// IE 7 standards mode, the border is always 2px
if ( msie ) {
var border = jQuery("html").css("borderWidth");
border = (border == "medium" || jQuery.boxModel &&
parseInt(version) >= 7) && 2 || border;
add( -border, -border );
}
There are so many misconceptions here it is hard to know where to
begin. Suffice to say that the clientLeft/Top properties hold the
needed information in IE.
In the same function:
// Mozilla and Safari > 2 does not include the border on offset
parents
// However Mozilla adds the border for table cells
if ( mozilla && /^t[d|h]$/i.test(parent.tagName) || !safari2 )
border( offsetParent );
Apparently, in the jQuery universe there is only Opera, Mozilla,
Safari and IE. IE never gets here. Opera (and Safari <= 2 if you
believe the comments) adds borders when it shouldn't. So this logic
excludes everything the author has ever heard of that isn't Opera.
Speaking of Mozilla. Does this look like a good indication of Mozilla-
based browsers?
mozilla: /mozilla/.test(userAgent) && !/(compatible|
webkit)/.test(userAgent)
Why not call that the everything-under-the-sun property?
Getting back to border issue, in the mozilla-and-newer-Safari-only
(and oddly named) border function:
add( jQuery.css(elem, "borderLeftWidth"), jQuery.css(elem,
"borderTopWidth") );
What an outrage. The author apparently never heard of clientLeft/Top.
Backing up to where boxModel was first spotted, this is deja vu:
styleFloat: jQuery.browser.msie ? "styleFloat" : "cssFloat",
Yes, this logic is repeated just three lines below the first instance.
Moving on. In the ready function:
if ( jQuery.browser.mozilla || jQuery.browser.opera )
document.removeEventListener( "DOMContentLoaded", jQuery.ready,
false );
So if it is virtually any agent, assume there is a document object (a
fair assumption) and assume that it has a removeEventListener method
(an outrageous assumption.) Why the event listener needs to be
removed at all is another interesting question. The comments
mentioned memory leaks.
Here is the flip-side of this in bindReady:
// If Mozilla is used
if ( jQuery.browser.mozilla || jQuery.browser.opera )
// Use the handy event callback
document.addEventListener( "DOMContentLoaded", jQuery.ready,
false );
So two of the four browsers that the author knows of are known to
support DOMContentLoaded. Of course, it wouldn't hurt to add this
listener for everything. Come to think of it, he did (unknowingly)
add it for virtually everything.
You've got to love the comments. "Use the handy event callback" may
be the least informative one yet. Here's another interesting one from
makeArray:
// Need to use typeof to fight Safari childNodes crashes
if ( typeof a != "array" )
for ( var i = 0, al = a.length; i < al; i++ )
r.push( a[i] );
else
r = a.slice( 0 );
And why would you pass an array to a "makeArray" function anyway?
This reminds me of the function test code, which was blistered in
another recent "jQuery is a joke" thread.
Enough is enough. If you use jQuery after reading this, you are
deserve everything you get.
> > 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.
Asked and answered? I still want to know what reak-world you are
from.
>
> > 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.
>
Ten years, according to a previous post, and you haven't learned a
thing. And who cares how it stacks up to "average developers?" 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 didn't think so either.
> > > 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.
Really? Define packed. Minified it is roughly 50K. GZIP doesn't
enter into it (unless you can't comprehend why it is silly to compare
file sizes after compression.) How small would a 20K library be after
compression? Regardless, you shouldn't manually compress JavaScript
files.
>
> > > > 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.
Sure did.
> Surely you could provide some examples from your recent investigation?
Sure could.
>
> > > 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?
What you consider yourself to be is hardly relevant. If you use and
recommend jQuery, then you are worse than an amateur. You are doing a
disservice to anyone who is unfortunate enough to use your creations
or listen to your advice.
>
> > > 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
You don't get JavaScript, browser scripting, etc.
> might as well just say "You're stupid!" and stick your tongue out.
>
If you use or advocate jQuery after today, you are stupid.
> Further, have you considered that perhaps it is you who just doesn't
> get it?
I've looked at that. I don't think so.
>
> > > 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.
A few flaws?!
> Which means it was probably developed by humans. If your goal is
> perfection, you'll never find it.
>
Finding a library was never my goal. Regardless, there is a big
difference between competent and perfect.
> > > 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
Oversimplification.
>
> #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
>
You've got lots of bugs and future maintenance issues. Perhaps you
didn't know about a lot of them before today. And if you can't write
relatively bug-free code without jQuery (God knows you can't with it),
then perhaps you should consider another line of work.
> Consider the effects of introducing jquery to a large development
> team:
[snip considerations]
>
> Now, how are you arguing that using jquery is not a huge benefit?
>
I didn't read the considerations. I am tired of hearing about
jQuery. It sucks. Case closed.
> You would recommend that we stop using it and start coding from
> scratch?
Why do library-advocates invariably see just those two choices? Do
whatever you want.
>
> > > 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?
You don't have to be psychic to see what lies ahead for your team.
> Can you quote the experience of anyone else who has used it and found
> it to be a maintenance problem?
I really don't talk to jQuery users. They tend to babble on and on
about nothing.
> Or hell, can you quote anyone who has used it and found it to be a bad
> decision for any reason?
I don't think I need to quote anyone at this point.
> Do you have any real-world experience with it?
You are repeating yourself.
> If not, how do you possibly feel justified in criticizing it?
See above.
Jeff North
<dmark....@gmail.com>
<1193694168.9...@22g2000hsm.googlegroups.com> wrote:
Thank you for the insightful review of jQuery.
Could you please tell me where I can get a copy of your js library?
-- -------------------------------------------------------------
jnor...@yourpantsyahoo.com.au : Remove your pants to reply
-- -------------------------------------------------------------
Evertjan.
> 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)
Douglas Crockford
> On Oct 28, 5:48 pm, shapper <mdmo...@gmail.com> wrote:
>> 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...
I would urge many of the regulars to reconsider their positions. Some of the
Ajax libraries have gotten quite good lately. They eliminate most of the browser
inconsistencies, relieving one of the major pain points in browser programming.
And they shift the level of programming up a level, so that you can focus more
on your application, and less on the browser's many limitations.
The biggest problems with the libraries are that there are too many of them, and
that there are some problems with the browser architecture (particularly with
security) that are unsolvable, given the current state of standards and browser
implementations.
It looks like the too many problem will solve itself with a shake out. I am
predicting that the winners of the shake out will be Dojo and YUI because they
are the best supported and documented.
Good use of an Ajax library can improve your productivity and improve the
portability of your application. The library makers scramble when every new
browser ships to find the workarounds for the new bugs and gotchas. They are
much better at that game than you want to be.
Matt Kruse
> It looks like the too many problem will solve itself with a shake out. I am
> predicting that the winners of the shake out will be Dojo and YUI because they
> are the best supported and documented.
They are both huge monster libraries, though, and that is not a
selling point.
I've recently seen Dojo killed from several projects because it was
too huge, confusing, and slow.
Matt Kruse
David Mark
> On Mon, 29 Oct 2007 14:42:48 -0700, in comp.lang.javascript David Mark
>
> <1193694168.952251.143...@22g2000hsm.googlegroups.com> wrote:
>
> 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.
David Mark
> Peter Michaux wrote:
> > On Oct 28, 5:48 pm, shapper <mdmo...@gmail.com> wrote:
> >> 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...
Certainly not jQuery or Dojo. I haven't looked into YUI very deeply,
but then YUI is just a big container for lots of little modules, so
the "should I use YUI" question is too vague. Should one use the YUI
tree widget? I would say no. Should one use the YUI events module?
I would say maybe. If it is stand-alone, efficient and employs no
browser sniffing, then perhaps.
>
> I would urge many of the regulars to reconsider their positions. Some of the
> Ajax libraries have gotten quite good lately. They eliminate most of the browser
It seems to me that Ajax would be an optional module for a general
purpose JavaScript library. That's one of the many problems with
jQuery, Prototype and the like.
> inconsistencies, relieving one of the major pain points in browser programming.
But if they do so with browser sniffing, then you mortgage your future
by relying on them.
> And they shift the level of programming up a level, so that you can focus more
> on your application, and less on the browser's many limitations.
>
But at what cost? Many of the popular libraries have their own
limitations. Some support only a handful of modern browsers. Most
rely on userAgent parsing to work around browser limitations. Is it
useful to invest time learning the limitations of a library, only to
have those limitations change every time a new browser version
appears?
> The biggest problems with the libraries are that there are too many of them, and
And all of them try to do everything. None masters all, so developers
end up using multiple libraries, which leads to triple-digit page
weights, namespace collisions, etc.
> that there are some problems with the browser architecture (particularly with
> security) that are unsolvable, given the current state of standards and browser
> implementations.
I assume you are talking about Ajax issues.
>
> It looks like the too many problem will solve itself with a shake out. I am
> predicting that the winners of the shake out will be Dojo and YUI because they
> are the best supported and documented.
I understand why you endorse YUI, but have you looked at the Dojo
source?
You obviously know ECMAScript/JavaScript very well. I assume you are
also well-versed in DOM variations and page optimization issues.
Would you recommend using the heavy YUI widgets on a site that isn't
Yahoo!?
>
> Good use of an Ajax library can improve your productivity and improve the
There needs to be a differentiation between "Ajax library" and
"JavaScript library." Too many developers think JavaScript
enhancements and Ajax are the same thing.
> portability of your application. The library makers scramble when every new
Portability to what? Libraries like Dojo, jQuery, ProtoType, etc.
aren't particularly backwards compatible, nor do they support a
significant number of current agents. And due to their reliance on
browser sniffing, they are not future-proof.
> browser ships to find the workarounds for the new bugs and gotchas. They are
> much better at that game than you want to be.
They are pretty weak at it from what I have seen. Who wants to rely
on third-parties to reevaluate their delusional inferences every time
a new browser is released?
Matt Kruse
> > Could you please tell me where I can get a copy of your js library?
> You cannot.
Why not?
> Though I have recently considered posting the basic
> essentials as a foundation for those who wish to write their own
> libraries.
I would encourage you to do so. Please provide full documentation,
test suites, examples, and support as well.
Matt Kruse
David Mark
> On Oct 30, 9:50 am, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > 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.
>
> > Though I have recently considered posting the basic
> > essentials as a foundation for those who wish to write their own
> > libraries.
>
> I would encourage you to do so. Please provide full documentation,
> test suites, examples, and support as well.
Why would you care?
vbgunz
there needs to be a DOM library. anyone know of one?
Evertjan.
> there needs to be a DOM library.
Why?
> anyone know of one?
Doug Miller
>On Oct 30, 12:12 pm, Matt Kruse <m...@mattkruse.com> wrote:
>> On Oct 30, 9:50 am, David Mark <dmark.cins...@gmail.com> wrote:
>>
>> > > 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
> In article <1193763312.381969.138...@22g2000hsm.googlegroups.com>, David Mark <dmark.cins...@gmail.com> wrote:
>
> >On Oct 30, 12:12 pm, Matt Kruse <m...@mattkruse.com> wrote:
> >> On Oct 30, 9:50 am, David Mark <dmark.cins...@gmail.com> wrote:
>
> >> > > 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.
Matt Kruse
> > > > 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.
Why not? What would it hurt?
> > I would encourage you to do so. Please provide full documentation,
> > test suites, examples, and support as well.
> Why would you care?
Because maybe I would switch to it if it was better than what I'm
already using.
Until a better alternative _actually exists_, people will continue to
use the library that they find best suited for their task.
Your argument sounds like:
1. All libraries suck
2. I know the better way to do it
3. I have a library that is better than any other out there
4. You can't have it
It's really a pretty simple question that the critics here never want
to answer:
Let's say a group of developers are building a webapp that needs some
Javascript development. There is no in-house library to start with,
and all of the developers are just average at javascript, at best.
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
Thomas 'PointedEars' Lahn
> there needs to be a DOM library. anyone know of one?
For example, I have been distributing http://PointedEars.de/scripts/dhtml.js
as free software under the GPL v2 (or later) for almost five years now, and
I update it frequently (as the build version indicates) with regard to
backwards-compatibility to previous versions. What it still lacks is a
decent Web site (there is only a directory index), but it is documented
inline, and can be found by and with search engines.
HTH
David Mark
> On Oct 30, 11:55 am, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > > > 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.
>
> Why not? What would it hurt?
What makes you think that modules developed for my own use would be
appropriate for somebody else? I already mentioned that perhaps I
will post some of the low-level reusable functions. If and when I
find the time to document them for the masses, I will do so.
>
> > > I would encourage you to do so. Please provide full documentation,
> > > test suites, examples, and support as well.
> > Why would you care?
>
> Because maybe I would switch to it if it was better than what I'm
> already using.
I think you misunderstand my intention. I have no plans to publish
the next free library. I might post some low-level functions, which
could be of interest to people who need a foundation to start their
own libraries.
>
> Until a better alternative _actually exists_, people will continue to
> use the library that they find best suited for their task.
>
I don't think jQuery is suited for any task (same goes for Prototype
and Dojo.) People who ask about those libraries in here rarely
mention a specific task anyway. They know they want to sell an "Ajax
site", but they don't want to learn how to script a browser.
> Your argument sounds like:
> 1. All libraries suck
> 2. I know the better way to do it
> 3. I have a library that is better than any other out there
> 4. You can't have it
You just don't get it. There is no single library that is appropriate
for every task. That is what jQuery, Prototype, etc. try to be and
they fail miserably at it. I build modules from reusable functions
that are specific to the task at hand. Yes, some of these modules
mirror the functionality that is lumped together in the publicly
available libraries. No, I didn't make the sort of ridiculous
mistakes that cripple these libraries. And no, I am not interested in
publishing and supporting my codebase as a free library. Sorry.
>
> It's really a pretty simple question that the critics here never want
> to answer:
>
> Let's say a group of developers are building a webapp that needs some
> Javascript development. There is no in-house library to start with,
> and all of the developers are just average at javascript, at best.
> 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
What library do you know of that fits that description?
> 2. Write everything from scratch, which might be lower quality than
> the libraries and take too long
I am tired of hearing the "write everything from scratch" argument.
That is not the only other choice.
> 3. Hire a competent developer to write everything from scratch, which
> again might take too long and may not be an option financially
A competent developer would not write everything from scratch.
> 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.
For the last time, there is no "magic bullet" general purpose library
that is suitable for all tasks.
> 5. ???
>
> In a real case like this, how would you recommend that people proceed?
>
Real in the sense that you made it up? These "real" people should
proceed to either hire competent developers or learn JavaScript
themselves. In the latter case, the FAQ would be a good starting
point. If neither of these works for them, perhaps they shouldn't
write a Web app at all.
Matt Kruse
wrote:
> For example, I have been distributinghttp://PointedEars.de/scripts/dhtml.js
> as free software under the GPL v2 (or later) for almost five years now
this.isIE4DOM = typeof document.all == "object" && !this.isOpera;
Really?
Matt Kruse
Jeff North
<ma...@mattkruse.com>
<1193756060....@o3g2000hsb.googlegroups.com> wrote:
>| On Oct 29, 4:42 pm, David Mark <dmark.cins...@gmail.com> wrote:
>| > [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.
Thomas 'PointedEars' Lahn
If you had quoted properly and would have used common sense, you would have
known that it is there for backwards compatibility to previous versions of
the library. If you would have looked further, you would have found the
value being used in the current version only sparsely, where it does little
to no harm. You may rest assured that I will continue to review and, where
necessary, refactor the code on a regular basis.
Thomas 'PointedEars' Lahn
> [...] 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
enough better than the free stuff, your market might be larger than you think.
David Mark
> In article <1193766517.521764.170...@y42g2000hsy.googlegroups.com>, David Mark <dmark.cins...@gmail.com> wrote:
>
>
>
> >On Oct 30, 1:27 pm, spamb...@milmac.com (Doug Miller) wrote:
> >> In article <1193763312.381969.138...@22g2000hsm.googlegroups.com>, David Mark
> > <dmark.cins...@gmail.com> wrote:
>
> >> >On Oct 30, 12:12 pm, Matt Kruse <m...@mattkruse.com> wrote:
> >> >> On Oct 30, 9:50 am, David Mark <dmark.cins...@gmail.com> wrote:
>
> >> >> > > 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?
Brian Adkins
> On Oct 30, 2:46 pm, Matt Kruse <m...@mattkruse.com> wrote:
> > On Oct 30, 11:55 am, David Mark <dmark.cins...@gmail.com> wrote:
> > Your argument sounds like:
> > 1. All libraries suck
> > 2. I know the better way to do it
> > 3. I have a library that is better than any other out there
> > 4. You can't have it
>
> You just don't get it. There is no single library that is appropriate
> for every task.
The several recent threads about JavaScript libraries has seemed quite
confrontational to me. I'm sure I've contributed to that myself, so I
apologize. Maybe it was perceived that I was being difficult on
purpose, but I can say that it was out of frustration, and not out of
intent. I feel it's an important topic though, so I'd like to give
everyone the benefit of the doubt and try to work through what I think
are some communication issues.
David, is it possible you're misunderstanding Matt's intention? It may
be that he's not looking for a single library to be used for every
task, but is simply interested in being able to leverage preexisting
code written by others. Isn't this a common desire for programmers? If
we begin a networking project which requires C programming, we don't
start by developing a TCP/IP library, right?
For example, if someone wanted to utilize regular expressions in
Common Lisp, one option would be to write their own regular expression
library, and another option would be to simply use CL-PPCRE. There is
a web site: http://www.weitz.de/cl-ppcre/ which provides
documentation, etc. This library has received great reviews from the
Common Lisp community. It's important for newcomers to Common Lisp to
be aware that such libraries exist to avoid reinventing the wheel.
In the other thread, I was truly trying to discover if a similar
situation existed in the JavaScript world i.e. well known public
libraries that are worthwhile to use. Do you think it's reasonable for
JavaScript programmers (of any level) to be interested in reusing
preexisting code written by others in this way - not to shield them
from learning JavaScript, but to simply save some coding/testing/
debugging time?
> > 2. Write everything from scratch, which might be lower quality than
> > the libraries and take too long
>
> I am tired of hearing the "write everything from scratch" argument.
> That is not the only other choice.
Maybe there have been multiple "from scratch" posts because that
phrase has a different meaning with different people. I think other
people have been frustrated from this as well. I won't speak for Matt,
but when I see "write everything from scratch", I think the author is
referring to writing code themselves instead of utilizing preexisting
code from other sources.
So, when several people make the assertion that "you don't have to
write everything from scratch" or "you don't have to write it all
yourself", but don't provide a means for accomplishing that (i.e. a
source of preexisting code), it sounds like a circular argument and is
frustrating - for both parties I expect.
> > 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.
>
> For the last time, there is no "magic bullet" general purpose library
> that is suitable for all tasks.
I doubt that anyone would disagree with that statement. I also agree
that the larger a library is, the greater the possibility that you
won't need a large portion of it for a particular task. I think it's
probably common for people to inquire about large, general purpose
libraries such as Prototype, JQuery, Dojo, YUI, etc. because those are
the only ones they're familiar with because of the "press" they
receive.
It's possible that they aren't looking for that in particular (e.g. a
large bloated library), but feel the only way they can reuse
preexisting code written by others is by utilizing one of them, and so
are interested in trying to determine if learning/using one is a good
investment.
> > In a real case like this, how would you recommend that people proceed?
>
> These "real" people should
> proceed to either hire competent developers or learn JavaScript
> themselves.
Do you think learning JavaScript and utilizing someone else's
preexisting code is mutually exclusive? I'm not trolling, it's a
serious question. In every other language I've developed in
(Assembler, C, C++, Java, Ruby, Common Lisp, etc.) I've utilized
libraries written by others - not to avoid learning those languages,
but to be efficient. JavaScript running in a browser has some
challenges those other languages don't share with respect to library
use, but in principle, I would still think the benefits of library use
would apply.
tony.gurnick
have is infinitley more useless than a badly coded, in-efficient
library that I can have.
Richard Cornford
> Peter Michaux wrote:
>>> 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...
>
> I would urge many of the regulars to reconsider
> their positions.
Urgings would not be nearly as effective as sound reasoned arguments.
> Some of the Ajax libraries have gotten quite good lately.
That is a matter of opinion. One of the things that seems absent from
'Ajax libraries' is the middle layer between the XML HTTP requests and
the user interface; the layer that manages the coordination of the two
independent sources of asynchronous input (the user's actions and the
XML HTTP responses). Increasingly I am seeing web sites 'handling' the
issues in that area by switching to synchronous XML HTTP requests, which
is such a bad idea that 'Ajax libraries' really should not offer an
option to do synchronous requests.
> They eliminate most of the browser inconsistencies,
No they don't, and they don't even appear to be trying to as most pick a
small set of 'supported' browsers and will just fall apart if exposed to
anything outside of that set.
> relieving one of the major pain points in browser
> programming. And they shift the level of programming up
> a level, so that you can focus more on your application,
> and less on the browser's many limitations.
Maybe, but in some cases that shift may just be an abdication of
responsibility for the cross-browser issues.
> The biggest problems with the libraries are that there
> are too many of them,
I would say that a bigger problem is that these libraries are being
created by individuals who have not yet taken the time to learn
javascript, let alone browser scripting, and so are inevitably making
design mistakes, which then become entrenched because fixing them would
offend people already using the libraries.
> and that there are some problems with the browser
> architecture (particularly with security) that are
> unsolvable, given the current state of standards and
> browser implementations.
That is not really a problem with the libraries, except maybe some of
them make it easy to provoke security issues.
> It looks like the too many problem will solve itself with
> a shake out.
Probably, but not necessarily driven by rational criteria.
> I am predicting that the winners of the shake out will be
> Dojo and YUI because they are the best supported and
> documented.
You might be right, and it might be 'support' and 'documentation' that
decide the question, but that outcome would be a tragedy given how
utterly atrocious dojo actually is. There are just too many examples of
code like:-
| if(
| elem == null ||
| ((elem == undefined)&&(typeof elem == "undefined"))
| ){
| dojo.raise("No element given to dojo.dom.setAttributeNS");
| }
- in dojo for anyone to regard its authors as anything other than inept.
You know the logic of that code as well as I do, and can see that the
final - (typeof elem == 'undefined') - just cannot ever be evaluated,
and that the (elem == undefined) expression can only have one result
whenever it is evaluated (making its evaluation pure runtime overhead to
no purpose). It is a basic failure to understand javascript, and the
fact that it is there for all to see means that it marks the panicle of
javascript understanding among all the contributors to the dojo code.
This has obvious implications for the nature of 'support' available, and
where the authors don't actually understand the code they are writing
you also have to wonder how useful their documentation of their code
will prove.
> Good use of an Ajax library can improve your productivity
> and improve the portability of your application.
Can and will are not the same thing, and that action is not the only way
of achieving that outcome.
> The library makers scramble when every new browser ships
I bet they do, at least if it is a new version of one of the browsers
they chose to recognise in the first place. Most of the attempts to
handle multiple browsers that I have seen in this code is extremely
brittle and won't adapt at all well to changes in those browsers.
> to find the workarounds for the new bugs and gotchas.
> They are much better at that game than you want to be.
Better is very relative. If there is one thing that is obvious in the
common library's code it is that their authors have little knowledge of
cross-browser techniques, are not particularly good at pinning down the
cause and effect relationships of the issues they encounter and are
stuck in a mindset where each new browser/issue means another branch in
their code. With the bulk of that branching driven by browser sniffing.
Richard.
Peter Michaux
> On Oct 30, 4:09 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > On Oct 30, 2:46 pm, Matt Kruse <m...@mattkruse.com> wrote:
> > > On Oct 30, 11:55 am, David Mark <dmark.cins...@gmail.com> wrote:
> > > Your argument sounds like:
> > > 1. All libraries suck
> > > 2. I know the better way to do it
> > > 3. I have a library that is better than any other out there
> > > 4. You can't have it
>
> > You just don't get it. There is no single library that is appropriate
> > for every task.
>
> The several recent threads about JavaScript libraries has seemed quite
> confrontational to me. I'm sure I've contributed to that myself, so I
> apologize. Maybe it was perceived that I was being difficult on
> purpose,
This is why I gave the logging example "library." It is not clear what
size, scope, and purpose of code you want to reuse and the criteria
keeps changing yet you still want an answer. If any size, scope and
purpose is sufficient then the logging example is sufficient. If the
size, scope and purpose matter even a bit then they must be specified
and you will get a much more useful answer.
> but I can say that it was out of frustration,
I was more confused than frustrated when I started JavaScript but had
similar discussions when I first participated in comp.lang.javascript.
This newsgroup is the only public online community that I've found
where the regulars generally do not recommend using the big name
libraries. Most of the other communities are dedicated to a particular
library so it is no surprise that they recommend a library.
Since the beginning for me, I could see the discussions on
comp.lang.javascript contained more valid information about JavaScript
and browser scripting than those other forums. That got me thinking
"those surly, rude, socially incapable programmers must know
something." I don't really think those adjectives apply quite as much
as I initially thought. It is good that at least somewhere on the
internet there are a group of people that aren't afraid to call it
like they see it and hurt some feelings.
When I've been involved with other online communities related to
libraries, I get a sense of "I don't want to learn JavaScript and if
we all band together and keep telling each other we are doing a good
job we will be fine." Generally criticism is not welcome in large
doses. The Prototype library group is a perfect example. That library
initially augmented Object.prototype which is about the worst possible
namespace you could append properties if you care about namespace
clashes and for-in enumerations (no I don't buy the hasOwnProperty()
stuff.) In the end the Prototype group saw the wisdom that others were
offering by telling them to stop doing that. But in the mean time
there were battles and arguments about it. The Prototype community
were defending their flag of honour and critics were derided and
labeled heretics. It took a long time to make that change. That
library is slowly changing it's ways. The library still augments other
built-in objects and it has caused problems with new browser releases,
the library is still distributed in one huge file and does all sorts
of contortions with the language. Do you want to wait for them to fix
that stuff too? You could learn JavaScript and write your own library
perfectly applicable to your situation without any of their legacy
restrictions far faster than they can change.
> and not out of
> intent. I feel it's an important topic though,
Code reuse is an important topic.
> so I'd like to give
> everyone the benefit of the doubt and try to work through what I think
> are some communication issues.
>
> David, is it possible you're misunderstanding Matt's intention? It may
> be that he's not looking for a single library to be used for every
> task, but is simply interested in being able to leverage preexisting
> code written by others. Isn't this a common desire for programmers? If
> we begin a networking project which requires C programming, we don't
> start by developing a TCP/IP library, right?
Starting a JavaScript project without a library is not quite like
starting a C project without TCP/IP library or stdlib or something
similarly fundamental. Even for a big project, the JavaScript library
code that you would need to write would be only a few thousand lines.
This is part of the reason so many JavaScript libraries exist: the
entry cost is low. To start a C project with no libraries would mean
tens of thousands of lines of libraries to write and I'd say those
libraries would be individually far more complex than any of the
JavaScript libraries. You would literally be operating at the bit
level at times and writing malloc would be no treat I'm sure.
> For example, if someone wanted to utilize regular expressions in
> Common Lisp, one option would be to write their own regular expression
> library, and another option would be to simply use CL-PPCRE. There is
> a web site:http://www.weitz.de/cl-ppcre/which provides
> documentation, etc. This library has received great reviews from the
> Common Lisp community. It's important for newcomers to Common Lisp to
> be aware that such libraries exist to avoid reinventing the wheel.
There are different priorities in browser scripting than the tasks for
which other languages are used. For example, code size matters much
more in browser scripting and perhaps doesn't matter much at all in
most other tasks.
> In the other thread, I was truly trying to discover if a similar
> situation existed in the JavaScript world i.e. well known public
> libraries that are worthwhile to use.
You can easily find people that will answer yes. There must be a
reason you stayed here.
> Do you think it's reasonable for
> JavaScript programmers (of any level) to be interested in reusing
> preexisting code written by others in this way - not to shield them
> from learning JavaScript, but to simply save some coding/testing/
> debugging time?
I first used YUI to learn many things. I've read some jQuery code and
ext to learn how they do CSS selectors. Using those libraries as
educational resources has been helpful.
The fundamental libraries seem to be for events and Ajax. Really with
those two libraries you can build everything else quite easily. I
wrote my own event and Ajax libraries (roughly based on the YUI API)
and you can even find them available on the web. It has worked out
much better than using one of the big name libraries. I still receive
emails from the YUI and Prototype ticket systems for tickets I created
over a year and a half ago. I didn't have time to wait for that long.
I also don't have any of the bloat of features that I don't use and
don't even think are a good idea to use.
Even if I had used a publicly available library for events and Ajax, I
have never had the opportunity to reuse widgets like a tabbed pane,
drop down menu, etc in my job. The main reason is I always need custom
features. High level components are just less reusable. However with a
base events library is it very easy to write a custom widget that has
exactly the necessary functionality and nothing more. The widgets I've
written have typically been a tenth the size of publicly available
widgets that do many things but not what I need.
> > > 2. Write everything from scratch, which might be lower quality than
> > > the libraries and take too long
>
> > I am tired of hearing the "write everything from scratch" argument.
> > That is not the only other choice.
>
> Maybe there have been multiple "from scratch" posts because that
> phrase has a different meaning with different people. I think other
> people have been frustrated from this as well. I won't speak for Matt,
> but when I see "write everything from scratch", I think the author is
> referring to writing code themselves instead of utilizing preexisting
> code from other sources.
Using preexisting code probably means different things to different
people.
> So, when several people make the assertion that "you don't have to
> write everything from scratch" or "you don't have to write it all
> yourself", but don't provide a means for accomplishing that (i.e. a
> source of preexisting code), it sounds like a circular argument and is
> frustrating - for both parties I expect.
>
> > > 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.
>
> > For the last time, there is no "magic bullet" general purpose library
> > that is suitable for all tasks.
>
> I doubt that anyone would disagree with that statement. I also agree
> that the larger a library is, the greater the possibility that you
> won't need a large portion of it for a particular task. I think it's
> probably common for people to inquire about large, general purpose
> libraries such as Prototype, JQuery, Dojo, YUI, etc. because those are
> the only ones they're familiar with because of the "press" they
> receive.
>
> It's possible that they aren't looking for that in particular (e.g. a
> large bloated library), but feel the only way they can reuse
> preexisting code written by others is by utilizing one of them, and so
> are interested in trying to determine if learning/using one is a good
> investment.
Sometimes they might not like the answer they receive.
> > > In a real case like this, how would you recommend that people proceed?
>
> > These "real" people should
> > proceed to either hire competent developers or learn JavaScript
> > themselves.
>
> Do you think learning JavaScript and utilizing someone else's
> preexisting code is mutually exclusive?
You need to understand JavaScript to use any of the publicly available
big name libraries. The more you understand and the more you look
around then I think the code in the libraries becomes less appealing.
At the next level above whether or not a library works or not is how
does it work. Libraries generally encourage particular style of
programming. jQuery is a good example. "Find stuff and do stuff to
it." I experimented with jQuery for a while and read examples on the
web. With jQuery, it is so easy (just characters of code) to find
stuff that people do it all the time. jQuery seems to have encouraged
it's users to write inefficient code. This is a problem beyond the
actual bugs and hacks that are in jQuery that may break with new
browser releases and may not have any substitutable solutions at all
when they do (eg the window.onload problem) due to the code that the
library has encouraged.
> I'm not trolling, it's a
> serious question. In every other language I've developed in
> (Assembler, C, C++, Java, Ruby, Common Lisp, etc.) I've utilized
> libraries written by others - not to avoid learning those languages,
> but to be efficient. JavaScript running in a browser has some
> challenges those other languages don't share with respect to library
> use, but in principle, I would still think the benefits of library use
> would apply.
There is a feeling that the average ability of library writers in
JavaScript/browser scripting is far lower than the average abilities
of programmers in other languages/contexts. This is likely due where
JavaScript programmers come from in life. Without stats I would guess
less have computer science degrees and more are self-taught. This
makes your comparison less apples-to-apples as the libraries in the
other languages may have been more worthy of reuse.
Peter
Brian Adkins
> On Oct 30, 5:17 pm, Brian Adkins <lojicdot...@gmail.com> wrote:
> > The several recent threads about JavaScript libraries has seemed quite
> > confrontational to me. I'm sure I've contributed to that myself, so I
> > apologize. Maybe it was perceived that I was being difficult on
> > purpose,
>
> This is why I gave the logging example "library." It is not clear what
> size, scope, and purpose of code you want to reuse and the criteria
> keeps changing yet you still want an answer. If any size, scope and
> purpose is sufficient then the logging example is sufficient. If the
> size, scope and purpose matter even a bit then they must be specified
> and you will get a much more useful answer.
I'm sorry Peter, but if you continue to insist that what you provided
was a realistic solution to my question (regardless of how ill-formed
you may have felt it was), I think it may be difficult for us to have
a conversation. I noticed you put "library" in quotes, so maybe you
sensed it was not a reasonable solution also.
If you honestly feel that you would consider creating a web site, for
example, to offer that code to the public as a "library", then I
apologize, but I seriously doubt that is the case. Do you now
understand why I included "publicly available" as a criteria?
Anyway, if any library/module authors who were proud of their code
were reading any of these threads, I expect they would have mentioned
their offerings by now, so we're probably beyond beating a dead horse
at this point, I think it's probably a bloody pulp :)
> When I've been involved with other online communities related to
> libraries, I get a sense of "I don't want to learn JavaScript
I believe you, and others, may have projected that attitude onto
people who don't share it. That's probably where the "straw man"
arguments keep coming from - not from maliciousness, but from not
bothering to actually understand where people are coming from and
simply assuming.
> Code reuse is an important topic.
Do you reuse code from others? If so, what are the sources of code
that you've found valuable.
> The fundamental libraries seem to be for events and Ajax. Really with
> those two libraries you can build everything else quite easily. I
> wrote my own event and Ajax libraries (roughly based on the YUI API)
> and you can even find them available on the web.
Well, why the heck didn't you mention those instead of the logger
thing ?! :) What's the URL?
> It has worked out
> much better than using one of the big name libraries. I still receive
> emails from the YUI and Prototype ticket systems for tickets I created
> over a year and a half ago. I didn't have time to wait for that long.
> I also don't have any of the bloat of features that I don't use and
> don't even think are a good idea to use.
If I end up writing a lot of code myself, that's fine, but it doesn't
make sense to reinvent the wheel if you don't have to. I have to say
the effort to have a dialog here has been much more than any other
newsgroup. Discovering some valuable, time saving libraries for Common
Lisp was straightforward.
> > Maybe there have been multiple "from scratch" posts because that
> > phrase has a different meaning with different people. I think other
> > people have been frustrated from this as well. I won't speak for Matt,
> > but when I see "write everything from scratch", I think the author is
> > referring to writing code themselves instead of utilizing preexisting
> > code from other sources.
>
> Using preexisting code probably means different things to different
> people.
Yes, but "preexisting code from other sources" should be pretty clear,
even in this crowd, right? "preexisting" => "it has already been
written"
"from other sources" => "I didn't write it"
Brian
Matt Kruse
> What makes you think that modules developed for my own use would be
> appropriate for somebody else?
Do you think you are solving extremely unique problems?
> I think you misunderstand my intention. I have no plans to publish
> the next free library. I might post some low-level functions, which
> could be of interest to people who need a foundation to start their
> own libraries.
I assume you have assembled your low-level functions into high-level
functionality at some point, so surely you have developed enough
functionality to accomplish complex tasks. Why not post all the code
you have - even if undocumented - as a great jump-start to anyone want
to assemble those pieces into something they would find useful?
> You just don't get it. There is no single library that is appropriate
> for every task. That is what jQuery, Prototype, etc. try to be and
> they fail miserably at it.
I think you misjudge the intent. IMO, these libraries intend to be a
solid framework that combine low-level reusable functions with an
intuitive API. They don't try to solve every problem. They give the
developer a different set of tools to use. Tools which are often more
compact, easier to use, and provide good browser abstraction.
Inserting jquery.js into a page will do nothing for you. It's just a
tool. You still need to write code.
How is this approach any different from your own set of low-level
functions? Libraries like jQuery just assemble the most often-used set
of tools and give them a consistent API. In under 30k of code, you
have a large set of functionality that you know will always be
available without having to piece together various functions to do
exactly what you want. How is that bad?
> And no, I am not interested in
> publishing and supporting my codebase as a free library. Sorry.
Which is ridiculous. So you have nothing to really offer anyone except
bashing the solutions others are developing. Great approach!
> I am tired of hearing the "write everything from scratch" argument.
> That is not the only other choice.
What _is_ the other choice? Could you be more specific?
If you don't get a library or set of functions from someone else, will
it magically write itself?
> For the last time, there is no "magic bullet" general purpose library
> that is suitable for all tasks.
I don't see anyone claiming that there is.
But there are general purpose libraries that provide a set of tools
and framework that will be beneficial in many common tasks.
Matt Kruse
Peter Michaux
> On Oct 30, 10:51 pm, Peter Michaux <petermich...@gmail.com> wrote:
>
> > On Oct 30, 5:17 pm, Brian Adkins <lojicdot...@gmail.com> wrote:
> > > The several recent threads about JavaScript libraries has seemed quite
> > > confrontational to me. I'm sure I've contributed to that myself, so I
> > > apologize. Maybe it was perceived that I was being difficult on
> > > purpose,
>
> > This is why I gave the logging example "library." It is not clear what
> > size, scope, and purpose of code you want to reuse and the criteria
> > keeps changing yet you still want an answer. If any size, scope and
> > purpose is sufficient then the logging example is sufficient. If the
> > size, scope and purpose matter even a bit then they must be specified
> > and you will get a much more useful answer.
>
> I'm sorry Peter, but if you continue to insist that what you provided
> was a realistic solution to my question (regardless of how ill-formed
> you may have felt it was)
No offense but it was ill formed and that has been the problem all
along. Other respondents tried to get you to specify your requirements
but it hasn't happened. I was just giving an extreme example that
satisfied your request perhaps prompting a refined request. Please
state the exact specifications of the type of code you would like to
reuse and for what purpose.
> I think it may be difficult for us to have
> a conversation. I noticed you put "library" in quotes, so maybe you
> sensed it was not a reasonable solution also.
It was intended to be obviously unreasonable. It is for debug logging
after all. That isn't even done in production code.
> If you honestly feel that you would consider creating a web site, for
> example, to offer that code to the public as a "library", then I
> apologize, but I seriously doubt that is the case.
You are right. I wouldn't.
> Do you now
> understand why I included "publicly available" as a criteria?
Your specs keep changing and several people have pointed to this
problem. Is a having a website the only way to be satisfactorily
public? Does having a website mean a library is better?
> Anyway, if any library/module authors who were proud of their code
> were reading any of these threads, I expect they would have mentioned
> their offerings by now, so we're probably beyond beating a dead horse
> at this point, I think it's probably a bloody pulp :)
>
> > When I've been involved with other online communities related to
> > libraries, I get a sense of "I don't want to learn JavaScript
>
> I believe you, and others, may have projected that attitude onto
> people who don't share it.
I was fresh meat and equally new to other communities and to
comp.lang.javascript. I don't have any personal connections to anyone
programming in JavaScript. I was relatively unbiased. That was the
impression I got especially in the Rails/Prototype community where
there is a movement to hide all JavaScript in Ruby wrappers.
> That's probably where the "straw man"
> arguments keep coming from - not from maliciousness, but from not
> bothering to actually understand where people are coming from and
> simply assuming.
>
> > Code reuse is an important topic.
>
> Do you reuse code from others? If so, what are the sources of code
> that you've found valuable.
comp.lang.javascript faq and faq notes
comp.lang.javascript archives
google.com search results
YUI and other libraries
All are just educational resources for me. After I understand the
problem I write my own version specific to my task with the API I
like.
The most important page I've read about doing browser scripting well
is
http://www.jibbering.com/faq/faq_notes/not_browser_detect.html
but I haven't used any of that code as is.
> > The fundamental libraries seem to be for events and Ajax. Really with
> > those two libraries you can build everything else quite easily. I
> > wrote my own event and Ajax libraries (roughly based on the YUI API)
> > and you can even find them available on the web.
>
> Well, why the heck didn't you mention those instead of the logger
> thing ?! :)
I was being an ass, making a mild joke and also a point to try to get
a better question from you so that you would get a more useful answer.
> What's the URL?
It works for me in my work situation and the way I handle degradation
paths.
> > It has worked out
> > much better than using one of the big name libraries. I still receive
> > emails from the YUI and Prototype ticket systems for tickets I created
> > over a year and a half ago. I didn't have time to wait for that long.
> > I also don't have any of the bloat of features that I don't use and
> > don't even think are a good idea to use.
>
> If I end up writing a lot of code myself, that's fine, but it doesn't
> make sense to reinvent the wheel if you don't have to. I have to say
> the effort to have a dialog here has been much more than any other
> newsgroup. Discovering some valuable, time saving libraries for Common
> Lisp was straightforward.
Perhaps "valuable, time saving libraries" are readily available in the
Common Lisp world but not in the JavaScript world.
> > > Maybe there have been multiple "from scratch" posts because that
> > > phrase has a different meaning with different people. I think other
> > > people have been frustrated from this as well. I won't speak for Matt,
> > > but when I see "write everything from scratch", I think the author is
> > > referring to writing code themselves instead of utilizing preexisting
> > > code from other sources.
>
> > Using preexisting code probably means different things to different
> > people.
>
> Yes, but "preexisting code from other sources" should be pretty clear,
> even in this crowd, right? "preexisting" => "it has already been
> written"
> "from other sources" => "I didn't write it"
Somewhere communication has broken down. It seems you think you have
clearly stated your library specs. You've assumed people will imply
the same things you have implied in you requirements but that hasn't
appeared to be the case. What do you want? Do you need a large user
base for the library? Do you need tutorials and documentations? Do you
need code that works on IE4 or cell phones or only in Opera 9? Do you
want event and Ajax libraries or do you only need to be able to
validate form inputs? Do you need code that has a larger chance of
working in future browsers or browser you have not tested? Do you have
a perfectionist in you that just can't stand seeing bad practices in
code that works now but likely will cause you grief down the road?
Perhaps you are writing a website for lower income people or people in
the third world with very slow connections so download times matter
more? Are you writing as site for blind people? Perhaps you are
writing for an internal app behind a login? How much money do you have
for development and testing? Does a particular library style/syntax
appeal to you? Is your website mission critical like a banking site or
is it a hobby site? If a bug appears how quickly will you need it
fixed in the library code? How do you weight all these requirements?
Some of these requirements will automatically negate YUI, Dojo,
Prototype, jQuery etc. There are likely people on comp.lang.javascript
that work in a wide variety of these situations so their priorities
will vary from yours and impact their answers if left to implications.
If you like the answers you receive or not is a different story and
apparently so far you haven't liked them.
I don't think that many people in JavaScript/browser scripting are
pleased with the missing aggregation of knowledge. At least an
outstanding book should exist. Currently it takes a newcomer an
unreasonably long time to gather all the information. The really
knowledgeable developers are busy working which pays much more money
than book writing.
Right now what I would like the most is an example from Richard
Cornford about how he implements and documents his library style with
an interface having several implementations. It is quite clear after
his explanation but an example may show some subtle things he has
learned working with such a library system.
Peter
Brian Adkins
> On Oct 30, 8:26 pm, Brian Adkins <lojicdot...@gmail.com> wrote:
> 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
downloaded without paying for it first.
Peter Michaux
> On Oct 31, 12:32 am, Peter Michaux <petermich...@gmail.com> wrote:
>
> > On Oct 30, 8:26 pm, Brian Adkins <lojicdot...@gmail.com> wrote:
> > 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
beegee
> I don't know if it will help with your task I think you should use YUI
> for a while.
>
I have been using YUI for almost two years. I use the Tree, Panel,
Container, Menu, Event modules and at times have used the Connection
(AJAX) module. They are all solid and do not obfuscate the language
like JQuery, Prototype etc. The documentation is good and the code is
so well written that tweaks to the library are easy to make. I have
used the datatable module for one project and have backed off a bit
because it is lacking in a few features that seem essential to me (the
ability to load from local XML for one).
There are two downsides to this library that I can see. One is that
if you are using many modules on a page, the load is slow although YUI
has an experimental Loader module that may help with this. The other
downside is that some of their releases have been backwardly
incompatible and though they provide extensive notes as to most of
these backward incompatibilities, it is a pain with a large site.
I have come to believe lately that there are no real helpful AJAX
libraries and that the task of cobbling together your own AJAX object
or set of functions is pretty easy and the best solution.
But hey, you want some real library nastiness, try creating javascript
proxies for .NET web services. We should all be grateful for
mootools,jquery,prototype,yui,dojo and on and on, excuse the incorrect
capitalization.
Bob
Brian Adkins
> 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 ;)
Thomas 'PointedEars' Lahn
> On Oct 31, 8:24 am, Peter Michaux <petermich...@gmail.com> wrote:
>> I don't know if it will help with your task I think you should use YUI
>> for a while.
>
> I have been using YUI for almost two years. I use the Tree, Panel,
> Container, Menu, Event modules and at times have used the Connection
> (AJAX) module. They are all solid and do not obfuscate the language
> like JQuery, Prototype etc. The documentation is good and the code is
> so well written that tweaks to the library are easy to make. I have
> used the datatable module for one project and have backed off a bit
> because it is lacking in a few features that seem essential to me (the
> ability to load from local XML for one).
The important question is: Could the UI features they provide generally
display without client-side script support, do they degrade gracefully?
If the answer to that is no, then they are not suited for general use.
> But hey, you want some real library nastiness, try creating javascript
> proxies for .NET web services.
That there is someone who does a (bad) thing even worse and therefore
the (bad) thing was good is a loser's argument, or IOW a logical fallacy.
> We should all be grateful for mootools,jquery,prototype,yui,dojo and
> on and on, excuse the incorrect capitalization.
No, "we" should not, with *maybe* the exception of YUI. And if you had
cared to consider the arguments already provided, you would know why.
PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
Peter Michaux
> On Oct 31, 8:24 am, Peter Michaux <petermich...@gmail.com> wrote:
>
> > 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
RobG
I think your question was answered fairly quickly and thoroughly.
Peter pointed you to an existing thread, others chimed in with
opinions on major libraries within a couple of days and others
responded with their opinions of those libraries. Which goes back to
why you won't see them recommended here.
I suggest you lurk for awhile in news groups related to the libraries
you'd like to try and see if you like what you see.
> 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.
There is certainly an attitude that the standard of code in most
general libraries is not very high and that the time and effort
required to learn the library may be better spent writing a bespoke
framework. Those opinions will be supported by examples if you ask
(there are some in threads from your OP). So while you may not like
the attitude, there is a sound reason for the bias.
But don't be discouraged, the bottom line is that those who like and
use libraries are probably using news groups dedicated to those
libraries. That is because most libraries introduce their own API
that masks the underlying built-in javascript objects and methods and
the W3C DOM API, so it is a bit pointless asking questions in a
general javascript news group.
Those who are regulars here mostly don't use libraries because they
have decided not to (most probably because they don't like what's on
offer) and are therefore unlikely to recommend one.
--
Rob
David Mark
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.
John Resig
ramblings set up by someone who has obviously never created a
JavaScript library of any kind, nor has used JavaScript code in any
sort of production environment.
I'll reply to your alleged critiques to the code below.
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
(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.
> Hardly. It is woven into many important low-level functions. Here is
> a particularly stupid snippet from the get/setAttribute wrapper called
> attr:
>
> } else if ( jQuery.browser.msie && name == "style" )
>
> return jQuery.attr( elem.style, "cssText", value );
>
> Do you have any idea how many agents jQuery will identify as IE?
The ones we care about?
> Do
> you have any idea how trivial it is to properly feature detect IE's
> broken get/setAttribute functionality?
Pray tell! I must've missed the boolean property that tells me that
it's broken as all get out.
> Forget that for the moment, why is this function passing a style
> object to itself?
The .attr() function can be a little futzy (it's long due for a
rewrite). For now, it's written this way to keep all attribute/css
special-case logic contained to a single location.
> if ( jQuery.browser.msie && /href|src/.test(name) && !
> jQuery.isXMLDoc(elem) )
> return elem.getAttribute( name, 2 );
>
> Just what sort of XML document runs script in IE? Certainly not an
> XHTML document. Realize that this absurd line of code is evaluated
> every time jQuery looks at an element's attribute.
Huh? That gets the interpreted value of an attribute, only in IE, and
only if it isn't within an XML document (and only for the href and src
attributes - which are the ones that have the specific URL-
interpretation problems).
> Then there is this gem:
>
> // Certain attributes only work when accessed via the old DOM 0 way
> if ( fix[name] ) {
> if ( value != undefined ) elem[fix[name]] = value;
> return elem[fix[name]];
>
> This demonstrates a stunning lack of understanding of attributes (and
> IE's problems with them.) Where's the sniff (or feature detect) for
> IE? This IE-specific workaround runs on everything.
This has nothing to do with being IE-specific, or not. Look at the fix
object - it contains a number of properties (both CSS and regular
attribute) that need to be re-written or defer to another attribute.
(For example, this is also used to fix cases where a user
types .attr("readonly") instead of .attr("readOnly")).
> Still in the same function:
>
> else if ( value == undefined && jQuery.browser.msie &&
> jQuery.nodeName(elem, "form") && (name == "action" || name ==
> "method") )
> return elem.getAttributeNode(name).nodeValue;
>
> No comment for this magic spell, so there is no telling what it is
> trying to do.
The action and method attributes can be overwritten in IE, like so:
<form>
<input type="text" id="action"/>
</form>
Thus, this code handles that case and gets the correct value, special.
> One thing is certain. This code will run on lots of
> non-IE agents.
It only runs on the ones that we care about - but apparently this
mythical, ultra-popular, StrawMan v1.0 is all the rage these days.
> if ( value != undefined ) {
> if ( name == "type" && jQuery.nodeName(elem,"input") &&
> elem.parentNode )
> throw "type property can't be changed";
> elem.setAttribute( name, value );
> }
>
> Another example of confusing attributes with properties. This is also
> an IE-specific workaround with no sniff (or feature detect.)
This was done completely intentionally - we don't support dynamically
changing the type attribute on input elements, since it causes an
exception to be thrown in IE (we would rather have a consistent code
base, across all browsers that we support, than have problems arise
later for users).
> And just when you think you have seen every conceivable miscue (all in
> a single function mind you.)
>
> if ( name == "opacity" && jQuery.browser.msie ) {
> if ( value != undefined ) {
> // IE has trouble with opacity if it does not have layout
> // Force it by setting the zoom level
> elem.zoom = 1;
>
> What in God's name do opacity (and other styles) have to do with
> attributes?
See above.
> That's enough of that function. Keep in mind that the code therein is
> called constantly by jQuery. Unfortunately for those who rely on
> jQuery, it is error-prone, confused, inefficient and convoluted.
Error-prone? Doubtful. Where's your test suite-backed attribute/css
manipulation code, I'd love to see it!
Inefficient, possibly. We've already made a number of optimizations
wherever possible - but many of the checks can't be circumvented.
Convoluted - sure. As I mentioned before, it's due for a re-write.
> The
> design (and documentation) is of such poor quality that it is an
> assault on the senses of anyone unfortunate enough to glance at it.
Sigh. Where's your ultra-documented, totally-awesome, perfect-in-every-
way JavaScript library? That's what I thought - you don't have one,
nor does one exist.
> And speaking of opacity. In the curCSS function:
>
> if (prop == "opacity" && jQuery.browser.msie) {
> ret = jQuery.attr(elem.style, "opacity");
> return ret == "" ? "1" : ret;
>
> }
>
> So any agent that identifies as IE and will be re-routed to the attr
> function, which has nothing to do with style, but does contain more
> sniffing and some IE-specific DirectX twiddling, which will have no
> (positive) effect on non-IE agents.
See above - it works for everything that we support. We make no
illusions as to otherwise.
> It would seem that querying style rules would be almost as critical to
> querying attributes in a library like jQuery. Yet, in this same
> function you find this gem:
>
> // A helper method for determining if an element's values are broken
> function color(a){
> if ( !jQuery.browser.safari )
> return false;
>
> var ret = document.defaultView.getComputedStyle(a,null);
> return !ret || ret.getPropertyValue("color") == "";
>
> }
>
> This is the author's idea of a feature detect for getComputedStyle.
> Why Safari-like browsers are excluded is a mystery. After that
> inauspicious start, it blunders into the defaultView, getComputedStyle
> and getPropertyValue properties with the impunity of somebody who
> hasn't got a clue as to what they are doing.
Wow. WowWowWow. Spoken like a true babe! It's damn simple to detect it
in all browsers but Safari. In Safari 2, in an element that is
display: none, getComputedStyle() returns null. In Safari 3, it
returns a style object, but within with all values return "" (which
may, or may not, be a valid return value - it's impossible to tell!).
Thus, you have to check for the existence of the computed color value
(which will always exist) and if it's empty, then we're inside a
corrupted element.
> It goes on and on. From the clean function:
>
> if ( jQuery.browser.msie ) { // String was a <table>, *may* have
> spurious <tbody>
> if ( !s.indexOf("<table") && s.indexOf("<tbody") < 0 )
> tb = div.firstChild && div.firstChild.childNodes;
>
> div *may* have a firstChild property.
Yes? Your point? IE can, sometimes, not auto-generate a <tbody>
wrapper (when there's no contents to the table). This verifies when a
<table></table> is passed in makes sure that a tbody is constructed.
Again, everything here is backed by a test suite.
> >From the same function:
>
> // IE can't serialize <link> and <script> tags normally
> jQuery.browser.msie && [1, "div<div>", "</div>"]
>
> You have to keep in mind while reading this stuff that
> jQuery.browser.msie is meaningless on the Web. It isn't of much use
> on an Intranet either, unless you use the same version and
> configuration of IE forever.
Huh? Show me a drastically improved version of IE and I'll show you an
updated copy of jQuery.
> >From merge:
>
> // Also, we need to make sure that the correct elements are being
> returned
> // (IE returns comment nodes in a '*' query)
> if ( jQuery.browser.msie ) {
> for ( var i = 0; second[i]; i++ )
> if ( second[i].nodeType != 8 )
> first.push(second[i]);
> } else
>
> Same problem different function. What if some agent that doesn't
> identify as IE has the same problem?
These browsers that you keep talking about must be amazing! They're,
quite literally, everywhere! At every turn there's a browser that we
support that also claims to be IE, but it isn't IE! What have we been
doing wrong all this time? How could we have been so naive?
> Also note how hard it is to
> follow with all of the missing brackets.
*shrug*
> More madness:
>
> var styleFloat = jQuery.browser.msie ? "styleFloat" : "cssFloat";
>
> Obviously you should just check (or set) them both. What happens if
> IE8 switches gears on this? And what of an IE-spoofing agent that
> doesn't use "styleFloat?"
The same argument, over and over, is getting incredibly old. Where's
your ultra-popular library that is 100% future proof?
Considering that IE is going to be backwards compatible for, most
likely, many many years to come, I'm not worried. When the year 2031
arrives, jQuery can, and will adapt.
> // Check to see if the W3C box model is being used
> boxModel: !jQuery.browser.msie || document.compatMode == "CSS1Compat",
>
> That could have far-reaching implications. A quick search found it in
> an attempt to measure the viewport:
>
> return this[0] == window ?
> jQuery.browser.safari && self["inner" + name] || jQuery.boxModel &&
> Math.max(document.documentElement["client" + name],
> document.body["client" + name]) ||
> document.body["client" + name] :
> this[0] == document ?
> Math.max( document.body["scroll" + name], document.body["offset" +
> name] ) :
> h == undefined ?( this.length ? jQuery.css( this[0], n ) : null ) :
> this.css( n, h.constructor == String ? h : h + "px" );
>
> I characterized this as a "million monkey" project earlier and I want
> to take a moment to apologize to monkeys everywhere. I think even a
> single monkey could write a better solution to this very common
> problem. Certainly there are many better solutions floating around on
> the Internet.
Certainly! They are, literally, everywhere! I mean, I can't go
anywhere without tripping over a test-suite-backed, cross browser,
quirksmode-handling, browser width and height detection script.
Your "arguments" consist of nothing but assumptions dressed up as
criticism.
> And boxmodel can also be observed in the positioning code:
>
> // IE adds the HTML element's border, by default it is medium which is
> 2px
> // IE 6 and IE 7 quirks mode the border width is overwritable by the
> following css html { border: 0; }
> // IE 7 standards mode, the border is always 2px
> if ( msie ) {
> var border = jQuery("html").css("borderWidth");
> border = (border == "medium" || jQuery.boxModel &&
> parseInt(version) >= 7) && 2 || border;
> add( -border, -border );
> }
> There are so many misconceptions here it is hard to know where to
> begin. Suffice to say that the clientLeft/Top properties hold the
> needed information in IE.
Yes, we are well aware of the clientLeft/Top properties -
unfortunately there are edge cases where they are not sufficient
(especially when moving between standards and quirksmode).
You're definitely proving that it's much easier to make off-the-cuff
criticisms than to actually provide working, tested, cross-browser
solutions. All of which we've done, and supported, for almost 2 years
now.
> In the same function:
>
> // Mozilla and Safari > 2 does not include the border on offset
> parents
> // However Mozilla adds the border for table cells
> if ( mozilla && /^t[d|h]$/i.test(parent.tagName) || !safari2 )
> border( offsetParent );
>
> Apparently, in the jQuery universe there is only Opera, Mozilla,
> Safari and IE. IE never gets here. Opera (and Safari <= 2 if you
> believe the comments) adds borders when it shouldn't. So this logic
> excludes everything the author has ever heard of that isn't Opera.
Right. See above.
> Speaking of Mozilla. Does this look like a good indication of Mozilla-
> based browsers?
>
> mozilla: /mozilla/.test(userAgent) && !/(compatible|
> webkit)/.test(userAgent)
>
> Why not call that the everything-under-the-sun property?
Because it's not? It captures everything that we care about.
> Getting back to border issue, in the mozilla-and-newer-Safari-only
> (and oddly named) border function:
>
> add( jQuery.css(elem, "borderLeftWidth"), jQuery.css(elem,
> "borderTopWidth") );
>
> What an outrage. The author apparently never heard of clientLeft/Top.
See above.
> Backing up to where boxModel was first spotted, this is deja vu:
>
> styleFloat: jQuery.browser.msie ? "styleFloat" : "cssFloat",
>
> Yes, this logic is repeated just three lines below the first instance.
This was already fixed in SVN:
http://dev.jquery.com/browser/trunk/jquery/src/core.js#L1180
> Moving on. In the ready function:
>
> if ( jQuery.browser.mozilla || jQuery.browser.opera )
> document.removeEventListener( "DOMContentLoaded", jQuery.ready,
> false );
>
> So if it is virtually any agent, assume there is a document object (a
> fair assumption) and assume that it has a removeEventListener method
> (an outrageous assumption.) Why the event listener needs to be
> removed at all is another interesting question. The comments
> mentioned memory leaks.
Man, why am I not using this StrawMan browser? It is, apparently, used
everywhere. Once again, if it's not in the 99% of all browsers that we
support, we don't care.
We remove the event to be tidy - if we don't need to keep it bound,
then there's no reason to waste any perfectly-good memory on it. I
don't understand why this is an issue for you. Do you prefer that
libraries keep everything bound indefinitely? Do you want them to have
high overhead and run slow?
> Here is the flip-side of this in bindReady:
>
> // If Mozilla is used
> if ( jQuery.browser.mozilla || jQuery.browser.opera )
> // Use the handy event callback
> document.addEventListener( "DOMContentLoaded", jQuery.ready,
> false );
>
> So two of the four browsers that the author knows of are known to
> support DOMContentLoaded. Of course, it wouldn't hurt to add this
> listener for everything. Come to think of it, he did (unknowingly)
> add it for virtually everything.
Except for half the browsers - Safari and IE. Which is not "virtually
everything".
> You've got to love the comments. "Use the handy event callback" may
> be the least informative one yet. Here's another interesting one from
> makeArray:
>
> // Need to use typeof to fight Safari childNodes crashes
> if ( typeof a != "array" )
> for ( var i = 0, al = a.length; i < al; i++ )
> r.push( a[i] );
> else
> r = a.slice( 0 );
>
> And why would you pass an array to a "makeArray" function anyway?
.makeArray() is designed to take any array-like object and return a
clone of itself. Thus this will work for both NodeLists and regular
arrays (for example). Note the key word there: clone - it doesn't
return the original (hence it's only used for when an array needs to
be cloned).
> This reminds me of the function test code, which was blistered in
> another recent "jQuery is a joke" thread.
I assume that you're referring to jQuery.isFunction(). If you have a
comparable method that's able to pass all of these tests in all modern
browsers, let me know! I'll be happy to take a look.
http://dev.jquery.com/browser/trunk/jquery/test/unit/core.js#L62
> Enough is enough. If you use jQuery after reading this, you are
> deserve everything you get.
Apparently, a thoroughly tested and comprehensively written JavaScript
library - who knew?
> 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.
> Really? Define packed. Minified it is roughly 50K. GZIP doesn't
> enter into it (unless you can't comprehend why it is silly to compare
> file sizes after compression.) How small would a 20K library be after
> compression? Regardless, you shouldn't manually compress JavaScript
> files.
Run through Dean Edwards' Packer script. jQuery is ~14K minified +
gzipped.
[snip non-discussion]
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
David Mark
> On Oct 30, 3:09 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > What makes you think that modules developed for my own use would be
> > appropriate for somebody else?
>
> Do you think you are solving extremely unique problems?
>
Yes.
> > I think you misunderstand my intention. I have no plans to publish
> > the next free library. I might post some low-level functions, which
> > could be of interest to people who need a foundation to start their
> > own libraries.
>
> I assume you have assembled your low-level functions into high-level
> functionality at some point, so surely you have developed enough
> functionality to accomplish complex tasks. Why not post all the code
> you have - even if undocumented - as a great jump-start to anyone want
> to assemble those pieces into something they would find useful?
Why not stop badgering me to post all of my code and make do with what
I have posted to this point?
>
> > You just don't get it. There is no single library that is appropriate
> > for every task. That is what jQuery, Prototype, etc. try to be and
> > they fail miserably at it.
>
> I think you misjudge the intent. IMO, these libraries intend to be a
> solid framework that combine low-level reusable functions with an
> intuitive API. They don't try to solve every problem. They give the
> developer a different set of tools to use. Tools which are often more
> compact, easier to use, and provide good browser abstraction.
>
Provide good browser abstraction? What library are you talking about?
> Inserting jquery.js into a page will do nothing for you. It's just a
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.
> tool. You still need to write code.
>
> How is this approach any different from your own set of low-level
> functions? Libraries like jQuery just assemble the most often-used set
> of tools and give them a consistent API. In under 30k of code, you
For the love of God. It is not 30K of code. It is 50K. When served
compressed by a Web server, it will likely be about 30K. Using that
ridiculous packer tool does not improve on that at all. In fact, it
may make things worse. In any case, it is ridiculous and misleading
to call a 50K minified script 30K. What do you call a 50K image
asset? Do you GZIP it and then cite the compressed size? Wouldn't
that make it hard to compare to everything else on you server?
> have a large set of functionality that you know will always be
> available without having to piece together various functions to do
> exactly what you want. How is that bad?
>
> > And no, I am not interested in
> > publishing and supporting my codebase as a free library. Sorry.
>
> Which is ridiculous. So you have nothing to really offer anyone except
> bashing the solutions others are developing. Great approach!
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 suggest you stop crying for me to hand you every line of code I ever
wrote for free. I am not a charity for challenged JavaScript coders.
Matt Kruse
> > 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, 5:36 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > 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
> > 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, 5:34 pm, John Resig <jere...@gmail.com> wrote:
> > 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
> 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
Yehuda Katz
The reason we care about 20k vs. 50k when we typically could care less
about such small libraries (what's the size of the C standard
library?) is because the open web involves downloading files from
central servers over (sometimes) slow connections. As a result
*download* size is actually the relevant size.
When minified and gzipped, jQuery is 14k. That is the number of bytes
a browser will need to get from a remote server in order to use
jQuery. It ungzips the files using a native decompressor (as opposed
to the packer, which must be run in JavaScript), so the gzipping
doesn't have any noticeable performance impact. Minified/gzipped is
the correct metric when handling JS files, unless you can give me
another reason why we give a damn about the difference between 20k and
30k.
-- Yehuda Katz
Peter Michaux
>
> 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
David Mark
> Yawwwwnnnnn.... this is, quite possibly, the most inane set of
> ramblings set up by someone who has obviously never created a
> JavaScript library of any kind, nor has used JavaScript code in any
> sort of production environment.
Wrong on all counts.
>
> I'll reply to your alleged critiques to the code below.
>
> To start with, jQuery only supports the following browsers:
> - IE 6+
> - Firefox 2+
> - Opera 9
> - Safari 2+
Which is why it is amazing that it has to resort to browser sniffing.
Of course, it likely won't wory very well in say IE8, Opera 10,
Firefox 3, etc.
>
> Anything outside that jurisdiction is not guaranteed to work. But
> considering that that selection is something like 99% of all browsers
> (and considering that the selection of supported browsers is "good
> enough" for Google, Amazon, NBC, IBM, Oracle, etc. etc.) I think it's
Google as an example?! The worst JavaScript developers in history?
Same goes for Amazon. Whatever you support, you shouldn't have to
parse the userAgent string to support it. That was clear 10 years
ago. Where have you been?
> safe to say that we've made a good choice.
>
> > Hardly. It is woven into many important low-level functions. Here is
> > a particularly stupid snippet from the get/setAttribute wrapper called
> > attr:
>
> > } else if ( jQuery.browser.msie && name == "style" )
>
> > return jQuery.attr( elem.style, "cssText", value );
>
> > Do you have any idea how many agents jQuery will identify as IE?
>
> The ones we care about?
So your library is inappropriate for a site on the public Internet?
>
> > Do
> > you have any idea how trivial it is to properly feature detect IE's
> > broken get/setAttribute functionality?
>
> Pray tell! I must've missed the boolean property that tells me that
> it's broken as all get out.
You simply not thinking.
>
> > Forget that for the moment, why is this function passing a style
> > object to itself?
>
> The .attr() function can be a little futzy (it's long due for a
> rewrite). For now, it's written this way to keep all attribute/css
> special-case logic contained to a single location.
It is a crock any way you slice it.
>
> > if ( jQuery.browser.msie && /href|src/.test(name) && !
> > jQuery.isXMLDoc(elem) )
> > return elem.getAttribute( name, 2 );
>
> > Just what sort of XML document runs script in IE? Certainly not an
> > XHTML document. Realize that this absurd line of code is evaluated
> > every time jQuery looks at an element's attribute.
>
> Huh? That gets the interpreted value of an attribute, only in IE, and
> only if it isn't within an XML document (and only for the href and src
> attributes - which are the ones that have the specific URL-
> interpretation problems).
Just like I said. Every time through it is interpreted. You don't
"know" it is IE until you test that useless msie property. And the
question remains: what sort of XML document runs script in IE?
>
> > Then there is this gem:
>
> > // Certain attributes only work when accessed via the old DOM 0 way
> > if ( fix[name] ) {
> > if ( value != undefined ) elem[fix[name]] = value;
> > return elem[fix[name]];
>
> > This demonstrates a stunning lack of understanding of attributes (and
> > IE's problems with them.) Where's the sniff (or feature detect) for
> > IE? This IE-specific workaround runs on everything.
>
> This has nothing to do with being IE-specific, or not. Look at the fix
> object - it contains a number of properties (both CSS and regular
> attribute) that need to be re-written or defer to another attribute.
> (For example, this is also used to fix cases where a user
> types .attr("readonly") instead of .attr("readOnly")).
And that has everything to do with IE. The fact that you don't
realize that speaks volumes. Do you even understand what the problem
is with get/setAttribute in IE?
>
> > Still in the same function:
>
> > else if ( value == undefined && jQuery.browser.msie &&
> > jQuery.nodeName(elem, "form") && (name == "action" || name ==
> > "method") )
> > return elem.getAttributeNode(name).nodeValue;
>
> > No comment for this magic spell, so there is no telling what it is
> > trying to do.
>
> The action and method attributes can be overwritten in IE, like so:
> <form>
> <input type="text" id="action"/>
> </form>
>
> Thus, this code handles that case and gets the correct value, special.
Your magic spell is botched. Did it occur to you detect when
attributes are mistakenly treated as properties (hint #2 on that
subject) and then to test getAttributeNode before blindly inferring
its existence from a useless flag?
>
> > One thing is certain. This code will run on lots of
> > non-IE agents.
>
> It only runs on the ones that we care about - but apparently this
> mythical, ultra-popular, StrawMan v1.0 is all the rage these days.
What does that mean? There are hundreds of agents in use today that
identify as IE and any Website that uses your script will break them.
>
> > if ( value != undefined ) {
> > if ( name == "type" && jQuery.nodeName(elem,"input") &&
> > elem.parentNode )
> > throw "type property can't be changed";
> > elem.setAttribute( name, value );
> > }
>
> > Another example of confusing attributes with properties. This is also
> > an IE-specific workaround with no sniff (or feature detect.)
>
> This was done completely intentionally - we don't support dynamically
> changing the type attribute on input elements, since it causes an
> exception to be thrown in IE (we would rather have a consistent code
Read your code again. It causes an exception under some circumstances
and other problems under other circumstances. Your parentNode test is
incorrect. Try using that code to create a new radio button and you
will see what I mean.
> base, across all browsers that we support, than have problems arise
> later for users).
Oddly enough, I don't have any trouble setting the type attribute for
input elements, dynamically created or not. Of course, to do this you
have to go back and re-think your strategy concerning finding a
boolean flag that will alert you to IE's botched attribute handling.
>
> > And just when you think you have seen every conceivable miscue (all in
> > a single function mind you.)
>
> > if ( name == "opacity" && jQuery.browser.msie ) {
> > if ( value != undefined ) {
> > // IE has trouble with opacity if it does not have layout
> > // Force it by setting the zoom level
> > elem.zoom = 1;
>
> > What in God's name do opacity (and other styles) have to do with
> > attributes?
>
> See above.
See what above? A tangled mess?
>
> > That's enough of that function. Keep in mind that the code therein is
> > called constantly by jQuery. Unfortunately for those who rely on
> > jQuery, it is error-prone, confused, inefficient and convoluted.
>
> Error-prone? Doubtful. Where's your test suite-backed attribute/css
> manipulation code, I'd love to see it!
I bet you would. My test suite covers quite a few more agents than
yours. And of course, I don't have to worry too much about ones I
don't use or future revisions as I don't employ browser sniffing. See
how that works?
>
> Inefficient, possibly. We've already made a number of optimizations
> wherever possible - but many of the checks can't be circumvented.
The whole structure is rotten. It's only 80K. Why not tear it down
and rewrite it?
>
> Convoluted - sure. As I mentioned before, it's due for a re-write.
>
The whole thing, right?
> > The
> > design (and documentation) is of such poor quality that it is an
> > assault on the senses of anyone unfortunate enough to glance at it.
>
> Sigh. Where's your ultra-documented, totally-awesome, perfect-in-every-
> way JavaScript library? That's what I thought - you don't have one,
> nor does one exist.
That is the Matt Kruse school of baiting. I am not going to help you
rewrite your library any more than I already have. Sorry.
>
> > And speaking of opacity. In the curCSS function:
>
> > if (prop == "opacity" && jQuery.browser.msie) {
> > ret = jQuery.attr(elem.style, "opacity");
> > return ret == "" ? "1" : ret;
>
> > }
>
> > So any agent that identifies as IE and will be re-routed to the attr
> > function, which has nothing to do with style, but does contain more
> > sniffing and some IE-specific DirectX twiddling, which will have no
> > (positive) effect on non-IE agents.
>
> See above - it works for everything that we support. We make no
> illusions as to otherwise.
But many delusions as to why you need to support only five browsers
and why you need to sniff the userAgent string to do it.
>
> > It would seem that querying style rules would be almost as critical to
> > querying attributes in a library like jQuery. Yet, in this same
> > function you find this gem:
>
> > // A helper method for determining if an element's values are broken
> > function color(a){
> > if ( !jQuery.browser.safari )
> > return false;
>
> > var ret = document.defaultView.getComputedStyle(a,null);
> > return !ret || ret.getPropertyValue("color") == "";
>
> > }
>
> > This is the author's idea of a feature detect for getComputedStyle.
> > Why Safari-like browsers are excluded is a mystery. After that
> > inauspicious start, it blunders into the defaultView, getComputedStyle
> > and getPropertyValue properties with the impunity of somebody who
> > hasn't got a clue as to what they are doing.
>
> Wow. WowWowWow. Spoken like a true babe! It's damn simple to detect it
You come off as an idiot.
> in all browsers but Safari. In Safari 2, in an element that is
> display: none, getComputedStyle() returns null. In Safari 3, it
That problem is not limited to Safari.
> returns a style object, but within with all values return "" (which
Not in Windows Safari 3. Regardless, I was referring to something
else entirely. It looks like you do have a feature detect for
getComputedStyle, but the section of code is so convoluted that I
missed it. Adjusted score is about negative a million plus one.
Also, the handling of this issue is typically inept. You should never
try to query the computed style of an element that isn't part of the
layout. Barring (!important) user style sheet overrides, calling
programs should be aware when an element is part of the layout and
when it is not. All of those hoops you are going through to display
parentNodes (with an arbitrary rule no less) is a waste of time.
You've got much bigger and more important problems.
> may, or may not, be a valid return value - it's impossible to tell!).
> Thus, you have to check for the existence of the computed color value
> (which will always exist) and if it's empty, then we're inside a
> corrupted element.
>
> > It goes on and on. From the clean function:
>
> > if ( jQuery.browser.msie ) { // String was a <table>, *may* have
> > spurious <tbody>
> > if ( !s.indexOf("<table") && s.indexOf("<tbody") < 0 )
> > tb = div.firstChild && div.firstChild.childNodes;
>
> > div *may* have a firstChild property.
>
> Yes? Your point? IE can, sometimes, not auto-generate a <tbody>
You missed the point completely. The general theme is feature
detection (and the lack thereof.) I didn't spell everything out for
you as this was not a support request ticket. Look a couple of lines
down from that and find:
for ( var n = tb.length-1; n >= 0 ; --n )
This assumes that tb was actually set to something. What if the agent
had no firstChild property? Certainly many agents that identify as IE
fall into that category. Isn't this script supposed to make it easier
to build a Website? Seems odd that it is completely unsuitable for
the Internet.
> wrapper (when there's no contents to the table). This verifies when a
> <table></table> is passed in makes sure that a tbody is constructed.
> Again, everything here is backed by a test suite.
But even if it aces your limited tests, it is still unsuitable for
building Web applications. So what is it good for?
>
> > >From the same function:
>
> > // IE can't serialize <link> and <script> tags normally
> > jQuery.browser.msie && [1, "div<div>", "</div>"]
>
> > You have to keep in mind while reading this stuff that
> > jQuery.browser.msie is meaningless on the Web. It isn't of much use
> > on an Intranet either, unless you use the same version and
> > configuration of IE forever.
>
> Huh? Show me a drastically improved version of IE and I'll show you an
> updated copy of jQuery.
What does that mean? If you had written it right to begin with, you
wouldn't have to go back and rewrite it every time a new version is
released. And the other browsers you support are updated constantly.
Any way you slice it, people that rely on your code are actually
relying on you. That is a scary thought as you clearly don't know the
first thing about JavaScript, let alone browser scripting.
>
> > >From merge:
>
> > // Also, we need to make sure that the correct elements are being
> > returned
> > // (IE returns comment nodes in a '*' query)
> > if ( jQuery.browser.msie ) {
> > for ( var i = 0; second[i]; i++ )
> > if ( second[i].nodeType != 8 )
> > first.push(second[i]);
> > } else
>
> > Same problem different function. What if some agent that doesn't
> > identify as IE has the same problem?
>
> These browsers that you keep talking about must be amazing! They're,
> quite literally, everywhere! At every turn there's a browser that we
> support that also claims to be IE, but it isn't IE! What have we been
> doing wrong all this time? How could we have been so naive?
You read it backwards apparently. The point is that the problem may
exist in browsers that are NOT IE. Why make stupid assumptions? Here
is that portion of the code:
if ( jQuery.browser.msie ) {
for ( var i = 0; second[i]; i++ )
if ( second[i].nodeType != 8 )
first.push(second[i]);
} else
for ( var i = 0; second[i]; i++ )
first.push(second[i]);
What's wrong with that picture? I don't mean the missing brackets
that make it nearly impossible to follow and easy to foul up during
the inevitable maintenance.
>
> > Also note how hard it is to
> > follow with all of the missing brackets.
>
> *shrug*
That captures the essence of your code and comments perfectly.
>
> > More madness:
>
> > var styleFloat = jQuery.browser.msie ? "styleFloat" : "cssFloat";
>
> > Obviously you should just check (or set) them both. What happens if
> > IE8 switches gears on this? And what of an IE-spoofing agent that
> > doesn't use "styleFloat?"
>
> The same argument, over and over, is getting incredibly old. Where's
> your ultra-popular library that is 100% future proof?
The difference between you and me is that I don't give away code for
beer money donations. Get it? And I gave you the answer to that
one. So why not get rid of at least that one browser sniff. Do you
really need to peek at my style functions to do this?
>
> Considering that IE is going to be backwards compatible for, most
> likely, many many years to come, I'm not worried. When the year 2031
> arrives, jQuery can, and will adapt.
It is absurd to think the jQuery will be around even a few more years,
let alone decades.
>
> > // Check to see if the W3C box model is being used
> > boxModel: !jQuery.browser.msie || document.compatMode == "CSS1Compat",
>
> > That could have far-reaching implications. A quick search found it in
> > an attempt to measure the viewport:
>
> > return this[0] == window ?
> > jQuery.browser.safari && self["inner" + name] || jQuery.boxModel &&
> > Math.max(document.documentElement["client" + name],
> > document.body["client" + name]) ||
> > document.body["client" + name] :
> > this[0] == document ?
> > Math.max( document.body["scroll" + name], document.body["offset" +
> > name] ) :
> > h == undefined ?( this.length ? jQuery.css( this[0], n ) : null ) :
> > this.css( n, h.constructor == String ? h : h + "px" );
>
> > I characterized this as a "million monkey" project earlier and I want
> > to take a moment to apologize to monkeys everywhere. I think even a
> > single monkey could write a better solution to this very common
> > problem. Certainly there are many better solutions floating around on
> > the Internet.
>
> Certainly! They are, literally, everywhere! I mean, I can't go
> anywhere without tripping over a test-suite-backed, cross browser,
> quirksmode-handling, browser width and height detection script.
Idiot. I posted one here not three weeks ago. It was tested on
virtually everything, all the way back to IE5/NS6 and you can be sure
that the word "userAgent" does not appear in it. It is a good idea to
read the newsgroup and its FAQ (to quote another regular's sig.)
>
> Your "arguments" consist of nothing but assumptions dressed up as
> criticism.
I don't have to assume. I have dealt with all of the same problems
that you are stumbling over.
>
> > And boxmodel can also be observed in the positioning code:
>
> > // IE adds the HTML element's border, by default it is medium which is
> > 2px
> > // IE 6 and IE 7 quirks mode the border width is overwritable by the
> > following css html { border: 0; }
> > // IE 7 standards mode, the border is always 2px
> > if ( msie ) {
> > var border = jQuery("html").css("borderWidth");
> > border = (border == "medium" || jQuery.boxModel &&
> > parseInt(version) >= 7) && 2 || border;
> > add( -border, -border );
> > }
> > There are so many misconceptions here it is hard to know where to
> > begin. Suffice to say that the clientLeft/Top properties hold the
> > needed information in IE.
>
> Yes, we are well aware of the clientLeft/Top properties -
> unfortunately there are edge cases where they are not sufficient
> (especially when moving between standards and quirksmode).
Gibberish. If you had any idea what you were doing, you wouldn't make
patently false comments like:
"IE 7 standards mode, the border is always 2px"
Do you understand that in quirks mode there is no HTML element present
in the layout. That 2px (which is not always 2px) represents part of
the chrome. It has nothing to do with the border style of the HTML
element. You can give the HTML element a border of 200px and it will
have no affect on the layout and certainly no affect on positioning.
In quirks mode it is the BODY border that gets subtracted from the
coordinates returned by getBoundingClientRect. No magic spells are
needed when you understand what is going on. Edge cases indeed.
It is pretty clear that you don't know what you are doing, which is
why you shouldn't be doing it. Not in public anyway. The fact that
you are also snotty towards criticism comes as no surprise. Most
incompetents have the same attitude.
>
> You're definitely proving that it's much easier to make off-the-cuff
> criticisms than to actually provide working, tested, cross-browser
> solutions. All of which we've done, and supported, for almost 2 years
> now.
Working? Cross-browser? Hardly. If you tested, then why are you
still clueless about simple things like the effect of borders on
positioning? Try turning on HTML borders in any other of your
supported browsers and see what happens to your positioning tests.
Same goes for margins. BODY borders are more prevalent and will also
cause problems in some cases. From the above comment about "edge
cases" for "HTML borders" in quirks mode, it appears you never tested
those at all.
>
> > In the same function:
>
> > // Mozilla and Safari > 2 does not include the border on offset
> > parents
> > // However Mozilla adds the border for table cells
> > if ( mozilla && /^t[d|h]$/i.test(parent.tagName) || !safari2 )
> > border( offsetParent );
>
> > Apparently, in the jQuery universe there is only Opera, Mozilla,
> > Safari and IE. IE never gets here. Opera (and Safari <= 2 if you
> > believe the comments) adds borders when it shouldn't. So this logic
> > excludes everything the author has ever heard of that isn't Opera.
>
> Right. See above.
But you still don't see why the logic and comments are senseless?
Opera (and Safari 2) are the exceptions, not the rule. The "borders-
included-in-offsets" anomaly is easy enough to feature test.
Coincidentally, I have posted examples of it in the past. They
weren't posts about jQuery, so I guess you didn't read them. Every
time a new version of Opera or Mozilla (or whatever) comes out, you've
got a lot of re-testing and (possibly re-working) to do, which can
easily introduce new bugs, which leads to more re-testing, etc. Then
the dialog pops up telling you that Firefox has a new version and do
you still think this is a good strategy? Since all of your testing is
based on browser names, what exactly will you do when Opera fixes
their border problem? Add another flag based on the version number?
You mentioned something about 2035 (or some ridiculously far off year)
earlier. How long will jQuery's browser sniffing branches be by
then? It is a rhetorical question. Obviously it will have long since
gone the way of the dodo.
>
> > Speaking of Mozilla. Does this look like a good indication of Mozilla-
> > based browsers?
>
> > mozilla: /mozilla/.test(userAgent) && !/(compatible|
> > webkit)/.test(userAgent)
>
> > Why not call that the everything-under-the-sun property?
>
> Because it's not? It captures everything that we care about.
Does it indicate Mozilla? IE has spoofed Mozilla in its userAgent
string since the beginning. So is IE Mozilla? Or perhaps in the
various branches it never checks Mozilla unless it has branched away
from IE? Does any of this sound like good coding practice to you?
Variable that have meaningless names, strange twisting branches based
on a string of characters that has no relation to the terrain, adding
more branches every time a new browser version comes out, etc.? Why
would anybody do that? A better question is why would anybody rely on
somebody who does it (especially when the person refuses to listen to
the advice of those who know better.)
>
> > Getting back to border issue, in the mozilla-and-newer-Safari-only
> > (and oddly named) border function:
>
> > add( jQuery.css(elem, "borderLeftWidth"), jQuery.css(elem,
> > "borderTopWidth") );
>
> > What an outrage. The author apparently never heard of clientLeft/Top.
>
> See above.
LOL. I think you need to see above. More "edge cases?" You have got
to be kidding. To find the border of an element, you start with
clientLeft/Top. Computing styles is the last resort for browsers that
do not support clientLeft/Top. Considering how outrageously
inefficient your style wrappers are, you would be well advised to use
the clientLeft/Top properties when they are available.
>
> > Backing up to where boxModel was first spotted, this is deja vu:
>
> > styleFloat: jQuery.browser.msie ? "styleFloat" : "cssFloat",
>
> > Yes, this logic is repeated just three lines below the first instance.
>
> This was already fixed in SVN:http://dev.jquery.com/browser/trunk/jquery/src/core.js#L1180
>
It should have been fixed before it was released.
> > Moving on. In the ready function:
>
> > if ( jQuery.browser.mozilla || jQuery.browser.opera )
> > document.removeEventListener( "DOMContentLoaded", jQuery.ready,
> > false );
>
> > So if it is virtually any agent, assume there is a document object (a
> > fair assumption) and assume that it has a removeEventListener method
> > (an outrageous assumption.) Why the event listener needs to be
> > removed at all is another interesting question. The comments
> > mentioned memory leaks.
>
> Man, why am I not using this StrawMan browser? It is, apparently, used
> everywhere. Once again, if it's not in the 99% of all browsers that we
> support, we don't care.
You are deluded. You don't support anywhere near 99% of all
browsers. And whether you care is not the point. Who was talking to
you?
>
> We remove the event to be tidy - if we don't need to keep it bound,
> then there's no reason to waste any perfectly-good memory on it. I
> don't understand why this is an issue for you. Do you prefer that
> libraries keep everything bound indefinitely? Do you want them to have
> high overhead and run slow?
GC is automatic. Do you understand that a memory leak is an exception
to GC? Your comment indicated that you thought the event might leak.
What do you base that suspicion on? Do you automatically remove every
listener every time the page unloads, just in case it might cause a
memory leak?
>
> > Here is the flip-side of this in bindReady:
>
> > // If Mozilla is used
> > if ( jQuery.browser.mozilla || jQuery.browser.opera )
> > // Use the handy event callback
> > document.addEventListener( "DOMContentLoaded", jQuery.ready,
> > false );
>
> > So two of the four browsers that the author knows of are known to
> > support DOMContentLoaded. Of course, it wouldn't hurt to add this
> > listener for everything. Come to think of it, he did (unknowingly)
> > add it for virtually everything.
>
> Except for half the browsers - Safari and IE. Which is not "virtually
> everything".
Not IE? Are you sure? Last I checked, IE spoofed Mozilla. I think
it was about ten years ago. I doubt it has changed.
>
> > You've got to love the comments. "Use the handy event callback" may
> > be the least informative one yet. Here's another interesting one from
> > makeArray:
>
> > // Need to use typeof to fight Safari childNodes crashes
> > if ( typeof a != "array" )
> > for ( var i = 0, al = a.length; i < al; i++ )
> > r.push( a[i] );
> > else
> > r = a.slice( 0 );
>
> > And why would you pass an array to a "makeArray" function anyway?
>
> .makeArray() is designed to take any array-like object and return a
> clone of itself. Thus this will work for both NodeLists and regular
> arrays (for example). Note the key word there: clone - it doesn't
> return the original (hence it's only used for when an array needs to
> be cloned).
You should try coming up with logical names for your functions. You
notice you how had to explain what that function did?
Regardless, you can't see what is wrong with this line?
if ( typeof a != "array" )
What (in any JavaScript implementation) will evaulate that to false?
What is an array in JavaScript?
>
> > This reminds me of the function test code, which was blistered in
> > another recent "jQuery is a joke" thread.
>
> I assume that you're referring to jQuery.isFunction(). If you have a
> comparable method that's able to pass all of these tests in all modern
> browsers, let me know! I'll be happy to take a look.
We just went over this a few weeks ago. Search the group before
posting. It might help you avoid shooting yourself in the foot next
time.
>
> http://dev.jquery.com/browser/trunk/jquery/test/unit/core.js#L62
>
Test your own code.
> > Enough is enough. If you use jQuery after reading this, you are
> > deserve everything you get.
>
> Apparently, a thoroughly tested and comprehensively written JavaScript
> library - who knew?
Nobody knew that, though some thought they did.
>
> > 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.
Again with the Google and Amazon (and AOL?!) nonsense. Is that
supposed to be funny?
>
> > Really? Define packed. Minified it is roughly 50K. GZIP doesn't
> > enter into it (unless you can't comprehend why it is silly to compare
> > file sizes after compression.) How small would a 20K library be after
> > compression? Regardless, you shouldn't manually compress JavaScript
> > files.
>
> Run through Dean Edwards' Packer script. jQuery is ~14K minified +
> gzipped.
Which would imply that packer does a worse job than GZIP, so it should
not be used. And of course, GZIP doesn't factor into page weight
comparisons. The server might GZIP it, it might not. All things
equal, it is a 50K script minified.
>
> [snip non-discussion]
>
> So besides .attr() needing a rewrite (I fully admit that) - I see
> absolutely no valid criticism of the library - and if anything, a
You are blind. Others certainly did. Even the jQuery fanboy Matt
Kruse agreed with enough of it to open up tickets on your site. I
wondered where he got the idea that you knew better about some of this
stuff as I didn't realize you were nuts enough to actually post a
retort here. When I saw that Matt "re-printed" one of his earlier
responses to you, I couldn't believe my eyes. I knew it would be a
bunch of clueless nonsense, but this exceeded my expectations by far.
> 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.
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.
David Mark
No kidding.
> *download* size is actually the relevant size.
Not for easy comparison to other Web assets it isn't. You would have
to GZIP everything by hand to level the field and then measure. And
of cousse, compression is not guaranteed.
>
> When minified and gzipped, jQuery is 14k. That is the number of bytes
You just made my argument for me. Using Packer will slow things down.
> a browser will need to get from a remote server in order to use
> jQuery. It ungzips the files using a native decompressor (as opposed
> to the packer, which must be run in JavaScript), so the gzipping
No kidding. Another reason that nobody (sane) uses Packer.
> doesn't have any noticeable performance impact. Minified/gzipped is
> the correct metric when handling JS files, unless you can give me
> another reason why we give a damn about the difference between 20k and
> 30k.
What is 20K? The difference is between 14K and 50K. The former is
not useful for comparisons, unless you manually GZIP everything you
want to compare it to. Wouldn't that be particularly stupid when
comparing JavaScript files? They will all compress at roughly the
same rate (when and if compression has been successfully negotatied
during the request), so the ratios of the uncompressed versions will
be roughly equivalent to the ratios of the compressed versions.
Jeff North
<jer...@gmail.com>
<1193870076.6...@e34g2000pro.googlegroups.com> wrote:
[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 :-)
-- -------------------------------------------------------------
jnor...@yourpantsyahoo.com.au : Remove your pants to reply
-- -------------------------------------------------------------
Jeff North
<dmark....@gmail.com>
<1193897199.9...@y42g2000hsy.googlegroups.com> wrote:
>| On Oct 31, 6:34 pm, John Resig <jere...@gmail.com> wrote:
[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?
David Mark
> On Wed, 31 Oct 2007 23:06:39 -0700, in comp.lang.javascript David Mark
>
> <1193897199.997049.211...@y42g2000hsy.googlegroups.com> wrote:
> >| On Oct 31, 6:34 pm, John Resig <jere...@gmail.com> wrote:
>
> [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
> Google as an example?! The worst JavaScript developers in history?
> Same goes for Amazon.
I don't think you can dismiss the "big guys" so easily. These
companies are worth billions of dollars and they are doing it by using
a strategy that you say is terrible and will never work. Clearly, it
does work. When you can showcase the kind of success that these
companies have by using YOUR methodology, then maybe your criticisms
will have more weight.
> And the
> question remains: what sort of XML document runs script in IE?
XML can be returned by ajax calls and operated on.
> Oddly enough, I don't have any trouble setting the type attribute for
> input elements, dynamically created or not.
I'd be curious to see your code, as I've never gotten it to work in
IE. Always had to resort to creating a new input of the new type and
removing the old.
> I bet you would. My test suite covers quite a few more agents than
> yours.
Code you post your test suite, or give a url? If you have test cases
that break other libraries or functions, it would be great to make
them available. And you wouldn't even need to share your precious
code.
> You read it backwards apparently. The point is that the problem may
> exist in browsers that are NOT IE. Why make stupid assumptions? Here
> is that portion of the code:
> if ( jQuery.browser.msie ) {
> for ( var i = 0; second[i]; i++ )
> if ( second[i].nodeType != 8 )
> first.push(second[i]);} else
>
> for ( var i = 0; second[i]; i++ )
> first.push(second[i]);
> What's wrong with that picture?
Wow, I hadn't looked at that portion of the code yet. Things like that
certainly concern me.
> The difference between you and me is that I don't give away code for
> beer money donations.
You should. Free beer is fantastic.
> I don't have to assume. I have dealt with all of the same problems
> that you are stumbling over.
And solved them, presumably? And then locked those awesome solutions
up in the closet so no one else can benefit from them?
I think publicly-available code with some problems is more valuable
than robust, "perfect" code that is locked away. The public code will
be inspected, torn apart, improved, and re-thought on a regular basis.
It will evolve into the best solution. The code kept private will rot
and not benefit from public criticism and improvements. So, while your
code may be "better" than that in jQuery, it is of no use to anyone
but yourself, so I'm not sure why you keep mentioning it.
> Does it indicate Mozilla? IE has spoofed Mozilla in its userAgent
> string since the beginning. So is IE Mozilla?
jQuery correctly identifies IE as IE, not Mozilla.
> GC is automatic. Do you understand that a memory leak is an exception
> to GC? Your comment indicated that you thought the event might leak.
> What do you base that suspicion on? Do you automatically remove every
> listener every time the page unloads, just in case it might cause a
> memory leak?
Memory leaks are a complex issue, especially in IE. I'm not sure if
you're aware of every possible leak scenario, but I know I'm not.
There are ridiculous leak scenarios that don't even involve closures
or circular references or events. Removing event listeners in this
case may not be required to avoid leaks, but it's perhaps a safe,
conservative practice.
> if ( typeof a != "array" )
> What (in any JavaScript implementation) will evaulate that to false?
> What is an array in JavaScript?
I hope someone somewhere is blushing.
> You are blind. Others certainly did. Even the jQuery fanboy Matt
> Kruse agreed with enough of it to open up tickets on your site.
I didn't actually open tickets, I just started a discussion.
FYI, some of your criticisms are certainly valid, and I posted your
entire original post to the jQuery dev list. I also followed up with
my own post below that goes into detail on the attr() function. You
are welcome to critique my critiques. I already see a few places that
my suggestions could be improved.
=== Begin Copied Post From jQuery-Dev ===
On Oct 30, 10:18 pm, Matt <m...@mattkruse.com> wrote:
> I haven't had time yet to look into the code in detail, but I will do
> so in the next few weeks.
I took a look at the 'attr' function today and here are my comments.
I'm not going to open a ticket for specific items, but I'd like to
hear some feedback. If these types of comments are helpful I will
continue looking at the code and making suggestions. If I am way off
base, then I'll just be quiet ;)
I've copied the entire attr() function from the nightly build below
and added comments:
> attr: function( elem, name, value ) {
> var fix = jQuery.isXMLDoc( elem ) ?
> {} :
> jQuery.props;
> // Safari mis-reports the default selected property of a hidden option
> // Accessing the parent's selectedIndex property fixes it
> if ( name == "selected" && jQuery.browser.safari )
> elem.parentNode.selectedIndex;
Why even do the name and browser check? Surely no browser will choke
on simply accessing the selectedIndex property. Just do it blindly.
> // Certain attributes only work when accessed via the old DOM 0 way
> if ( fix[ name ] ) {
> if ( value != undefined )
> elem[ fix[ name ] ] = value;
> return elem[ fix[ name ] ];
> } else if ( jQuery.browser.msie && name == "style" )
> return jQuery.attr( elem.style, "cssText", value );
> else if ( value == undefined && jQuery.browser.msie && jQuery.nodeName( elem, "form" ) && (name == "action" || name == "method") )
> return elem.getAttributeNode( name ).nodeValue;
If you're going to include this fix for 'action' and 'method' then why
not also for 'accept','enctype','name','target', etc?
And why restrict it only to IE? In fact, why even use getAttribute()?
Why not just use elem.getAttributeNode( name ).nodeValue for all node
values in all browsers?
(I've not researched that one, so there is a potential that fails in
some browsers)
You could also just do a general fix in the code below... (Marked #1)
> // IE elem.getAttribute passes even for style
> else if ( elem.tagName ) {
> if ( value != undefined ) {
> // We can't allow the type property to be changed (since it causes problems in IE)
> if ( name == "type" && jQuery.nodeName( elem, "input" ) && elem.parentNode )
> throw "type property can't be changed";
Do other browsers allow it? Why fail for all browsers, if only IE has
a problem?
> elem.setAttribute( name, value );
Now, what if I am setting the 'action' attribute of a form that has an
input with name 'action'? It will safely get to this block in IE and
fail to set the attribute. You've handled this case for getting the
value, but not setting. Calling form.attr('action','val') in this case
will not set the action attribute in IE.
> }
> if ( jQuery.browser.msie && /href|src/.test( name ) && !jQuery.isXMLDoc( elem ) )
> return elem.getAttribute( name, 2 );
What harm would there be in always passing a '2' to this call in all
browsers? Browsers other than IE would ignore it, and IE would always
use it to return the actual node value. Why not get rid of the browser
check and condition and just call it blindly?
In this specific case, I see that IE has a problem with passing '2' in
the case above where we are trying to get the 'action' attribute. But
the fix below avoids that. The general point is, why only limit things
like this to a browser-sniffed IE, when it wouldn't hurt to apply the
same fix for every browser?
> return elem.getAttribute( name );
Here you could put in a general fix (#1) that would do away with the
special case handling above:
var v = elem.getAttribute(name);
return ((v && v.tagName)?
elem.getAttributeNode(name).nodeValue:elem.getAttribute(name,2));
This seems to cover all cases, doesn't it? If future cases are found
where certain attributes are 'masked' by returning elements, the case
will automatically be handled. And it's not limited to any specific
browser.
I haven't tested anything other than IE, but I would be interested to
hear if it causes any problems.
> // elem is actually elem.style ... set the style
I don't understand why opacity, filter, etc are even considered
attributes.
> } else {
> // IE actually uses filters for opacity
> if ( name == "opacity" && jQuery.browser.msie ) {
Will it ever even get here if it's not IE?
> if ( value != undefined ) {
> // IE has trouble with opacity if it does not have layout
> // Force it by setting the zoom level
> elem.zoom = 1;
> // Set the alpha filter to set the opacity
> elem.filter = (elem.filter || "").replace( /alpha\([^)]*\)/, "" ) +
> (parseFloat( value ).toString() == "NaN" ? "" : "alpha(opacity=" + value * 100 + ")");
> }
> return elem.filter ?
> (parseFloat( elem.filter.match(/opacity=([^)]*)/)[1] ) / 100).toString() :
> "";
> }
> name = name.replace(/-([a-z])/ig, function(all, letter){
> return letter.toUpperCase();
> });
> if ( value != undefined )
> elem[ name ] = value;
> return elem[ name ];
> }
> }
I hope these comments make sense!
Matt Kruse
David Mark
> On Nov 1, 1:06 am, David Mark <dmark.cins...@gmail.com> wrote:
>
> > Google as an example?! The worst JavaScript developers in history?
> > Same goes for Amazon.
>
> I don't think you can dismiss the "big guys" so easily. These
Why not? Their Websites throw lots of script errors, degrade poorly,
etc.
> companies are worth billions of dollars and they are doing it by using
How much they are worth has no bearing to the discussion. Their
scripts are still incompetently written. Stock market analysts are in
no position to judge the quality of these sites. Those who are
invariably agree that they are junk. Your argument sounds like: "if
Google is incompetent and makes lots of money, then I should follow
their lead and I will make lots of money."
> a strategy that you say is terrible and will never work. Clearly, it
Everything is relative. Perhaps they would make more money with
competent developers. Or perhaps hiring better developers would eat
into their TV advertising budget. There are too many variables to
make a correlation between Website quality and the bottom-line bean
counting of a massive multinational concern.
> does work. When you can showcase the kind of success that these
> companies have by using YOUR methodology, then maybe your criticisms
How do you know what I have "showcased." Do you have any idea what I
do or who I do it for?
> will have more weight.
They have all the weight they need in relation to the current
discussion. On the contrary, babbling about Google lends no weight to
your "arguments" at all.
>
> > And the
> > question remains: what sort of XML document runs script in IE?
>
> XML can be returned by ajax calls and operated on.
And you really think that the jQuery attr function is appropriate for
manipulating XML results? I can tell you that it is not. Certainly
not in IE. jQuery doesn't even work with XHTML unless it is served as
tag soup HTML.
>
> > Oddly enough, I don't have any trouble setting the type attribute for
> > input elements, dynamically created or not.
>
> I'd be curious to see your code, as I've never gotten it to work in
> IE. Always had to resort to creating a new input of the new type and
> removing the old.
I'm sure you would. Why would you ever need to change the type of an
extant input element? Nevertheless, if you poke around the Web with
your favorite search engine, you should be able to find the answer
quickly. First things first, you have to detect the broken IE get/
setAttribute implementation or you won't know when you need this
specific workaround. That is important as the method required to fix
it is proprietary to IE. Once you find the method I am referring to,
do not feature detect it and infer that attribute handling is broken
(and certainly do not infer anything from the userAgent string.) If
you understand what IE is doing wrong and look at the various
workarounds posted, you should be able to come up with the same answer
I did.
>
> > I bet you would. My test suite covers quite a few more agents than
> > yours.
>
> Code you post your test suite, or give a url? If you have test cases
> that break other libraries or functions, it would be great to make
I don't know what that means. My test "suite" (a page actually) calls
functions in my code. It is worthless for testing other libraries.
And as for those, I think I gave you enough on the one you recommend
(and apparently use) from the code snippets I posted. Why do you need
to test what is obviously broken?
> them available. And you wouldn't even need to share your precious
> code.
You really don't help yourself do you?
>
> > You read it backwards apparently. The point is that the problem may
> > exist in browsers that are NOT IE. Why make stupid assumptions? Here
> > is that portion of the code:
> > if ( jQuery.browser.msie ) {
> > for ( var i = 0; second[i]; i++ )
> > if ( second[i].nodeType != 8 )
> > first.push(second[i]);} else
>
> > for ( var i = 0; second[i]; i++ )
> > first.push(second[i]);
> > What's wrong with that picture?
>
> Wow, I hadn't looked at that portion of the code yet. Things like that
> certainly concern me.
As well they should. No need to thank me.
>
> > The difference between you and me is that I don't give away code for
> > beer money donations.
>
> You should. Free beer is fantastic.
Whatever.
>
> > I don't have to assume. I have dealt with all of the same problems
> > that you are stumbling over.
>
> And solved them, presumably? And then locked those awesome solutions
> up in the closet so no one else can benefit from them?
That would seem a good presumption, otherwise I wouldn't know that the
code in jQuery is wrong. And I don't really care if you (or your
clients) benefit from my work. You might as well stop badgering me.
If you have a specific question, post it. Maybe I will take the time
to answer it and maybe I won't. It depends on the scope of the
question, how you ask it, if you can demonstrate that you have tried
to solve it yourself, etc.
>
> I think publicly-available code with some problems is more valuable
> than robust, "perfect" code that is locked away. The public code will
> be inspected, torn apart, improved, and re-thought on a regular basis.
Inspected, torn apart and improved by whom? Tearing apart jQuery here
didn't seem to light fire under its author. On the contrary, his
argument seemed to be that because so many people us it, it must be
great.
> It will evolve into the best solution. The code kept private will rot
> and not benefit from public criticism and improvements. So, while your
I constantly post code here in hopes of getting criticism. And I
constantly make improvements. But why would you care? Oh, because
you want to bait me into making you a Beta tester or something. Good
luck. I don't need your help.
> code may be "better" than that in jQuery, it is of no use to anyone
> but yourself, so I'm not sure why you keep mentioning it.
I don't. You keep mentioning it.
>
> > Does it indicate Mozilla? IE has spoofed Mozilla in its userAgent
> > string since the beginning. So is IE Mozilla?
>
> jQuery correctly identifies IE as IE, not Mozilla.
jQuery doesn't identify anything as anything. It sets flags that are
not mutually exclusive. Have a look at the regex that sets the
"mozilla" flag.
>
> > GC is automatic. Do you understand that a memory leak is an exception
> > to GC? Your comment indicated that you thought the event might leak.
> > What do you base that suspicion on? Do you automatically remove every
> > listener every time the page unloads, just in case it might cause a
> > memory leak?
>
> Memory leaks are a complex issue, especially in IE. I'm not sure if
> you're aware of every possible leak scenario, but I know I'm not.
Nobody but IE's developers could be aware of every leak scenario. And
they probably don't either. Interestingly enough, the specific leak
issue referred to had nothing to do with IE.
> There are ridiculous leak scenarios that don't even involve closures
Yes there are. In IE and other browsers.
> or circular references or events. Removing event listeners in this
> case may not be required to avoid leaks, but it's perhaps a safe,
> conservative practice.
So you would remove every event handler on every page unload?
Regardless, that is not what the line in question did.
>
> > if ( typeof a != "array" )
> > What (in any JavaScript implementation) will evaulate that to false?
> > What is an array in JavaScript?
>
> I hope someone somewhere is blushing.
Especially since that is the second time I posted that snippet in this
thread. What followed was pure bluster and indicates that the author
didn't read what I posted at all.
>
> > You are blind. Others certainly did. Even the jQuery fanboy Matt
> > Kruse agreed with enough of it to open up tickets on your site.
>
> I didn't actually open tickets, I just started a discussion.
Good for you. Seriously. I'm glad you found my comments helpful and
did something positive in response.
>
> FYI, some of your criticisms are certainly valid, and I posted your
> entire original post to the jQuery dev list. I also followed up with
Great.
> my own post below that goes into detail on the attr() function. You
> are welcome to critique my critiques. I already see a few places that
> my suggestions could be improved.
>
I really don't have time right now. It would be a good idea not to
waste any more of my time with silly arguments and badgering.
>
> read more »
I really hate Google. Never mind. I have had enough of this
discussion anyway.
Matt Kruse
> > I don't think you can dismiss the "big guys" so easily. These
> Why not? Their Websites throw lots of script errors, degrade poorly,
> etc.
> > companies are worth billions of dollars and they are doing it by using
> How much they are worth has no bearing to the discussion. Their
> scripts are still incompetently written. Stock market analysts are in
> no position to judge the quality of these sites.
If you are looking purely from a technical javascript standpoint, I
understand.
But that's not what most people care about. The more important issue
is the big picture. Great javascript code is not the end goal for most
people - business decisions are. And if Google et al can build a
successful business using the strategy that you despise, by writing
code that you think is junk, then how can you blame others for doing
the same?
Obviously, using general-purpose libraries that are not up to your
standards on the public internet does not hold back these companies
from reaching their goals. If someone else comes in here asking about
which libraries to use to solve problems or to increase the
productivity of their team, they are probably thinking in the same
way. A perfect library that stands up to all criticisms would be
fantastic, but a well-documented, well-supported, well-tested library
that does most things right and can quickly reap rewards and help
reach the business goals is better than nothing.
When you consider all the factors that most people are dealing with,
using libraries like jQuery makes an awful lot of sense. If you ONLY
consider the pure coding quality of the underlying javascript, then
keeping your own set of "bullet-proof" libraries and reusable
functions might make the most sense. Most people, IMO, are interested
in the former. Many people in this group are interested in the latter.
Thus, the conflict.
> > I'd be curious to see your code, as I've never gotten it to work in
> > IE. Always had to resort to creating a new input of the new type and
> > removing the old.
> I'm sure you would.
I would very much. Would you share it?
> Why would you ever need to change the type of an
> extant input element?
There are some situations where I've wanted to do it. It would be hard
to explain. But it's irrelevant.
> Nevertheless, if you poke around the Web with
> your favorite search engine, you should be able to find the answer
> quickly.
I haven't been able to find a solution. Have you?
> Good for you. Seriously. I'm glad you found my comments helpful and
> did something positive in response.
My goal is to improve the tools that I and other developers use. I
have no emotional attachment to jQuery or any code. If real criticisms
and suggestions are raised, I want to address them. If they aren't
addressed by the jQuery team (I assume they will be), I'll consider
branching my own version of jQuery or something. I don't know.
Matt Kruse
David Mark
> On Nov 1, 12:15 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > I don't think you can dismiss the "big guys" so easily. These
> > Why not? Their Websites throw lots of script errors, degrade poorly,
> > etc.
> > > companies are worth billions of dollars and they are doing it by using
> > How much they are worth has no bearing to the discussion. Their
> > scripts are still incompetently written. Stock market analysts are in
> > no position to judge the quality of these sites.
>
> If you are looking purely from a technical javascript standpoint, I
> understand.
>
> But that's not what most people care about. The more important issue
> is the big picture. Great javascript code is not the end goal for most
> people - business decisions are. And if Google et al can build a
> successful business using the strategy that you despise, by writing
> code that you think is junk, then how can you blame others for doing
> the same?
I don't blame anybody for anything. I just offer advice.
>
> Obviously, using general-purpose libraries that are not up to your
> standards on the public internet does not hold back these companies
> from reaching their goals. If someone else comes in here asking about
If they were competent, perhaps they could set their goals higher. Or
maybe it wouldn't matter to the bottom line of a huge corporation.
What works for a huge corporation isn't necessarily going to translate
into success for Joe Webmaster.
> which libraries to use to solve problems or to increase the
> productivity of their team, they are probably thinking in the same
> way. A perfect library that stands up to all criticisms would be
> fantastic, but a well-documented, well-supported, well-tested library
> that does most things right and can quickly reap rewards and help
Does what things right? I still contend that the library in question
is not exactly huge or all-encompassing. The time it takes to learn
it and deal with all of the issues from the 15% (or so) or users who
will not be able to use the resulting projects could be spent
learning. For instance, learning the difference between attributes
and DOM properties and how IE mixes up the two.
> reach the business goals is better than nothing.
>
> When you consider all the factors that most people are dealing with,
> using libraries like jQuery makes an awful lot of sense. If you ONLY
Not for a public Website it doesn't. I thought Peter's comments
concerning expected rates of failure and the ramifications of those
failures was a good explanation of why it doesn't make sense at all
(unless the goal is abject failure.)
> consider the pure coding quality of the underlying javascript, then
> keeping your own set of "bullet-proof" libraries and reusable
Nothing is "bullet-proof." How you deal with the bullets that get
through is what is important. The author(s) of jQuery apparently deal
with them by shrugging.
> functions might make the most sense. Most people, IMO, are interested
> in the former. Many people in this group are interested in the latter.
I am very quickly losing interest in any sort of discussion regarding
jQuery, Prototype, Dojo, etc. Use whatever you want. It won't bother
me a bit. Just don't expect to encourage others to follow suit
without hearing dissenting opinions.
> Thus, the conflict.
>
> > > I'd be curious to see your code, as I've never gotten it to work in
> > > IE. Always had to resort to creating a new input of the new type and
> > > removing the old.
> > I'm sure you would.
>
> I would very much. Would you share it?
You would have been better off asking me that about twenty posts ago.
>
> > Why would you ever need to change the type of an
> > extant input element?
>
> There are some situations where I've wanted to do it. It would be hard
> to explain. But it's irrelevant.
Certainly. I don't need to do it. But I did need to create radio
buttons on the fly, so I ran into the problem. It isn't relegated to
nodes in the document, or even nodes with parents. The problem is
with IE's handling of the name attribute.
>
> > Nevertheless, if you poke around the Web with
> > your favorite search engine, you should be able to find the answer
> > quickly.
>
> I haven't been able to find a solution. Have you?
I found a partial solution posted on some blog and had to spend some
time to perfect it for all cases. As I understand it, you are asking
about a specific case (changing types of elements in the document
tree) and I gave you several hints as to how to do that.
Unfortunately, you snipped them. Try googling for "IE setAttribute
type name outerHTML." But you still need to detect the problem before
you can implement the solution. Here is another hint:
Assuming el is an element object and has a getAttribute method, what
will this evaluate to in standards-based browsers?
el.getAttribute('style') && typeof(el.getAttribute('style')) ==
'object'
If it doesn't have a style attribute, it the first test will return
null and the second test is not evaluated. If it does have one, the
second test will return false. So in standards-based browsers, the
conjunction is always false.
Now consider current and past (broken) versions of IE which doesn't
know what attributes are (it thinks they are properties of the element
object.) Regardless of whether the element has a style attribute, it
has a style property which is an non-null object, so the first test
always passes. Obviously the second test is always evaluated for IE
and always true. Therefore, the conjunction is always true.
So there you have it. A boolean result that is guaranteed to tell you
when an implementation has broken attribute handling. Furthermore, it
does not harm future versions that will (hopefully) fix the problem.
Use that on an arbitrary element (I use the HTML element) during
feature detection and you only have to apply fixes for browsers that
are actually broken. The rest of them use get/setAttribute as normal.
And you should realize that this test does not directly indicate when
there will be a problem regarding the name and type attributes. That
is an inference (though a very good one) and you still need to detect
outerHTML support to work around those issues. You should also
realize at this point that this test does indicate specific problems
that can arise when confusing attributes and properties. For
instance, what do you suppose these will do in IE?
el.setAttribute('style', 'color:red');
el.setAttribute('onclick', 'alert("jQuery forgot to fix this");');
el.setAttribute('disabled', 'disabled'); // This too
el.setAttribute('checked', 'checked'); // And this
Now that you understand the problem, you can properly address it.
That's all the help I will give you on this. Perhaps if you had
posted the question first instead of running off at the mouth, I would
have helped you more.
>
> > Good for you. Seriously. I'm glad you found my comments helpful and
> > did something positive in response.
>
> My goal is to improve the tools that I and other developers use. I
Good.
> have no emotional attachment to jQuery or any code. If real criticisms
You would seem in the minority among jQuery users.
> and suggestions are raised, I want to address them. If they aren't
> addressed by the jQuery team (I assume they will be), I'll consider
> branching my own version of jQuery or something. I don't know.
Why expend effort to salvage an obvious derelict. Face it, you were
fooled into thinking you had a magic bullet, but it was really a time
bomb. The mad bombers who built it just shrugs off valid criticism.
The criticism will likely get more heated as more devices are
introduced with embedded browsers and they will likely continue to
chant "we don't care about anything but IE7, Opera 9, etc." Their
attitude does not indicate that they will switch gears to keep up with
the times and they are therefore doomed to end up an obscure footnote
in the history of browser scripting. Never mind the author's delusion
about remaining relevant for decades to come.
I haven't looked much at your toolkits, but why don't you concentrate
on building those up. It would make more sense to work with code you
are already familiar with. Attribute handling would seem a good
starting point.
Matt Kruse
> > > Why would you ever need to change the type of an
> > > extant input element?
> > There are some situations where I've wanted to do it. It would be hard
> > to explain. But it's irrelevant.
> Certainly. I don't need to do it. But I did need to create radio
> buttons on the fly, so I ran into the problem. It isn't relegated to
> nodes in the document, or even nodes with parents. The problem is
> with IE's handling of the name attribute.
Most experienced developers have run into this problem at some point,
but this has nothing to do with changing the 'type' of an element.
> > I haven't been able to find a solution. Have you?
> I found a partial solution posted on some blog and had to spend some
> time to perfect it for all cases. As I understand it, you are asking
> about a specific case (changing types of elements in the document
> tree) and I gave you several hints as to how to do that.
> Unfortunately, you snipped them. Try googling for "IE setAttribute
> type name outerHTML."
Either you are misunderstanding the problem or you have never actually
experienced and fixed it. I still cannot find a single solution for
changing the type of an input element in IE. And I'm a fairly good
googler.
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
object. And it has problems of its own.
> Here is another hint:
I'm not stupid - your "hints" are nothing insightful. and they don't
even begin to address the problem. It's not about bugs in setAttribute
in IE, it's about the fact that IE just doesn't want to let you change
an input's type.
> Perhaps if you had
> posted the question first instead of running off at the mouth, I would
> have helped you more.
I'm not sure you _can_ actually be more helpful. You continue claiming
that you have all these solutions, yet you never post any of them.
Instead you give "hints" and say "search the web" and "if you had read
my posts before" etc. I'm still not convinced that you actually can
write the code that you claim to be able to. Not that I really care.
> Why expend effort to salvage an obvious derelict. Face it, you were
> fooled into thinking you had a magic bullet, but it was really a time
> bomb.
Not at all. I like the API. I like the approach. I like the
compactness. I like the plugins. I like the community. I was aware of
some problems in the code before I decided to begin using it. I think
it has the best chance of quickly improving and becoming exactly what
I want. And it does a damn fine job for everything I'm using it for at
the moment.
> I haven't looked much at your toolkits, but why don't you concentrate
> on building those up.
I'd love to. Unfortunately with a wife and kids and dogs, etc, my free
time is almost nil! The days of working on my own projects for hours
at a time are long gone. Some of the code in those libs is old and
quite rusty. Some of it (like the table sorting) is newer and I
believe I solve some very tricky problems that others don't even
tackle (rowspan, colspan, etc). I always keep meaning to get back to
it...
But in a business development environment, I need to hand off tools to
other teams of developers and tell them what to use. I need javascript
tools that are documented in detail, supported with a user community,
preferrably with a printed book about them, and with a consistent and
logical API. Just having these things is such a huge improvement over
patching together various functions and utilities that the minor code
problems that exist don't really bother me much.
Matt Kruse
David Mark
> On Nov 1, 2:05 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > > Why would you ever need to change the type of an
> > > > extant input element?
> > > There are some situations where I've wanted to do it. It would be hard
> > > to explain. But it's irrelevant.
> > Certainly. I don't need to do it. But I did need to create radio
> > buttons on the fly, so I ran into the problem. It isn't relegated to
> > nodes in the document, or even nodes with parents. The problem is
> > with IE's handling of the name attribute.
>
> Most experienced developers have run into this problem at some point,
> but this has nothing to do with changing the 'type' of an element.
Actually it does. When you create an input element, it starts off as
a text element. You have to change its type to create a radio
button. If you don't do it exactly right, you will get a non-working
radio button. I assume as an "experienced developer" you have already
figured out how to do this, so I won't elaborate.
>
> > > I haven't been able to find a solution. Have you?
> > I found a partial solution posted on some blog and had to spend some
> > time to perfect it for all cases. As I understand it, you are asking
> > about a specific case (changing types of elements in the document
> > tree) and I gave you several hints as to how to do that.
> > Unfortunately, you snipped them. Try googling for "IE setAttribute
> > type name outerHTML."
>
> Either you are misunderstanding the problem or you have never actually
> experienced and fixed it. I still cannot find a single solution for
> changing the type of an input element in IE. And I'm a fairly good
> googler.
You must be a lousy "Googler." The first hit that comes up has most
of the answers you seek.
>
> 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. Assuming you actually
need to magically change the type of an existing element. Yes, it
invalidates any object references.
> object. And it has problems of its own.
I am well aware of the problems. The blog solution I found was
incomplete. It took me hours of tinkering to get it right. In the
end, the fix for changing existing input elements led to the fix for
newly created radio buttons. All of it was either directly or
indirectly caused by IE's attribute woes. Not unsurprisingly, other
browsers, which treat attributes as attributes, do not share any of
these problems. That is why the feature detect I gave you is the
perfect branching indicator.
>
> > Here is another hint:
>
> I'm not stupid - your "hints" are nothing insightful. and they don't
> even begin to address the problem. It's not about bugs in setAttribute
> in IE, it's about the fact that IE just doesn't want to let you change
It has everything to do with bugs in setAttribute in IE. What you
fail to understand is that those very bugs are what lead you to have
to set properties instead of attributes. Is that not clear at this
point?
> an input's type.
>
> > Perhaps if you had
> > posted the question first instead of running off at the mouth, I would
> > have helped you more.
>
> I'm not sure you _can_ actually be more helpful. You continue claiming
> that you have all these solutions, yet you never post any of them.
I all but gave you the solution in the last post. Not just to the
specific type/name problem, but to the entire IE get/setAttribute
issue. Whether you are playing dumb or actually are dumb is unclear
to me. Either way, I couldn't care less at this point.
Peter Michaux
> On Nov 1, 2:05 pm, David Mark <dmark.cins...@gmail.com> wrote:
> > I haven't looked much at your toolkits, but why don't you concentrate
> > on building those up.
>
> I'd love to. Unfortunately with a wife and kids and dogs, etc, my free
> time is almost nil! The days of working on my own projects for hours
> at a time are long gone.
What about life priorities, man?! When you are lying on your death
bed, won't you have regrets? ;-)
> But in a business development environment, I need to hand off tools to
> other teams of developers and tell them what to use. I need javascript
> tools that are documented in detail, supported with a user community,
> preferrably with a printed book about them, and with a consistent and
> logical API. Just having these things is such a huge improvement over
> patching together various functions and utilities that the minor code
> problems that exist don't really bother me much.
I agree with your sentiment here. It is very pragmatic for a business
environment. A English teacher of mine once said "A job worth doing is
worth doing poorly." This is sometimes true in business. The overall
profit of using a library like jQuery may be higher than starting from
scratch or cobbling bits and pieces together. The majority of
developers are punching the clock and things just won't ever be
released if a library like jQuery is not used.
However...
I think the utility of comp.lang.javascript would be sorely degraded
if it was ok to say "Well, that's good enough. I need to get some work
done." There are so many online communities where that is the case it
is good there is at least one where technical correctness is
paramount. I do think comp.lang.javascript's collective knowledge
should be better harnessed. Perhaps we should do something about
that.
Good to see you posting again, Matt.
Peter
Evertjan.
> Actually it does. When you create an input element, it starts off as
> a text element. You have to change its type to create a radio
> button. If you don't do it exactly right, you will get a non-working
> radio button. I assume as an "experienced developer" you have already
> figured out how to do this, so I won't elaborate.
>
"TYPE Attribute | type Property
Retrieves or initially sets the type of input control represented by the
object.
As of Microsoft Internet Explorer 5, the type property is read/write-once,
but only when an input element is created with the createElement method and
before it is added to the document."
<http://msdn2.microsoft.com/en-us/library/ms534700.aspx>
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
David Mark
That's Microsoft's general explanation of that attribute/property
(which they think are the same thing), but it doesn't touch on the
issues relating to the creation of radio buttons, which are related to
both the type and name attributes (and affect elements created with
createElement.) As is typical with them, the implementation doesn't
quite match the explanation.
Richard Cornford
> Yawwwwnnnnn.... this is, quite possibly, the most inane
> set of ramblings set up by someone who has obviously
> never created a JavaScript library of any kind,
> perfect-in-every- way JavaScript library? That's what I
> thought - you don't have one, nor does one exist.
> The same argument, over and over, is getting incredibly
> old. Where's your ultra-popular library that is 100%
> future proof?
"The same argument, over and over"?
So how does this work then? I cannot validly criticise dojo's authors
for demonstrating an ignorance of fundamental aspects of javascript
until after I have created something that resembles dojo (or at
least some form of "ultra-documented", "totally-awesome",
"perfect-in-every- way", "ultra-popular", "future proof" general
javascript library)? The implication being that this act is the only
pertinent qualification when judging javascript, and that my knowing
that by type-converting comparison the values undefined and null both
equal null and that no others do leaves me less qualified to judge
dojo than the people who wrote it in a way that demonstrated their
ignorance of that fact.
It doesn't really work as an argument. And if it were valid it would
raise many questions. The first would be why are there not (and never
have been) more of these things than there are? Over the years I
have knows a fair number of individuals who pretty much know
javascript and browser scripting inside out, and there must be
thousands who would never make the logical mistakes demonstrated in
dojo, so where are all of their general javascript libraries?
The next question would be; if creating these libraries is itself
the qualification why does the current set of half a dozen or so
contenders include so much code that can be validly criticised?
Shouldn't these things be demonstrating the sate of the art and
not falling down on questions of basic logic and employing
techniques which were recognised as inadequate nearly a decade ago?
> So besides .attr() needing a rewrite (I fully admit that) -
> I see absolutely no valid criticism of the library
And of course because the only pertinent criteria for valid
criticisms is someone having written general-purpose javascript
library, having done that yourself you then must be in the better
position to judge valid criticism, and so can be satisfied with
just dismissing whatever you don't see as valid out of hand.
> - and if anything, a gross misunderstanding of common cross
> browser issues
This from someone who uses user agent string browser sniffing
virtually to the exclusion of anything else? And someone who's
code only works with a couple of versions of only 4 web browsers.
> 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.
So if David publishes (or continues to publish) scripts it does not
matter how cross-browser they may be, how reliable, how future proof,
how easily maintained they are, how artfully they employ javascript
or how impeccable their logic may be, so long as they are not a
library you are not interested.
Richard.
Matt Kruse
> On Nov 1, 7:23 pm, "Evertjan." <exjxw.hannivo...@interxnl.net> wrote:
> > As of Microsoft Internet Explorer 5, the type property is read/write-once,
> > but only when an input element is created with the createElement method and
> > before it is added to the document."
> (which they think are the same thing), but it doesn't touch on the
> issues relating to the creation of radio buttons
The only person who has ever said anything about the creation of radio
buttons is you.
Creating a new input element and setting its type is a completely
different issue.
I know of no solution to change the type of an existing input in IE.
Which was the point all along. If you have the solution you claim to
have, please do us all a favor, stop the "hinting" and just post an
example.
Matt Kruse
Matt Kruse
> 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
TheBagbournes
Heh! You're quite right, and I think many people who have peeked under the layer of carpets that is the Dojo library, and run away shuddering would agree with you!
VK
> Heh! You're quite right, and I think many people who have peeked
> under the layer of carpets that is the Dojo library, and run away
> shuddering would agree with you!
There are good libraries, bad libraries, awful libraries and God knows
what else libraries. As a side note: a superior quality of a product
is not a decisive argument for its possible popularity. It is only
partially technical problem - in a total it is a complex technical-
administrative-human factor domain with the technical part very rarely
holding the blocking stock package :-)
The real problem of JavaScript is not in the absence of good
libraries. Its real problem is in lack of package mechanics - that
prevents from having real, 3rd party software independent, Java-like
frameworks. As a result one is oftenly having a huge library loaded
just for a few used methods, another huge library for other several
methods/properties etc. There is no easy way just to include any
libraries one likes - but to have the resulted .js only with what
really needed and used from each library.
JavaScript is matured and it went the regular way of any maturing
language: from repetitive code snippets to small libraries; from small
libraries to big "solution size" libraries; now it is on the stage
when one needs libraries to manage libraries - so frameworks. Yes,
everything can be re-done from scratch to exactly fit a particular
solution: but no one will pay for extra hours, so it's an option for
private works at one's leisure time. With the maturity JavaScript also
got the regular pay back of of this stage: a heavily overweighted,
junky inside coding style of big commercial solutions. "There is never
time to polish anything: this lib for this, that lib for that, patch
here, add there, and new processors' speed will compensate any sick
ugly ineffective algorithm."
Some people like Richard Cornford just do not accept that the baby is
grown so trying to put old cloth on it :-)
>From the practical point of view we don't need so much a Yet-Another-
But-Now-Really-Correct library. What is really needed is a framework
software that would compensate current package limitations of
JavaScript. So the user could link as many libraries as she wants but
the runtime-generated .js for the page would include from each library
only what is used and also what is required for used parts. That also
mean that we need an RFC to describe each library so all dependencies
could be properly read and traced by any RFC-aware software.
In My Humble but strong Opinion.
David Mark
> On Nov 1, 6:31 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > On Nov 1, 7:23 pm, "Evertjan." <exjxw.hannivo...@interxnl.net> wrote:
> > > As of Microsoft Internet Explorer 5, the type property is read/write-once,
> > > but only when an input element is created with the createElement method and
> > > before it is added to the document."
> > That's Microsoft's general explanation of that attribute/property
> > (which they think are the same thing), but it doesn't touch on the
> > issues relating to the creation of radio buttons
>
> The only person who has ever said anything about the creation of radio
> buttons is you.
And you would do well to re-read what I said about it and how it
relates to the issue of setting the type property of input elements in
IE.
> Creating a new input element and setting its type is a completely
> different issue.
>
> I know of no solution to change the type of an existing input in IE.
Define an "existing input." Does that mean an input that has a parent
node? Or one that has had its type property set? Either case causes
attempts to set the type property to throw an exception. It would
seem that IE assumes a default type as soon as the node is added to a
document (or document fragment.) And as I told you previously, you
can indeed change an input element from one type to another,
regardless of its circumstance.
> Which was the point all along. If you have the solution you claim to
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. Assuming you
account for this properly, the user of your (very strange) application
will see the input change types, just as it does in standards-based
browsers and will experience no ill after-effects. Whether a node was
orphaned (or destroyed) and replaced by another in the process is
irrelevant.
If you are going to argue semantics, you will have to avoid vagueries
like "existing input." Furthermore, if you really wanted such a
solution for this, you would just use what I already gave you. It
would seem you just want to argue with me.
Matt Kruse
> 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, 5:21 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > 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.
Peter Michaux
> 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, 3:16 pm, Peter Michaux <petermich...@gmail.com> wrote:
> > 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
<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
It was not directed at Matt.
Peter
David Mark
> 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
> 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.
Randy Webb
> On Dec 4, 4:19 pm, Randy Webb <HikksNotAtH...@aol.com> wrote:
>> 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.
> (!)
True. The irony I was referring to was that rozzy didn't have a f**king
clue what they were talking about.
<snip>
> 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.)
Personally, I think it is beyond silly. The entire problem comes about -
mostly - from sites simply making XHR calls to retrieve documents and
inserting them in a container element via innerHTML and then proclaiming
"We have an AJAX site". If the site is designed to be "AJAX friendly"
then the issue doesn't exist.
> 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.
Was the first step in the strategy to determine if the scripts got
executed via innerHTML?
> I'd like to compare it to the definitive version that has been
> tested on all of the weird Mac browsers, etc.
The test page that shows what browsers support what methods?
<URL: http://members.aol.com/_ht_a/hikksnotathome/loadJSFile/>
Last function I posted to attempt to deal with script execution?
Some issues that I know of with it:
1) Doesn't deal with document.write at all.
2) Should be conditional functions so that it isn't
doing all of the feature detection every time you
call the function.
3) Will fail miserably in IE5.2 and early versions of iCab.
4) Probably some other places it will fail. Either silently
or not so silently.
5) Just a note that there was the suggestion of simply
appending to the HEAD element and then removing it instantly
in a thread. Good idea, I just never changed it to do it, mostly
so that I could make a "dump" of a div element to see what
was actually in place at the moment.
As for a "library", there isn't one really. The last code I posted can
definitely be improved on though.
var isIE = false;
/*@cc_on @*/
/*@if (@_jscript_version >= 4)
var isIE = true;
@end @*/
function loadHTMLFragment(elemId, HTMLFragment)
{
if (document &&
document.getElementById &&
document.getElementById(elemId) &&
document.createElement &&
document.appendChild &&
document.getElementsByTagName)
{
var el = document.getElementById(elemId);
if(isIE)
{
HTMLFragment = " " + HTMLFragment;
//The is a hack to cause IE to process the
//script elements if the first node in the
//HTMLFragment is a script element.
}
el.innerHTML = HTMLFragment;
var d =el.getElementsByTagName('script');
var t = d.length;
for (var x=0;x<t;x++)
{
var newScript = document.createElement('script');
newScript.type = "text/javascript";
if(d[x].src)
{
newScript.src = d[x].src;
}
else
{
if(isIE)
{
newScript.text = d[x].text;
}
else
{
var s = document.createTextNode(d[x].text);
newScript.appendChild(s);
}
}
el.appendChild(newScript);
}
for (var y=0;y<t;y++)
{
el.removeChild(el.getElementsByTagName("script")[0]);
David Mark
> David Mark said the following on 12/5/2007 4:19 AM:
>
> > On Dec 4, 4:19 pm, Randy Webb <HikksNotAtH...@aol.com> wrote:
> >> 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.
> > (!)
>
> True. The irony I was referring to was that rozzy didn't have a f**king
> clue what they were talking about.
No question there.
>
> <snip>
>
> > 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.)
>
> Personally, I think it is beyond silly. The entire problem comes about -
> mostly - from sites simply making XHR calls to retrieve documents and
> inserting them in a container element via innerHTML and then proclaiming
> "We have an AJAX site". If the site is designed to be "AJAX friendly"
> then the issue doesn't exist.
I am with you there. This odd strategy leads to people storing state
information in the location hash and then monitoring the location with
setInterval, etc. All in the name of having an "Ajax site." Seems to
me that page navigation is best accomplished without Ajax.
>
> > 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.
>
> Was the first step in the strategy to determine if the scripts got
> executed via innerHTML?
Yes.
>
> > I'd like to compare it to the definitive version that has been
> > tested on all of the weird Mac browsers, etc.
>
> The test page that shows what browsers support what methods?
>
> <URL:http://members.aol.com/_ht_a/hikksnotathome/loadJSFile/>
>
> Last function I posted to attempt to deal with script execution?
>
> Some issues that I know of with it:
>
> 1) Doesn't deal with document.write at all.
Right. And as you have noted, if people are trying to download pages
with Ajax that contain document.write calls, then they should clearly
re-examine their design.
> 2) Should be conditional functions so that it isn't
> doing all of the feature detection every time you
> call the function.
That I did.
> 3) Will fail miserably in IE5.2 and early versions of iCab.
Define miserably. Script errors?
> 4) Probably some other places it will fail. Either silently
> or not so silently.
I imagine so.
> 5) Just a note that there was the suggestion of simply
> appending to the HEAD element and then removing it instantly
That's what I did.
> in a thread. Good idea, I just never changed it to do it, mostly
> so that I could make a "dump" of a div element to see what
> was actually in place at the moment.
>
> As for a "library", there isn't one really. The last code I posted can
> definitely be improved on though.
>
> var isIE = false;
> /*@cc_on @*/
> /*@if (@_jscript_version >= 4)
> var isIE = true;
> @end @*/
> function loadHTMLFragment(elemId, HTMLFragment)
> {
> if (document &&
> document.getElementById &&
> document.getElementById(elemId) &&
> document.createElement &&
> document.appendChild &&
> document.getElementsByTagName)
> {
> var el = document.getElementById(elemId);
> if(isIE)
> {
> HTMLFragment = " " + HTMLFragment;
> //The is a hack to cause IE to process the
> //script elements if the first node in the
> //HTMLFragment is a script element.
> }
I tested for a script element at the head of the fragment and added
the , regardless of the browser.
> el.innerHTML = HTMLFragment;
> var d =el.getElementsByTagName('script');
> var t = d.length;
> for (var x=0;x<t;x++)
> {
> var newScript = document.createElement('script');
> newScript.type = "text/javascript";
> if(d[x].src)
> {
> newScript.src = d[x].src;
> }
I skipped this case.
> else
> {
> if(isIE)
> {
> newScript.text = d[x].text;
> }
This is where mine differs. I create an array of functions to try,
based on testing the text and canHaveChildren properties of a created
script element, then try them in turn. The first one that works is
the one used in the innerHTML wrapper. I try the text property first,
which may or may not be good idea. Does that property throw errors in
any agents that support createTextNode? If so, I will have to change
the testing order.
> else
> {
> var s = document.createTextNode(d[x].text);
> newScript.appendChild(s);
> }
> }
> el.appendChild(newScript);
> }
> for (var y=0;y<t;y++)
> {
> el.removeChild(el.getElementsByTagName("script")[0]);
> }
> }
>
> }
>
Thanks for posting. If you want the one-off version, let me know.
David Mark
[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.
Randy Webb
> On Dec 5, 6:41 am, Randy Webb <HikksNotAtH...@aol.com> wrote:
>> David Mark said the following on 12/5/2007 4:19 AM:
<snip>
>>> I'd like to compare it to the definitive version that has been
>>> tested on all of the weird Mac browsers, etc.
>> The test page that shows what browsers support what methods?
>>
>> <URL:http://members.aol.com/_ht_a/hikksnotathome/loadJSFile/>
>>
>> Last function I posted to attempt to deal with script execution?
>>
>> Some issues that I know of with it:
>>
>> 1) Doesn't deal with document.write at all.
>
> Right. And as you have noted, if people are trying to download pages
> with Ajax that contain document.write calls, then they should clearly
> re-examine their design.
Very true as I don't believe that there is any way to compensate for a
document.write without writing your own parser.
>> 3) Will fail miserably in IE5.2 and early versions of iCab.
>
> Define miserably. Script errors?
I don't think it would error out, it would never make it pasts the
feature testing. Although I don't even know that it would make it that
far in an AJAX application. "Fails silently without fallback" would be a
better description. If the innerHTML assignment was made first, before
any script insertion code, then it would insert the HTML, process the
scripts, and move on.
The test for innerHTML script execution is as simple as:
innerHTMLFailed = true;
window.onload=insertScript;
function insertScript(){
document.getElementById('scriptDiv').innerHTML='<script
type="text/javascript">innerHTMLFailed = false;<\/script>'
}
And then in the function you could have this:
if(innerHTMLFailed){
//code here
}
With a conditional function, you could test for innerHTML script
execution and if it succeeded, you would simply insert the HTML and be
finished. In fact, I have changed my local version to insert the HTML
before the feature testing that is related to the script insertion.
>> 4) Probably some other places it will fail. Either silently
>> or not so silently.
>
> I imagine so.
>
>> 5) Just a note that there was the suggestion of simply
>> appending to the HEAD element and then removing it instantly
>
> That's what I did.
I think the main reason I used a scriptDiv element was for testing more
than anything else. I could dump the innerHTML of scriptDiv to make sure
the script block got inserted if it didn't execute.
<snip>
> I tested for a script element at the head of the fragment and added
> the , regardless of the browser.
That is a better way to go with it since it would only get added when it
was needed.
>> el.innerHTML = HTMLFragment;
>> var d =el.getElementsByTagName('script');
>> var t = d.length;
>> for (var x=0;x<t;x++)
>> {
>> var newScript = document.createElement('script');
>> newScript.type = "text/javascript";
>> if(d[x].src)
>> {
>> newScript.src = d[x].src;
>> }
>
> I skipped this case.
That was added in the last version I posted as an afterthought.
>> else
>> {
>> if(isIE)
>> {
>> newScript.text = d[x].text;
>> }
>
> This is where mine differs. I create an array of functions to try,
> based on testing the text and canHaveChildren properties of a created
> script element, then try them in turn. The first one that works is
> the one used in the innerHTML wrapper. I try the text property first,
> which may or may not be good idea. Does that property throw errors in
> any agents that support createTextNode? If so, I will have to change
> the testing order.
iCab, Safari2/Mac and some other fringe browsers error if you try to set
the .text property of a script element but using createTextNode works in
those two browsers. The main reason I used the isIE is because IE is the
only browser I am aware of that doesn't support createTextNode and the
idea was to use createTextNode and only use .text for IE.
> Thanks for posting. If you want the one-off version, let me know.
Sure. Maybe the two together we can get something that is better than
either of them alone.
Randy Webb
> On Dec 5, 7:17 am, David Mark <dmark.cins...@gmail.com> wrote:
<snip>
> Guys its hard to take you seriously with dicks still in your mouth, I
> mean it feels like the special olympics... I want to tell you your
> wrong, but I'm pretty much obligated to let you win.
You are too stupid to know whether someone is wrong or not.
> btw, Randy Webb, nice job backing down from your response, "it was a
> general comment", and then coming back later with your attempted
> insult you fucking pussy.
That is coming from a person too stupid to realize who wrote what.
Does your mommy know you are on the computer?
David Mark
Apparently you care. How else do you explain the profanity-laced
reply? Tourette's Syndrome?
And I'm sure you are just like me, except that you have considerable
trouble reading and writing English and know virtually nothing about
JavaScript (as evidenced by your recent posts here and in the
JavaScript Forum.)
beegee
> 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
David Mark
> David Mark said the following on 12/5/2007 7:17 AM:
>
> > On Dec 5, 6:41 am, Randy Webb <HikksNotAtH...@aol.com> wrote:
> >> David Mark said the following on 12/5/2007 4:19 AM:
>
> <snip>
>
> >>> I'd like to compare it to the definitive version that has been
> >>> tested on all of the weird Mac browsers, etc.
> >> The test page that shows what browsers support what methods?
>
> >> <URL:http://members.aol.com/_ht_a/hikksnotathome/loadJSFile/>
>
> >> Last function I posted to attempt to deal with script execution?
>
> >> Some issues that I know of with it:
>
> >> 1) Doesn't deal with document.write at all.
>
> > Right. And as you have noted, if people are trying to download pages
> > with Ajax that contain document.write calls, then they should clearly
> > re-examine their design.
>
> Very true as I don't believe that there is any way to compensate for a
> document.write without writing your own parser.
It would certainly be a waste of time.
>
> >> 3) Will fail miserably in IE5.2 and early versions of iCab.
>
> > Define miserably. Script errors?
>
> I don't think it would error out, it would never make it pasts the
> feature testing. Although I don't even know that it would make it that
> far in an AJAX application. "Fails silently without fallback" would be a
> better description. If the innerHTML assignment was made first, before
> any script insertion code, then it would insert the HTML, process the
> scripts, and move on.
>
> The test for innerHTML script execution is as simple as:
>
> innerHTMLFailed = true;
> window.onload=insertScript;
>
> function insertScript(){
> document.getElementById('scriptDiv').innerHTML='<script
> type="text/javascript">innerHTMLFailed = false;<\/script>'
>
> }
Aren't you missing the at the start of the string?
>
> And then in the function you could have this:
>
> if(innerHTMLFailed){
> //code here
>
> }
This is similar to what I did, but I don't test with a straight
innerHTML assignment as I use a wrapper for setting or appending HTML
that smooths out some of the issues with innerHTML. The wrapper uses
insertAdjacentHTML in a dummy DIV and then adds the nodes to the
target element. It seems it has identical issues with inline script,
including the need for the hack in IE.
I switched the order of testing to try createTextNode first.
>
> > Thanks for posting. If you want the one-off version, let me know.
>
> Sure. Maybe the two together we can get something that is better than
> either of them alone.
You won't be able to run this as it makes numerous references to
wrappers and an object defined in another script. The feature testing
logic looks like this:
methods = [];
s = createElement('script');
if (s) {
add = function(method, t) {
head.appendChild(s);
method(s, t);
head.removeChild(s);
};
if (doc.createTextNode && s.canHaveChildren ||
typeof(s.canHaveChildren) == 'undefined') {
push(methods, function(s, t) {
s.appendChild(doc.createTextNode(t));
});
}
if (typeof(s.text) == 'string') {
push(methods, function(s, t) {
s.text = t;
});
}
l = methods.length;
while (!api._testscriptinsertion && l--) {
add(methods[l], 'this.api._testscriptinsertion = true;');
}
if (api._testscriptinsertion) {
setElementScript = api.setElementScript = function(el, t) {
s = el;
while (s.firstChild) { s.removeChild(s.firstChild); }
add(methods[l], t);
}
addElementScript = api.addElementScript = function(s, t) {
s = el;
add(methods[l], t);
}
addScript = api.addScript = function(t) {
s = createElement('script');
add(methods[l], t);
s = null;
};
}
delete api._testscriptinsertion;
s = null;
}
So it doesn't actually do the innerHTML test first as it defines
general purpose script insertion/addition methods that can be used
without innerHTML.
After this it augments the HTML manipulation methods if they exist:
findAndAddScripts = function(el) {
var l, scripts = elementElementsByTagName(el, 'script');
l = scripts.length;
while (l--) {
if (scripts[l].text) { addScript(scripts[l].text); }
}
}
if (addElementHTML) {
addElementHTML(head, '<script type="text/
javascript">this.api._testaddhtmlscript = true;</script>');
if (!api._testaddhtmlscript) {
api.addElementHTML = function(el, html) {
addElementHTML(el, html);
findAndAddScripts(el);
};
}
}
There are two more clauses like this that have to run after the body
is parsed as they create and append a DIV to test the wrappers that
set inner/outerHTML. Worked for me, at least in the modern browsers I
use to test Ajax apps. Now that I switched the initial testing order,
it should work for iCab and those other odd Mac browsers that I don't
have here.