4 ms·

> 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/ . Th

by 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.
- bdg 15y ago
  Your post reads as if there's an undertone where you're really defensive of the library. If that's the case, there's no point discussing this further, however, lets go ahead anyway. > Most of your argument boils down to "jQuery makes it easy for shit developers to write shit code, therefore you shouldn't use it". Shit developers will write shit code regardless of a library, just as good developers will write good code. The problem is that jQuery provides an abstraction to what's actually happening, and how the DOM treats events in the browser. The present status-quo of jQuery code boils down to abuse of innerHTML="foo", and binding events onto individual elements rather than bubbling up to a parent listener. As I said, the culture around jQuery propagates the web with sub-standard code simply because it attracts cut+paste+tweak developers who don't really understand jQuery, never-mind what's going on behind the curtain, or how to use events in such a way that can lead to long-term maintainability. It discourages best practices because it's really good at hiding reality from developers. Even if you're a good developer, why should you use jQuery? You aren't necessarily getting anything more done than usual if you know what you're doing and using a micro-framework under 10kb, or expand your framework with one of the modular fameworks that let you do so. Don't like Sizzle selector engine? Use something else. > Compared to what? What parts are slow? Keep in mind it needs to support legacy browsers like IE6 before you answer those questions. Compared to plain old JavaScript. Almost all of it is slower, modifying the DOM, binding events, AJAX has been known to expose memory leaks (an on-going problem in other places as well), jsperf is full of people who set up test cases to see the difference between jQuery and vanilla JS: http://jsperf.com/browse http://jsperf.com/browse Two contrived examples, feel free to explore some more... 1. http://jsperf.com/queryselector-vs-getelementbyid-perf http://jsperf.com/queryselector-vs-getelementbyid-perf 2. http://jsperf.com/modern-js-vs-jquery-append http://jsperf.com/modern-js-vs-jquery-append Legacy support should not be a unilateral feature that every browser has to fell the pain of, it goes against the grain of progressive enhancement practices. I don't really buy into the whole "we have to support IE6" any more that it's now under 1.5% everywhere that's in my market. However, legacy support can easily be provided through polyfills that append the DOM methods, and standard JS object prototypes, sometimes these are called shims as well, it supplements a broken legacy browser-native API with something that matches modern implementations, or in some cases, normalizes spec implementation discrepancies. This means I don't have to check for activeX object every time I goto make an AJAX request, or other costly things.
strickjb9 15y ago
I see jQuery misused every day, I'm pretty sure I was one of those terrible people a couple years ago. Since then I hardly use jQuery anymore except for delegate() and that's only because I haven't explored other libraries to replace it. jQuery, if used responsibly, is still a good library. Unfortunately, you are correct that the culture around it stinks. jQuery is the tool of choice for bad developers to write bad code.

by bdg 15y ago

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.

bdg 15y ago
Your post reads as if there's an undertone where you're really defensive of the library. If that's the case, there's no point discussing this further, however, lets go ahead anyway. > Most of your argument boils down to "jQuery makes it easy for shit developers to write shit code, therefore you shouldn't use it". Shit developers will write shit code regardless of a library, just as good developers will write good code. The problem is that jQuery provides an abstraction to what's actually happening, and how the DOM treats events in the browser. The present status-quo of jQuery code boils down to abuse of innerHTML="foo", and binding events onto individual elements rather than bubbling up to a parent listener. As I said, the culture around jQuery propagates the web with sub-standard code simply because it attracts cut+paste+tweak developers who don't really understand jQuery, never-mind what's going on behind the curtain, or how to use events in such a way that can lead to long-term maintainability. It discourages best practices because it's really good at hiding reality from developers. Even if you're a good developer, why should you use jQuery? You aren't necessarily getting anything more done than usual if you know what you're doing and using a micro-framework under 10kb, or expand your framework with one of the modular fameworks that let you do so. Don't like Sizzle selector engine? Use something else. > Compared to what? What parts are slow? Keep in mind it needs to support legacy browsers like IE6 before you answer those questions. Compared to plain old JavaScript. Almost all of it is slower, modifying the DOM, binding events, AJAX has been known to expose memory leaks (an on-going problem in other places as well), jsperf is full of people who set up test cases to see the difference between jQuery and vanilla JS: http://jsperf.com/browse http://jsperf.com/browse Two contrived examples, feel free to explore some more... 1. http://jsperf.com/queryselector-vs-getelementbyid-perf http://jsperf.com/queryselector-vs-getelementbyid-perf 2. http://jsperf.com/modern-js-vs-jquery-append http://jsperf.com/modern-js-vs-jquery-append Legacy support should not be a unilateral feature that every browser has to fell the pain of, it goes against the grain of progressive enhancement practices. I don't really buy into the whole "we have to support IE6" any more that it's now under 1.5% everywhere that's in my market. However, legacy support can easily be provided through polyfills that append the DOM methods, and standard JS object prototypes, sometimes these are called shims as well, it supplements a broken legacy browser-native API with something that matches modern implementations, or in some cases, normalizes spec implementation discrepancies. This means I don't have to check for activeX object every time I goto make an AJAX request, or other costly things.

strickjb9 15y ago

I see jQuery misused every day, I'm pretty sure I was one of those terrible people a couple years ago. Since then I hardly use jQuery anymore except for delegate() and that's only because I haven't explored other libraries to replace it. jQuery, if used responsibly, is still a good library. Unfortunately, you are correct that the culture around it stinks. jQuery is the tool of choice for bad developers to write bad code.