4 ms·

The more I use jQuery, the more of a mess I see that it is. Don't get me wrong, I'd rather use it than rolling my own cross browser solution, but it is not the

The more I use jQuery, the more of a mess I see that it is. Don't get me wrong, I'd rather use it than rolling my own cross browser solution, but it is not the library that Id choose first. I simply do not like the api choices, the lib works well, the api, as seen in this article, isn't too pretty.

csomar 15y ago
Backward compatibility. Millions (if not hundred of millions) of websites rely on jQuery, switching to a newer version that breaks old code will wreak havoc and make these sites unusable. But this shouldn't stop jQuery from improving. If you have read the article from the beginning, you'll see how the jQuery team was improving the binding functionality. It has a cost, certainly. Maybe there should be a jQuery version with no legacy code.
- davej 15y ago
  Yep, the best advice for a newcomer is to just use `.on()` and familiarise yourself with that API. You can ignore the other event handler methods because they're all just shortcuts or legacy methods.
  - dmethvin 15y ago
    Exactly. It would simplify the documentation to simply deprecate everything but .on() but would that justify breaking all the existing code out there? Not to me. The old APIs need to stay around so that code continues to work.
    - cgoddard 15y ago
      They could deprecate the old methods and still keep them around as long as makes sense. There's no rule that deprecated methods have to be gotten rid of during the next major revision or anything.
    - cgoddard 15y ago
      Even if they excised the old methods from the code, hopefully no one is linking to jQuery trunk or something as their primary library. The old versions would still be around. Just some simple work might have to be done to update a web app to using the latest versions of jQuery.
  - emehrkay 15y ago
    I like MooTools. When they added event delegation to their library, they simply modified the existing addEvent method to parse the event name instead of adding new method after new method -- seems like a more thought out approach. $(selector').addEvent('click:relay(selector)', fn)
- emehrkay 15y ago
  The overall api is strange. The each loops are backwards from the spec (key, value) instead of (value, key) and there are instances where it is key, value in jquery, there are instances where method names just don't make sense (I'd expect something like size to be dimensions etc), getters and setters as the same method, way too much argument overloading, inconsistent approach (selector.action, but wrap is the opposite of how the rest of the lib works). There is no kind of inheritance for their plugin architecture. These are just things off the top of my head. I feel like jQuery is the same as PHP when it comes to api, and I make a living doing PHP.
  - mark_story 15y ago
    jQuery.map() jQuery.each() having their arguments has caused me more than a few WAT moments. One way I solve the issue around overloaded apis is by not using them. I just pretend .click() and friends just don't exist.
- prolepunk 15y ago
  Yet it breaks hilariously when you try to move from 1.3.2 to 1.4.4. I still have ONE script for which I have to deal with jquery-1.3.2.
- jonknee 15y ago
  > Maybe there should be a jQuery version with no legacy code. They're deprecating stuff, so it's just a matter of time. I think that's the sensible way to do things. http://blog.jquery.com/2011/11/08/building-a-slimmer-jquery/ http://blog.jquery.com/2011/11/08/building-a-slimmer-jquery/ They're also taking steps to be able and use Google Closure Compiler's advanced optimizations, which would let you build jQuery against your code and trim out everything that's not used. Pretty handy.
  - nfriedly 15y ago
    > They're also taking steps to be able and use Google Closure Compiler's advanced optimizations... That is awesome, thanks for pointing it out!
- jacobr 15y ago
  A 2.0 release would be a reasonable point to potentially break legacy code.
v33ra 15y ago
Jquip is trying to make jquery less messy by splitting into separate modules.
- fooyc 15y ago
  But it failed to use a proper module format (e.g. CommonJS / AMD)
jsdalton 15y ago
> ...but it is not the library that Id choose first. Which library/libraries would you choose first, over jQuery?
- maratd 15y ago
  MooTools. Dojo. The herd has been thinned a bit over the last few years.
