Just use it. There's no reason not to - it's fairly lightweight, and even if you don't "need" it on this project, you might on the next. Better to stay familiar with it instead of mucking around with bare javascript.
Really? 93kb of code is lightweight? Yeah I know it gzips smaller, but that's still not what I'd call "ligthweight". It's not bloated, but it's certainly not a micro-lib.
> you might on the next
I think this might miss the point. If you're just writing code on sites, sure, consider jQuery. But if you're creating a library or framework that thousands of others may use, your decision to pick jQuery is making that choice for THEM, which means you should think about it a lot more closely.
It's not then about whether you might like it "next time", but whether the people using your lib/framework will likely need jQuery. That decision should not be made glibly or lightly.
Especially if you're only using a small portion of that 93kb of jQuery, and could just "do it yourself".
> Really? 93kb of code is lightweight? Yeah I know it gzips smaller, but that's still not what I'd call "ligthweight". It's not bloated, but it's certainly not a micro-lib.
use a cdn, anyway most browsers support gzipped requests.
> Especially if you're only using a small portion of that 93kb of jQuery, and could just "do it yourself".
"do it yourself" if you can be sure it will work on as many browsers as jquery.
Do you think most people have the capability to test their DOM related code on as much browsers ? or are you telling people to ship broken code ?
jQuery is one of the only library that is tested on a wide range of devices. But you dont care ,you are not responsible for people's failure to deliver code that works everywhere.
And it's not just a IE8 issue. Some mobile browsers have serious DOM issues that will never be fixed ( Android 2.3, safari ), and these cases are handled by jquery. Can you fix people's "diy" code? no, so dont give developpers bad advices.
My advice is, if you dont have the capability to test on a wide range of devices , dont "DIY" , your code will be break for sure.
It's not lightweight - the full library is just over 80 KB for 2.x. If you have devs good enough to handle it, it should be avoided as much as possible because jquery is often significantly inefficient.
Not to say there aren't instances where jQuery is fine to use. I use it for some apps as well. I don't feel the need to lie on jQuery as a crux for every problem though, especially having a decent understanding of cross-browser issues.
I think this is something worth considering by people.
Doesn't that ignore the increased parsing time of the larger JavaScript library compared to image rendering and the fact that loading & parsing JavaScript blocks page rendering? Seems like the arguments linked only focus on the network.
I only use jQuery on Websites, mostly because it comes bundled with Rails. But most of my JavaScript code runs either in specific WebViews, on the server or special OSes like Firefox OS. Especially on mobile I found that jQuery (mobile) slows down everything significantly.
> In Q1 2013, average connection speeds on surveyed mobile network operators ranged from a low of 0.4 Mbps to a high of 8.6 Mbps. Only nine operators demonstrated average connection speeds in the aforementioned broadband category while 64 more operators showed average connection speeds above 1 Mbps.
My 80% number was hyperbole, but I do think the data supports that on world-wide average, mobile connections are drastically lower, and so making assumptions about a file size downloading quickly on fast broadband is ignoring an increasingly important part of the web traffic, which are years behind wired connections in terms of speeds.
16 comments
[ 4.0 ms ] story [ 45.2 ms ] threadReally? 93kb of code is lightweight? Yeah I know it gzips smaller, but that's still not what I'd call "ligthweight". It's not bloated, but it's certainly not a micro-lib.
> you might on the next
I think this might miss the point. If you're just writing code on sites, sure, consider jQuery. But if you're creating a library or framework that thousands of others may use, your decision to pick jQuery is making that choice for THEM, which means you should think about it a lot more closely.
It's not then about whether you might like it "next time", but whether the people using your lib/framework will likely need jQuery. That decision should not be made glibly or lightly.
Especially if you're only using a small portion of that 93kb of jQuery, and could just "do it yourself".
use a cdn, anyway most browsers support gzipped requests.
> Especially if you're only using a small portion of that 93kb of jQuery, and could just "do it yourself".
"do it yourself" if you can be sure it will work on as many browsers as jquery.
Do you think most people have the capability to test their DOM related code on as much browsers ? or are you telling people to ship broken code ?
jQuery is one of the only library that is tested on a wide range of devices. But you dont care ,you are not responsible for people's failure to deliver code that works everywhere.
And it's not just a IE8 issue. Some mobile browsers have serious DOM issues that will never be fixed ( Android 2.3, safari ), and these cases are handled by jquery. Can you fix people's "diy" code? no, so dont give developpers bad advices.
My advice is, if you dont have the capability to test on a wide range of devices , dont "DIY" , your code will be break for sure.
Not to say there aren't instances where jQuery is fine to use. I use it for some apps as well. I don't feel the need to lie on jQuery as a crux for every problem though, especially having a decent understanding of cross-browser issues.
I think this is something worth considering by people.
also, https://twitter.com/trek/status/227082154109186049 and http://fourkitchens.com/blog/2013/04/24/one-less-jpg/
- Other devs in the team are using it
- Unless it's a small pet project, you will probably need it down the road even if you don't need it now
- Minified jquery is like 32kb. That means literally nothing in modern web. Unless you are from 1995 using 2G connection, this doesn't matter.
- Modern browsers are good. It's going to handle jquery like a champ. Don't worry.
- jQuery code is probably better than yours.
- Lots of 3rd party libraries have jquery as a dependancy.
Reasons not to use jquery and use just javascript
- Want to learn javascript
- Writing a library or framework and you don't want jquery dependancy
- Working on a very small website
Or on like better than 80% of all mobile data connections in the world. But mobile is so niche, right? No need to worry about them.
http://www.diffusedonline.com/wp-content/uploads/2012/04/pag...
http://thenextweb.com/insider/2013/07/23/akamai-average-inte...
My 80% number was hyperbole, but I do think the data supports that on world-wide average, mobile connections are drastically lower, and so making assumptions about a file size downloading quickly on fast broadband is ignoring an increasingly important part of the web traffic, which are years behind wired connections in terms of speeds.
yawn