please list all the things you hate about Jquery!
- ps i love it, just try to find some side effects. google didnt help
Printable View
please list all the things you hate about Jquery!
- ps i love it, just try to find some side effects. google didnt help
- Doesn't work very well in Netscape 3.
- Won't make you a cooked breakfast on Sunday morning.
- Pisses on your cereal too often.
This is very valid reason for not using it. Most of my clients turn out to be on Netscape 3..Quote:
Originally Posted by asheep_uk
- it can be a bit hard to read and understand jquery code. You can make things happen in 1 line, and you can chain actions. So someone that is reading your code might have problems with it. (I always have trouble understanding jquery plugins when I'm reading the sourcecode).
- I'm guessing here, that a lot of users might abuse the class selectors ($('.someclass')). I think that might be way slower than selecting by id $('#myid') or even better $(document.getElementById('hello')). Class selectors should be used when you're going to work with an item collection.
- It doesn't place nicely with mootools. And although you can use the jquery noconflict thingie, still, it might be hard if you're using some plugins or code you just don't want to modify (I've had this problem in modx, which uses mootools for the frontend quick edit module).
- you don't need to care about browser compatibility, as jquery takes care of that. So, when you use it, you might not notice that IE still sucks
- it's free, it goes against everything the RIAA has taught us!
- it's kind of a big library (50k ?) which you always need to include even if you need the most basic stuff. I'm not a mootools user, but I think they let you choose which parts of mootools you want to download, and then they create a single file for you with only the things you need.
argonauta, not to really cause an argument, but have you ever used jQuery?
Code formatting depends on the person writing the code. Yes, things can be chained together and in "one line". But that one line, can be neatened up and broken up across lines. Most programming languages and other libraries can be written in a messy way. It's all in the user.
Selectors in jQuery are extremely fast. So far that it's basically irrelevant.
Any plugin is written in it's own namespace. They won't conflict with other libraries.
And jQuery is ~19k.
yup, in about every project i have.Quote:
Originally Posted by MyFriendIsATaco
I'm kinda playing devil's advocate here, as I do like and use jquery. Yes, it's up to the programmer to create good code, clean code, readable code, but jquery is easy to learn and use, and makes it easy to write code that is harder to understand, and sometimes bad code.Quote:
Code formatting depends on the person writing the code. Yes, things can be chained together and in "one line". But that one line, can be neatened up and broken up across lines. Most programming languages and other libraries can be written in a messy way. It's all in the user.
For example:
not exactly good code there, but the more verbose version gives you a better idea of what you're doing: " get an element by id mylink, and when it's clicked, activateBomb is triggered"Code:function activateBomb(){
alert('hello');
}
var mylink=document.getELementById('mylink');
mylink.onclick=activateBomb;
Compare that to jquery:
For someone that has never seen jquery, that code is a bit harder to understand at first (although once you learn to read it, it is very easy). Now, let's say that the onclick function is more complicated than an alert, and has 100 lines. In the non-jquery version you can ignore all of the code of activateBomb, because the function name might be self explanatory. In the jquery version, it'd take longer for you to understand that the function will activate the bomb. Of course, you can either add a comment, or create the function somewhere else, so that you can read the code faster.Code:$('#mylink').click(function(){
alert('hello');
});
However, for what I've seen other people do, people using jquery will still use lots of anonymous functions, not organizing the code well. Again, it's not jquery's fault, it's the coder....but jquery makes it easy to code fast and not well.Code://i like this one the most
var activateBomb=function(){
//100 lines of code
}
$('#mylink').click(activateBomb);
And selectors in jquery are very powerful, but saying they're fast, it's not an excuse not to use them right. If you need to select one element, use by id, if you need to select several, limit your search (select the parent by id and the children by class). Besides the fact that it might be just a tiny bit faster (unnoticeable anyway)...the next person that sees your code will have a better idea of where will this divs be.Quote:
Selectors in jQuery are extremely fast. So far that it's basically irrelevant..
It's details, really, and again, it depends on the coder. But when the library makes it easy to be careless, any good coder will get lazy.
yes, mostly the conflicts come from the use of the $ function, which other libraries use as well. Jquery has the noConflict method, which is great. But still, specially because there's no quality control on jquery plugins (anyone can release a plugin anywhere for anyone, with good or bad code), you can't say it won't conflict with anything.Quote:
Any plugin is written in it's own namespace. They won't conflict with other libraries.
There can be conflicts: http://modxcms.com/forums/index.php?topic=33038.0
easy to solve, but they exist nevertheless.
oops, my bad...I guess google code is wrong, because they say jquery is 55.9kbQuote:
And jQuery is ~19k.
http://code.google.com/p/jqueryjs/do...s&downloadBtn=
I don't really care to hit over every point, because most aren't really arguable and neither of us really have specific benchmarks and numbers to prove anything. (At least, I don't care to throw together tests, nor do I personally care that much.)
But really, if code readability is your biggest issue, that's kinda irrelevant. Because like you acknowledge, it comes down to the code author. It shouldn't be a reason to say something is not good. It just means there's a tad of a learning curve. That's like saying an entire programming language is bad because someone doesn't understand the syntax.
Yes, it's probably better to select elements by ids vs classes, but that really comes down to the situation. Is it possible to only select with an id? What if there isn't? Most people don't slap ids on every single element. I'd probably end up using some other selector instead of using a class, but I get where you're coming from. It's an argument, but in my opinion, it's a weak one. It may be the difference of 2ms in execution time.
The file itself is 55.9kb, but gzipped, it's 19kb. Most server setups serve up gzipped files by default. At least, if anyone who knows anything set up your server. 19kb isn't anything to get worked up about. For the convenience, hell, it's so worth it. Look at Prototype, it's a beast.
And to add, Mootools, is about 65kb without gzip when I selected all of the features that I know of that jQuery has. Not a scientific measurement, but just a quick guesstimate.
jQuery can also be served up from Google: http://ajax.googleapis.com/ajax/libs.../jquery.min.js So can Mootools and Prototype, but it helps the overall argument for these JS libraries. The main benefit is global caching. If one site includes this file, and another does, it's cached in the users browser because it has been loaded from the same sever. It's the same file used on multiple sites.
About the class selector, most modern browsers now have a function called getElementsByClassName, which is implemented nativly, and is therefore really quick. Even the most complex selectors (try "[name~='a'] [href~='#login']" for example) is still really fast because modern browsers have the selectors API.
well I guess it's all good news! no wonder google couldn't find anything bad about it.
it sounds stupid. They should change it to , LifeEndingBoltOfLightningQuery or PurposelyRudeToYourGirlfriendsParentsQuery.
I believe Adobe own the copyright on that. Flash Player called my girlfriend's mum a whore the other day.Quote:
Originally Posted by AttackRabbit
haha!Quote:
Originally Posted by attackrabbit
On selector performance, here's an odd quirk - try creating a big page with a bunch of headings in it and then compare the performance of $(':header') vs the equivalent $('h1, h2, h3, h4, h5, h6') it seems :header misses out on a bunch of optimisations that are applied otherwise and using it turns out to be cripplingly slow.
A minor jQuery niggle - currently it adds an onunload event to the page which breaks fast back and forward navigation in browsers