- jacobr 15y ago
  I would use Ender and pull together various micro-libraries/modules. http://ender.no.de http://ender.no.de
  - jsdalton 15y ago
    That is very interesting. It looks like they even have a "starter pack" that approximates much of what jQuery does: http://ender.no.de/#jeesh http://ender.no.de/#jeesh Thanks.
    - euroclydon 15y ago
      I winder how it well it works with SVG?
- oinksoft 15y ago
  For a complete one-off, plain JavaScript and DOM. For a small, simple project, MooTools. For a large project, Closure Tools. jQuery's not a good choice for anything I work on, and its "God Object" API makes for repugnant code.
funkah 15y ago
I've been using Prototype for years and am now using jQuery more, and I have to agree. The knock against Prototype was that it modifies built-in classes, but I seriously doubt how much that actually matters, and as a programming library it makes much more sense to work with, I think. jQuery doesn't even offer very useful things like list comprehensions! You have to use underscore to get those.
- emehrkay 15y ago
  There is a grep method that does some stuff: http://api.jquery.com/jQuery.grep/ http://api.jquery.com/jQuery.grep/
- tikhonj 15y ago
  Actually, splitting out logical code from DOM manipulation code makes plenty of sense. Just because I'm using one does not mean I want the other and both stand on their own fairly well. This is even more important now that JavaScript is popular on the server--I can use Underscore there as well.
bdg 15y ago
> the more of a mess I see that it is. I started a joke project to mock the total mess that jQuery has become, http://cowbelljs.com/ http://cowbelljs.com/ . The performance hit from using jQuery is awful these days, it's become a monolithic framework aimed towards support for a hodge-podge of things rather than using best practices. A simple line of code such as this might be readable: $(".foo input[type=checkbox]:checked").live(function(e){fizzbuzz(e)}) But, the costs of that? You've just killed performance, your page is probably going to have laggy response and all kinds of event listener issues crop up as you keep working, leading to you using .die, .stopeventpropegation, .stopeventbubbeling, and return false all over the place in a futile attempt to manage your events. jQuery does a great job of letting you write less code, it also does a good job of abstracting away tasks and making things look like "magic", but it also really makes it easy to shoot yourself in the foot, with a tommy gun. jQuery creates a lot of undesirable effects, as far as I'm concerned: - People don't understand what their code does. - jQuery API is a mess, and version upgrades are hard - Best practices for a given task are not focused on, rather, "every practice" is accepted, and whatever blog post the JS novice read at the time becomes the method they write their code with (as a result, we almost never see .delegate() in use) - The library is huge. Yes, they brag about it being only 31kb minified, but that's huge! - jQuery code is slow. - Nobody understands how the DOM API works any more, and because sizzle makes it easy to select complex things the authors don't even bother writing semantic HTML, so we start to see <td id="Row2Cell2"> kind of things. - We have landed in a mess where ambitious people tightly couple their projects with an unstable API and practices that create sluggish pages. Sure, you can use jQuery correctly, but I'd rather use a micro-framework that complements JavaScript rather than attempt to replace it with tightly-coupled abstraction layers and memory hogging through event listeners and timers all over the place. The culture around it makes me really sad.
- driverdan 15y ago
  Most of your argument boils down to "jQuery makes it easy for shit developers to write shit code, therefore you shouldn't use it". No response necessary. > jQuery code is slow Compared to what? What parts are slow? Keep in mind it needs to support legacy browsers like IE6 before you answer those questions.
MatthewPhillips 15y ago
I don't use JQuery anymore at all. I just use element.addEventListener with a polyfill for attachEvent if I need to hit old IE.
- bdg 15y ago
  Poly-fill is the future. Someone's working on a DOM polyfill at the moment, it's unstable beta but looks promising: https://github.com/Raynos/DOM-shim https://github.com/Raynos/DOM-shim
  - dkubb 15y ago
    I've often thought that frameworks should be built on top of standardized native apis, poly-filled when necessary. I imagine a time when browser specific hacks will be outside of the frameworks and "pushed down" to something lower level; ultimately shared across several frameworks rather than siloed off like it is now.

