Javascript Library

Discussion in 'Javascript' started by shapper, Oct 29, 2007.

  1. shapper

    shapper Guest

    Hello,

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

    Which one do you advice me to use?

    Thanks,
    Miguel
    shapper, Oct 29, 2007
    #1
    1. Advertising

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


    Until further notice: yours.


    PointedEars
    --
    var bugRiddenCrashPronePieceOfJunk = (
    navigator.userAgent.indexOf('MSIE 5') != -1
    && navigator.userAgent.indexOf('Mac') != -1
    ) // Plone, register_function.js:16
    Thomas 'PointedEars' Lahn, Oct 29, 2007
    #2
    1. Advertising

  3. On Oct 28, 5:48 pm, shapper <> 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...

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

    Peter
    Peter Michaux, Oct 29, 2007
    #3
  4. shapper

    Brian Adkins Guest

    On Oct 28, 8:50 pm, Thomas 'PointedEars' Lahn <>
    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"?
    Brian Adkins, Oct 29, 2007
    #4
  5. shapper

    David Mark Guest

    On Oct 29, 11:26 am, Brian Adkins <> wrote:
    > On Oct 28, 8:50 pm, Thomas 'PointedEars' Lahn <>
    > wrote:
    >
    > > shapper wrote:
    > > > I would like to use a javascript library to simplify my coding
    > > > process. I know a few: JQuery, Dojo, Yahoo UI, ...

    >
    > > > Which one do you advice me to use?

    >
    > > Until further notice: yours.

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


    I don't see Richard in this thread. Regardless, your library does not
    have to be 100% self-written. IIRC, Richard stated something to that
    effect in the other "please recommend a library" thread.
    David Mark, Oct 29, 2007
    #5
  6. shapper

    Matt Kruse Guest

    On Oct 28, 7:48 pm, 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?


    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
    Matt Kruse, Oct 29, 2007
    #6
  7. shapper

    David Mark Guest

    On Oct 29, 12:01 pm, Matt Kruse <> wrote:
    > On Oct 28, 7:48 pm, 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?

    >
    > 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.
    David Mark, Oct 29, 2007
    #7
  8. shapper

    Matt Kruse Guest

    On Oct 29, 11:25 am, David Mark <> 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
    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
    Matt Kruse, Oct 29, 2007
    #8
  9. shapper

    David Mark Guest

    On Oct 29, 12:47 pm, Matt Kruse <> wrote:
    > On Oct 29, 11:25 am, David Mark <> 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.
    David Mark, Oct 29, 2007
    #9
  10. shapper

    Matt Kruse Guest

    On Oct 29, 12:42 pm, David Mark <> wrote:
    > 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
    Matt Kruse, Oct 29, 2007
    #10
  11. shapper

    David Mark Guest

    On Oct 29, 3:00 pm, Matt Kruse <> wrote:
    > On Oct 29, 12:42 pm, David Mark <> 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++ )
    if ( second.nodeType != 8 )
    first.push(second);
    } 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 );
    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.
    David Mark, Oct 29, 2007
    #11
  12. shapper

    Jeff North Guest

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

    Thank you for the insightful review of jQuery.
    Could you please tell me where I can get a copy of your js library?
    -- -------------------------------------------------------------
    : Remove your pants to reply
    -- -------------------------------------------------------------
    Jeff North, Oct 30, 2007
    #12
  13. shapper

    Evertjan. Guest

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

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


    What and to who are you replying, Jeff?

    [please always quote on usenet]

    --
    Evertjan.
    The Netherlands.
    (Please change the x'es to dots in my emailaddress)
    Evertjan., Oct 30, 2007
    #13
  14. Peter Michaux wrote:
    > On Oct 28, 5:48 pm, shapper <> 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.
    Douglas Crockford, Oct 30, 2007
    #14
  15. shapper

    Matt Kruse Guest

    On Oct 30, 8:16 am, Douglas Crockford <> wrote:
    > 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
    Matt Kruse, Oct 30, 2007
    #15
  16. shapper

    David Mark Guest

    On Oct 30, 7:50 am, Jeff North <> wrote:
    > On Mon, 29 Oct 2007 14:42:48 -0700, in comp.lang.javascript David Mark
    > <>
    >
    > <> 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, Oct 30, 2007
    #16
  17. shapper

    Matt Kruse Guest

    On Oct 29, 4:42 pm, David Mark <> 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
    Matt Kruse, Oct 30, 2007
    #17
  18. shapper

    David Mark Guest

    On Oct 30, 9:16 am, Douglas Crockford <> wrote:
    > Peter Michaux wrote:
    > > On Oct 28, 5:48 pm, shapper <> 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?
    David Mark, Oct 30, 2007
    #18
  19. shapper

    Matt Kruse Guest

    On Oct 30, 9:50 am, David Mark <> wrote:
    > > 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
    Matt Kruse, Oct 30, 2007
    #19
  20. shapper

    David Mark Guest

    On Oct 30, 12:12 pm, Matt Kruse <> wrote:
    > On Oct 30, 9:50 am, David Mark <> 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?
    David Mark, Oct 30, 2007
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mythran
    Replies:
    0
    Views:
    2,404
    Mythran
    Aug 24, 2004
  2. Alan Ferrandiz [MCT]
    Replies:
    0
    Views:
    435
    Alan Ferrandiz [MCT]
    Sep 11, 2004
  3. Sweep

    Library in library...

    Sweep, Dec 8, 2003, in forum: C++
    Replies:
    1
    Views:
    378
    Jack Klein
    Dec 9, 2003
  4. Replies:
    6
    Views:
    819
    red floyd
    May 10, 2005
  5. iceColdFire

    Static library Vs. Dynamic library

    iceColdFire, May 17, 2005, in forum: C++
    Replies:
    3
    Views:
    17,021
Loading...

Share This Page