Question by : Isn’t using JQuery instead of Javascript just a complete waste of bandwidth?
I only rely on about 10-20 self-written Javascript functions for any custom built site anyway (form validators, whitespace strippers, ajax xml loaders, etc.). Is it really worth using JQuery just to ensure compatibility with ALL modern browsers – even though I test on as many as possible anyway – given the additional bandwidth JQuery requires?
Visage – I don’t intend to write functions that are the equivalent of JQuery. I intend to write the same kind of Javascript I’ve been writing since 1996 (albeit with a huge break between 2002 and 2009 because I went into a different line of work), but wondering why I should port it to JQuery.
As an example, I have twenty javascript functions here that I wrote myself. Most are trivial (regexps dealing with whitespace, form validators, etc.), but there are others which process XML being returned from server side Python scripts that I also wrote.
The file size of the JS file is 8.67KB.
If I wrote equivalent code in JQuery, the code size would perhaps be a little smaller (probably about 6KB), but the (minified) JQuery.js script is 74KB. So you’re talking a bandwidth increase about 900% to perform exactly the same tasks.
Surely then, JQuery is only really worthwhile for extremely large websites?
Best answer:
Answer by Visage
Hardly. The production version of JQuery is very minimal, and even if you were to write your own functions that were the equivalent of JQuery, I seriously doubt you could do it in a less amount of kb and with the same degree of compatibility. Really, JQuery is quite minimal. I’ve never seen performance impacted too much by it to even really care.
Know better? Leave your own answer in the comments!
Frameworks such as JQuery are very important in programming. Depending on the complexities of your JavaScript applications, you could benefit from using a framework such as JQuery.
There should not be a huge increase in bandwidth if using best practices when developing with JQuery. Besides, bandwidth is usually not an issue with proper caching. Using a framework such as JQuery will not increase bandwidth dramatically unless–for some reason–users are required to download your scripts at every request.
Even if there was an increase, the slight increase would not be a waste. JQuery helps you produce content that is widely accessible and has been proven. Using frameworks allows you to take advantage of code that has already been tried and tested rather than “reinventing the wheel.”
Follow best practices and you can benefit exceedingly by using strong frameworks such as JQuery.
Check out the following reference on JQuery best practices: http://www.smashingmagazine.com/2008/09/16/jquery-examples-and-best-practices/
Use the google Jquery, unless you work on something highly secure or seriously distrust google or are DoD or something. Almost everyone will have it cached already.
Google doesn’t mind people doing this: http://code.google.com/apis/ajaxlibs/documentation/
If your stuff works, then it’s good. The way you’re doing it is frequently called “Vanilla JavaScript” these days. The problem is does your script *really* work or does it only work in FF3, IE8, and Opera 10; and DO YOU CARE?
You may also find $ (‘someID’) ends up looking a lot nicer in your code than document.getElementById(‘someId’)
It is heavier, that’s true, but you can always mix them. JavaScript is full of suck. I assume you have the Rhino book, compare that to the new “JavaScript: the good parts” and you’ll see a huge amount of things you can do; you shouldn’t.
Bandwidth and related performance issues aren’t usually the big issue at shops that use jQuery or any of the other JS frameworks. More often, it’s a matter of minimizing developer time and the related costs. The majority of developers who are fulfilling the UIE role are PHP, Java, ASP, etc. developers. They are not JS experts. In other cases, where the guy in the UIE hat isn’t a developer in a server-side language, he’s often not really a programmer at all; that is, many UIEs know lots about HTML and CSS and little of JS, except in the script-kiddie sense (they can Google up a script and barely tweak it to suit their own needs).
When it comes to performance-tuning and bandwidth reductions, there’s a lot of lower hanging fruit than JS frameworks. You can optimize images, reduce the number of images, employ sprites to cut the number of GET requests, defer loading content into background and Ajax processes, etc.
My shop uses jQuery for CMS sites, since the open source CMS we employ for that purpose requires it on the client side. I do not ever use jQuery otherwise.
My major objection to the big frameworks is that they are most frequently used by people who don’t understand what’s going on under the hood. This may save time in the short run but leaves projects at great risk, if anything goes wrong; that is, you’ve got a very complex app in the hands of people who don’t have the expertise to support it. I am ever (evilly) amused by requests for help that being like, “my app was working perfectly with {some JS library} until I added {some other JS library}, but now it’s broken.” These guys will not be fixing their own problems.
Bottom line is that’s it’s a spectrum. At one end, if you’re using significant portions of jQuery and have a fair grasp of JS, it’s probably not a waste of bandwidth (tho’ other risks obtain). If you need only a little JS functionality or are a JS guru (I am), it’s probably a waste.