csomar 15y ago

Backward compatibility. Millions (if not hundred of millions) of websites rely on jQuery, switching to a newer version that breaks old code will wreak havoc and make these sites unusable. But this shouldn't stop jQuery from improving. If you have read the article from the beginning, you'll see how the jQuery team was improving the binding functionality. It has a cost, certainly. Maybe there should be a jQuery version with no legacy code.

davej 15y ago
Yep, the best advice for a newcomer is to just use `.on()` and familiarise yourself with that API. You can ignore the other event handler methods because they're all just shortcuts or legacy methods.
- dmethvin 15y ago
  Exactly. It would simplify the documentation to simply deprecate everything but .on() but would that justify breaking all the existing code out there? Not to me. The old APIs need to stay around so that code continues to work.
  - cgoddard 15y ago
    They could deprecate the old methods and still keep them around as long as makes sense. There's no rule that deprecated methods have to be gotten rid of during the next major revision or anything.
  - cgoddard 15y ago
    Even if they excised the old methods from the code, hopefully no one is linking to jQuery trunk or something as their primary library. The old versions would still be around. Just some simple work might have to be done to update a web app to using the latest versions of jQuery.
- emehrkay 15y ago
  I like MooTools. When they added event delegation to their library, they simply modified the existing addEvent method to parse the event name instead of adding new method after new method -- seems like a more thought out approach. $(selector').addEvent('click:relay(selector)', fn)
emehrkay 15y ago
The overall api is strange. The each loops are backwards from the spec (key, value) instead of (value, key) and there are instances where it is key, value in jquery, there are instances where method names just don't make sense (I'd expect something like size to be dimensions etc), getters and setters as the same method, way too much argument overloading, inconsistent approach (selector.action, but wrap is the opposite of how the rest of the lib works). There is no kind of inheritance for their plugin architecture. These are just things off the top of my head. I feel like jQuery is the same as PHP when it comes to api, and I make a living doing PHP.
- mark_story 15y ago
  jQuery.map() jQuery.each() having their arguments has caused me more than a few WAT moments. One way I solve the issue around overloaded apis is by not using them. I just pretend .click() and friends just don't exist.
prolepunk 15y ago
Yet it breaks hilariously when you try to move from 1.3.2 to 1.4.4. I still have ONE script for which I have to deal with jquery-1.3.2.
jonknee 15y ago
> Maybe there should be a jQuery version with no legacy code. They're deprecating stuff, so it's just a matter of time. I think that's the sensible way to do things. http://blog.jquery.com/2011/11/08/building-a-slimmer-jquery/ http://blog.jquery.com/2011/11/08/building-a-slimmer-jquery/ They're also taking steps to be able and use Google Closure Compiler's advanced optimizations, which would let you build jQuery against your code and trim out everything that's not used. Pretty handy.
- nfriedly 15y ago
  > They're also taking steps to be able and use Google Closure Compiler's advanced optimizations... That is awesome, thanks for pointing it out!
jacobr 15y ago
A 2.0 release would be a reasonable point to potentially break legacy code.

v33ra 15y ago

Jquip is trying to make jquery less messy by splitting into separate modules.

fooyc 15y ago
But it failed to use a proper module format (e.g. CommonJS / AMD)

jsdalton 15y ago

> ...but it is not the library that Id choose first. Which library/libraries would you choose first, over jQuery?

maratd 15y ago
MooTools. Dojo. The herd has been thinned a bit over the last few years.
jacobr 15y ago
I would use Ender and pull together various micro-libraries/modules. http://ender.no.de http://ender.no.de
- jsdalton 15y ago
  That is very interesting. It looks like they even have a "starter pack" that approximates much of what jQuery does: http://ender.no.de/#jeesh http://ender.no.de/#jeesh Thanks.
  - euroclydon 15y ago
    I winder how it well it works with SVG?
