Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Results 1 to 14 of 14
  1. #1
    Regular Coder
    Join Date
    Oct 2010
    Location
    San Antonio Tx
    Posts
    251
    Thanks
    12
    Thanked 11 Times in 11 Posts

    Jquery and Javascripts

    whats the difference between Jquery and Javascripts?

  • #2
    Banned
    Join Date
    Feb 2011
    Posts
    2,699
    Thanks
    13
    Thanked 395 Times in 395 Posts
    jQuery is a javascript framework - basically a library of javascript functions to perform specific tasks and in a production environment can save coders time coding because someone else has already written the bulk of the code to perform a task. There is nothing you can do with jQuery that you cannot do with plain javascript.

    [ot]
    On a side note though, all too often I see people coming into forums saying they are new to javascript and asking for help with their jQuery code. Imo people should learn at least the basics of javascript before playing with jQuery.

    People trying to take the "jQuery shortcut" without learning javascript first will most probably result in them spending a lot of time in forums like this looking for someone to help them when they get stuck.
    [/ot]

  • #3
    The fat guy next door VIPStephan's Avatar
    Join Date
    Jan 2006
    Location
    Halle (Saale), Germany
    Posts
    8,607
    Thanks
    6
    Thanked 997 Times in 970 Posts
    Quote Originally Posted by NoeG View Post
    whats the difference between Jquery and Javascripts?
    Basically jQuery is modularizing the many possibilities you have with plain JS. For example, in basic JS when you wanna retreive an element you have to write, e. g., document.getElementById('whatever') all the time. What jQuery does is take that syntax and shortens it to a more manual input friendly version.

    You’re already starting to write your own basic tiny library if you’re writing something like this to retreive elements:

    Code:
    function getEl(e) {  
      if (typeof e == 'string') 
        {return window.document.getElementById(e);}  
      if (e[0]) {//array
        var i=e.length;     
        while(i--) {e[i]=arguments.callee(e[i]);}
        return e;}  return e;//element
    }
    …
    …
    getEl('whatever')getEl('anotherElement')…

  • #4
    Banned
    Join Date
    Feb 2011
    Posts
    2,699
    Thanks
    13
    Thanked 395 Times in 395 Posts
    Quote Originally Posted by VIPStephan View Post
    For example, in basic JS when you wanna retreive an element you have to write, e. g., document.getElementById('whatever') all the time.
    Maybe I'm being a bit picky here, but you only need to do that once and assign the object to an appropriate variable either locally or globally and then refer to that variable whenever you need to access that object for any reason.

    So I guess the point I am making is that that is probably not a good example of the advantages of jQuery (of which there are disadvantages as well as alluded to in my earlier post)

  • #5
    The fat guy next door VIPStephan's Avatar
    Join Date
    Jan 2006
    Location
    Halle (Saale), Germany
    Posts
    8,607
    Thanks
    6
    Thanked 997 Times in 970 Posts
    Quote Originally Posted by bullant View Post
    Maybe I'm being a bit picky here, but you only need to do that once and assign the object to an appropriate variable either locally or globally and then refer to that variable whenever you need to access that object for any reason.
    As far as I understand that works if you have one object to assign. But what if you have several objects? What if you need to get many elements by different IDs in your script? That function makes this a little more convenient just as the $('anyCssSelector') syntax in jQuery. Of course, jQuery can do much more but I wanted to use a simple example to illustrate my point.

  • #6
    Banned
    Join Date
    Feb 2011
    Posts
    2,699
    Thanks
    13
    Thanked 395 Times in 395 Posts
    yep no problem - I'm not trying to sidetrack this thread But to answer your question you can write (or copy from elsewhere) simple functions to collect elements by className or their name attribute into an array and then loop through the array to process those elements.

    For doing "back-end" code intensive stuff like fade-in/fade-out slide shows with animations etc etc then yes, jQuery can save a lot of time but I don't see the point of loading a complete library of javacsript functions to do all sorts of tasks if only simple basic tasks are required on the page.

    But that's just me and since I contributed my 2c worth in post 2, I'll butt out now

  • #7
    Regular Coder
    Join Date
    Oct 2010
    Location
    San Antonio Tx
    Posts
    251
    Thanks
    12
    Thanked 11 Times in 11 Posts
    People trying to take the "jQuery shortcut" without learning javascript first will most probably result in them spending a lot of time in forums like this looking for someone to help them when they get stuck.
    exactly what I was thinking to just jump strait to jquery thanks...I am trying to learn the basics of JS but I cant wrap my brain around it....gonna keep trying though

  • #8
    Senior Coder rnd me's Avatar
    Join Date
    Jun 2007
    Location
    Urbana
    Posts
    4,277
    Thanks
    10
    Thanked 581 Times in 562 Posts
    jQuery is to javascript as McDonald's is to hamburgers. It tastes a lot better to make and bbq your own burgers with your own good meat, spices, and fixings on a real fire.
    But, sometimes we just need to eat something quick and we don't particularity care how it tastes as long as it's easy.

    I think that if you stop targeting IE7 and old Safris, you can easily kill jQuery.
    Most of its convenience to me comes from homogenized dom access like .textContent vs. .innerText as .text()...
    most of the plugins are poorly written; akin to DynamicDrive reloaded for a new generation of skill-less busy bodies.

    using array prototypes like .map and .filter, you can get a HUGE chunk of jQuery-esqe power in just a single gatherer function:

    Code:
    function $(selector){
       return [].slice.call(document.querySelectorAll(selector));
    }
    Last edited by rnd me; 03-08-2011 at 08:17 PM.
    my site (updated 13/9/26)
    BROWSER STATS [% share] (2014/5/28) IE7:0.1, IE8:5.3, IE11:8.4, IE9:3.2, IE10:3.2, FF:18.2, CH:46, SF:7.9, NON-MOUSE:32%

  • #9
    Gütkodierer
    Join Date
    Apr 2009
    Posts
    2,127
    Thanks
    1
    Thanked 426 Times in 424 Posts
    Quote Originally Posted by rnd me View Post
    jQuery is to javascript as McDonald's is to hamburgers. It tastes a lot better to make and bbq your own burgers with your own good meat, spices, and fixings on a real fire.
    Hm. I don't really like that metaphor.

    I'd say it's rather like using products you can buy in a store vs. learning to grow your own crops and cows — with jQuery being quality ingredients from a trusted store (with which you still need lots of bbqing experience in order to make something tasty), and jQuery plugins being ready made hamburgers from some arbitrary burger joint, which may or may not give you food poisoning.

  • #10
    Senior Coder rnd me's Avatar
    Join Date
    Jun 2007
    Location
    Urbana
    Posts
    4,277
    Thanks
    10
    Thanked 581 Times in 562 Posts
    Quote Originally Posted by venegal View Post
    I'd say it's rather like using products you can buy in a store vs. learning to grow your own crops and cows — with jQuery being quality ingredients from a trusted store
    the quality of the ingredients is up for debate. I think that jQuery has gotten better ingredients over time, but it's still a lot closer to walmart than a farmers market.

    the other downside to jQuery is that you need to use all 500 of its ingredients for every meal, doing it yourself means less packaging and scraps.
    my site (updated 13/9/26)
    BROWSER STATS [% share] (2014/5/28) IE7:0.1, IE8:5.3, IE11:8.4, IE9:3.2, IE10:3.2, FF:18.2, CH:46, SF:7.9, NON-MOUSE:32%

  • #11
    Gütkodierer
    Join Date
    Apr 2009
    Posts
    2,127
    Thanks
    1
    Thanked 426 Times in 424 Posts
    Quote Originally Posted by rnd me View Post
    the quality of the ingredients is up for debate. I think that jQuery has gotten better ingredients over time, but it's still a lot closer to walmart than a farmers market.

    the other downside to jQuery is that you need to use all 500 of its ingredients for every meal, doing it yourself means less packaging and scraps.
    Do you dislike anything particular about jQuery? I think it's pretty well done, but I haven't delved too deeply into the source. I've never found myself in a situation where I felt a need to manually implement some functionality jQuery offers because it did it poorly, so I'd be interested in your comments.

    I don't think that the packaging is much of a problem anymore because of CDNs and jQuery's ubiquity. I don't even think twice about including it anymore, because people either have it already in their cache, or I'm doing them a favour by putting it there.

  • #12
    Senior Coder rnd me's Avatar
    Join Date
    Jun 2007
    Location
    Urbana
    Posts
    4,277
    Thanks
    10
    Thanked 581 Times in 562 Posts
    Quote Originally Posted by venegal View Post
    Do you dislike anything particular about jQuery?
    im trying to be fair and honest, i could throw out plenty of anti-jquery points that don't really bother me individually, but the following all personally bother me:

    1. 55kb of code to do anything: too big for iOS's cache means lots re-transfers of 1/20th of a meg on every page visit. from prepaid mifi, that's fairly expensive. a CDN implies another DNS lookup and more privacy erosion.

    2. can't iterate comment nodes.

    3. backwards argument order on .map w/no custom this, completely different args (this) on .filter

    4. 20X more CPU to fadeOut() vs a hand-coded solution.

    5. selection uses much much more CPU than getElementsByTagName, getByClassName, and querySelectorAll.

    6. can't use 1.6 array methods, the clones are slow, though 1.4 added .toArray (thanks)

    7. i've had IE errors raised inside the compressed jQuery file, nearly impossible to debug, no helper throw statement inside jQuery codebase.

    8. makes debugging in general harder due to single-letter function names, deeply nested function calls for every tiny trivial thing (ex: c.isFunction(a)), and having the whole library inside a trace-less anon function.

    Code:
    $.fn.attr == function (a, b) {
        return X(this, a, b, true, c.attr);
    }
    what the heck is X and c in that function? wtf?!?!?! grrrrr...

    9. philosophical problems with the guts: lots of conditionals based on current browser, instead of instantiating a dedicated method.
    Code:
     if (a.addEventListener) { //from jq1.4's $.event.add
    10. form serialization uses php-style arrays (arguably a pref)

    11. no CORS support for a library that supposedly supports ajax.

    12. $("<xml />") for creating DOMs works in W3, but not in IE.

    13. performance. why does it take 1000+ function calls to simple things like fading, or 20+ calls to simply $("body").hide(). On pre-GS iPhones, pages that use jQuery are often noticably slower than pages who's authors took time to use apropos scripting for the page's functionality.

    ----------
    most of my ill feeling are performance related, overlapping hovers, 100% cpu usage on jerky mouse moves, etc.
    I will admit that performance is MUCH better as of 1.4, so much so i think it should have been re-named as a new library, or jQuery2 or something...

    it would be much nicer if i could compile only the functionality i needed instead of 55kb of FX and compat code i don't need.





    Quote Originally Posted by venegal View Post
    I don't think that the packaging is much of a problem anymore because of CDNs and jQuery's ubiquity. I don't even think twice about including it anymore, because people either have it already in their cache, or I'm doing them a favour by putting it there.
    providing google ad-market-research favors by associating a user's IP address with your page via the ever-popular hosted libraries is hardly a favor: it's eroding the privacy of your site and it's users.

    If you use a third party to host an asset because it's too big for your servers to handle, should you really be requiring that asset in everything you do?
    I've never seen a page load faster simply by switching a js file to a hosted codebase: feel free to quantitatively prove me wrong, but in all my tests, it's quicker to serve it yourself.

    Finally, you can use a manifest locally to perma cache the asset, something that is not consistently possible with 3rd-party domains.
    Last edited by rnd me; 03-09-2011 at 12:47 AM.
    my site (updated 13/9/26)
    BROWSER STATS [% share] (2014/5/28) IE7:0.1, IE8:5.3, IE11:8.4, IE9:3.2, IE10:3.2, FF:18.2, CH:46, SF:7.9, NON-MOUSE:32%

  • #13
    Gütkodierer
    Join Date
    Apr 2009
    Posts
    2,127
    Thanks
    1
    Thanked 426 Times in 424 Posts
    Thanks for taking the time to write that up. I'll comment on the points I already have an opinion on; those comments might be a bit on the pro jQuery side in order to provide a counterpoint, which doesn't necessarily mean that I'm a fanboy.

    Quote Originally Posted by rnd me View Post
    1. 55kb of code to do anything: too big for iOS's cache means lots re-transfers of 1/20th of a meg on every page visit. from prepaid mifi, that's fairly expensive. a CDN implies another DNS lookup and more privacy erosion.
    The cache limit on iOS surely is a bummer. On the other hand, going without jQuery on a few sites won't change the fabric of the web — there are lots of badly done sites including several frameworks in order to make a bunch of plugins work, and people with expensive data transfer plans will generally notice that surfing the web isn't cheap, but they won't notice that one particular site just saved them some money (performance is an entirely other issue, of course). Also, I don't think jQuery's 29k (1.5, minified, gzipped) is really that much of a burden. That's like one medium sized image.

    As for the CDN, I don't think the DNS lookup is really an issue because of client-side DNS caching. The privacy erosion is an issue, of course. The ubiquity of Google Analytics might suggest, though, that this is already a lost battle (if you consider there to be a battle, and don't just trust Google in order to be able to sleep at all).

    Quote Originally Posted by rnd me View Post
    2. can't iterate comment nodes.
    Just out of interest, what did you need that for?

    Quote Originally Posted by rnd me View Post
    3. backwards argument order on .map w/no custom this, completely different args (this) on .filter
    I'll give you the missing this parameter of jQuery.map, since that's actually about arrays, but since .map and .filter are methods of jQuery collections and not arrays, I don't consider differences from those JS 1.6 array methods to be a real problem. They are simply not meant to give cross-browser 1.6 support, but for DOM traversing and manipulation.

    Quote Originally Posted by rnd me View Post
    4. 20X more CPU to fadeOut() vs a hand-coded solution.

    5. selection uses much much more CPU than getElementsByTagName, getByClassName, and querySelectorAll.
    I won't argue about performance. There's always a tradeoff.

    Quote Originally Posted by rnd me View Post
    6. can't use 1.6 array methods, the clones are slow, though 1.4 added .toArray (thanks)
    I suppose it's a design decision not to extend native data types. Providing a cross-browser 1.6 implementation is just not what it's for.

    Quote Originally Posted by rnd me View Post
    7. i've had IE errors raised inside the compressed jQuery file, nearly impossible to debug, no helper throw statement inside jQuery codebase.
    I guess you are saying that those errors didn't occur in the uncompressed file? That sounds unlikely, and is probably a bug.

    Quote Originally Posted by rnd me View Post
    8. makes debugging in general harder due to single-letter function names, deeply nested function calls for every tiny trivial thing (ex: c.isFunction(a)), and having the whole library inside a trace-less anon function.

    Code:
    $.fn.attr == function (a, b) {
        return X(this, a, b, true, c.attr);
    }
    what the heck is X and c in that function? wtf?!?!?! grrrrr...
    I couldn't find that piece of code in the source. What version are you refering to?

    On a quick glance, I didn't find those single-letter function names either. For debugging I find it feasible enough to just look in the stack trace for the last piece of code I wrote myself, because the error won't be inside jQuery anyway.

    The anonymous wrapper is a good thing in my book, for obvious namespacing reasons. I also like the window and undefined parameters of the anonymous function, so the window lookup will be faster, and undefined will really be undefined.


    Quote Originally Posted by rnd me View Post
    9. philosophical problems with the guts: lots of conditionals based on current browser, instead of instantiating a dedicated method.
    Code:
     if (a.addEventListener) { //from jq1.4's $.event.add
    Can you elaborate on what you mean with "instantiating a dedicated method"? As far as I can see, every addEventListener/attachEvent lookup is used in a different context.

    Quote Originally Posted by rnd me View Post
    10. form serialization uses php-style arrays (arguably a pref)
    What do you mean by that?

    Quote Originally Posted by rnd me View Post
    11. no CORS support for a library that supposedly supports ajax.
    My understanding is that jQuery aims to provide cross-browser safe functionality, and since CORS isn't something that just differs in browser implementations, but that is entirely unsupported in a bunch of browsers, I don't think it belongs in the jQuery core. For a plugin, that would be fine, and I suppose they exist.

    Quote Originally Posted by rnd me View Post
    12. $("<xml />") for creating DOMs works in W3, but not in IE.
    Could you explain what you mean by that? Is it supposed to work cross-browser but doesn't?

    Quote Originally Posted by rnd me View Post
    13. performance. why does it take 1000+ function calls to simple things like fading, or 20+ calls to simply $("body").hide(). On pre-GS iPhones, pages that use jQuery are often noticably slower than pages who's authors took time to use apropos scripting for the page's functionality.
    Yes, performance vs. development (and maintenance) cost is an always an issue.

    Quote Originally Posted by rnd me View Post
    most of my ill feeling are performance related, overlapping hovers, 100% cpu usage on jerky mouse moves, etc.
    What do you mean with "overlapping hovers"?

    Quote Originally Posted by rnd me View Post
    it would be much nicer if i could compile only the functionality i needed instead of 55kb of FX and compat code i don't need.
    John Resig suggest building a custom copy from individual pieces from SVN, but that's probably not feasible.


    Quote Originally Posted by rnd me View Post
    If you use a third party to host an asset because it's too big for your servers to handle, should you really be requiring that asset in everything you do?
    I've never seen a page load faster simply by switching a js file to a hosted codebase: feel free to quantitatively prove me wrong, but in all my tests, it's quicker to serve it yourself.

    Finally, you can use a manifest locally to perma cache the asset, something that is not consistently possible with 3rd-party domains.
    The asset being too big for the server to handle is an amusing notion. Whether the CDN per se is faster than serving it yourself is up for debate, as I haven't done any tests, but for most sites, the number of first time visitors outweighs the number of recurring visitors, so the CDN version being already cached definitely does make a difference. Same goes for the cache manifest, which would target recurring visitors only.


    This has been much longer than I originally intended, but I find this to be an interesting discussion.

  • #14
    The fat guy next door VIPStephan's Avatar
    Join Date
    Jan 2006
    Location
    Halle (Saale), Germany
    Posts
    8,607
    Thanks
    6
    Thanked 997 Times in 970 Posts
    Quote Originally Posted by rnd me View Post
    8. makes debugging in general harder due to single-letter function names, deeply nested function calls for every tiny trivial thing (ex: c.isFunction(a)), and having the whole library inside a trace-less anon function.

    Code:
    $.fn.attr == function (a, b) {
        return X(this, a, b, true, c.attr);
    }
    what the heck is X and c in that function? wtf?!?!?! grrrrr...
    You know that you can just use the un-minified version for development and debugging, don’t you?


  •  

    Posting Permissions

    • You may not post new threads
    • You may not post replies
    • You may not post attachments
    • You may not edit your posts
    •