oinksoft 15y ago
For a complete one-off, plain JavaScript and DOM. For a small, simple project, MooTools. For a large project, Closure Tools. jQuery's not a good choice for anything I work on, and its "God Object" API makes for repugnant code.

funkah 15y ago

I've been using Prototype for years and am now using jQuery more, and I have to agree. The knock against Prototype was that it modifies built-in classes, but I seriously doubt how much that actually matters, and as a programming library it makes much more sense to work with, I think. jQuery doesn't even offer very useful things like list comprehensions! You have to use underscore to get those.

emehrkay 15y ago
There is a grep method that does some stuff: http://api.jquery.com/jQuery.grep/ http://api.jquery.com/jQuery.grep/
tikhonj 15y ago
Actually, splitting out logical code from DOM manipulation code makes plenty of sense. Just because I'm using one does not mean I want the other and both stand on their own fairly well. This is even more important now that JavaScript is popular on the server--I can use Underscore there as well.

bdg 15y ago

> the more of a mess I see that it is. I started a joke project to mock the total mess that jQuery has become, http://cowbelljs.com/ http://cowbelljs.com/ . The performance hit from using jQuery is awful these days, it's become a monolithic framework aimed towards support for a hodge-podge of things rather than using best practices. A simple line of code such as this might be readable: $(".foo input[type=checkbox]:checked").live(function(e){fizzbuzz(e)}) But, the costs of that? You've just killed performance, your page is probably going to have laggy response and all kinds of event listener issues crop up as you keep working, leading to you using .die, .stopeventpropegation, .stopeventbubbeling, and return false all over the place in a futile attempt to manage your events. jQuery does a great job of letting you write less code, it also does a good job of abstracting away tasks and making things look like "magic", but it also really makes it easy to shoot yourself in the foot, with a tommy gun. jQuery creates a lot of undesirable effects, as far as I'm concerned: - People don't understand what their code does. - jQuery API is a mess, and version upgrades are hard - Best practices for a given task are not focused on, rather, "every practice" is accepted, and whatever blog post the JS novice read at the time becomes the method they write their code with (as a result, we almost never see .delegate() in use) - The library is huge. Yes, they brag about it being only 31kb minified, but that's huge! - jQuery code is slow. - Nobody understands how the DOM API works any more, and because sizzle makes it easy to select complex things the authors don't even bother writing semantic HTML, so we start to see <td id="Row2Cell2"> kind of things. - We have landed in a mess where ambitious people tightly couple their projects with an unstable API and practices that create sluggish pages. Sure, you can use jQuery correctly, but I'd rather use a micro-framework that complements JavaScript rather than attempt to replace it with tightly-coupled abstraction layers and memory hogging through event listeners and timers all over the place. The culture around it makes me really sad.

driverdan 15y ago
Most of your argument boils down to "jQuery makes it easy for shit developers to write shit code, therefore you shouldn't use it". No response necessary. > jQuery code is slow Compared to what? What parts are slow? Keep in mind it needs to support legacy browsers like IE6 before you answer those questions.

MatthewPhillips 15y ago

I don't use JQuery anymore at all. I just use element.addEventListener with a polyfill for attachEvent if I need to hit old IE.

bdg 15y ago
Poly-fill is the future. Someone's working on a DOM polyfill at the moment, it's unstable beta but looks promising: https://github.com/Raynos/DOM-shim https://github.com/Raynos/DOM-shim
- dkubb 15y ago
  I've often thought that frameworks should be built on top of standardized native apis, poly-filled when necessary. I imagine a time when browser specific hacks will be outside of the frameworks and "pushed down" to something lower level; ultimately shared across several frameworks rather than siloed off like it is now.