Why the Overuse of Javascript Libraries?

[Jarrod1937]

This is javascript related, but i think it fits here better since its more of a rant/discussion.
Basically i am wondering why there is always such an overuse of javascript libraries? Whenever i am looking for some premade solution to save myself some development time, i always find "the script is only 7 KB! ... But requires jquery (76 KB minified)". Recently i was looking for a nice free livehelp ajax app to integrate directly within the site (think facebook chat), the smallest i was able to find was a 7 KB script, but again required a giant library. But, guess what? I was able to program one myself and the entire ajax script is 2.4 KB minified, no library.
It seems as if people are using the library as a shortcut to programming, which is ok by itself, but not when you're only using 1% of the libraries feature set. Perhaps performance isn't a concern for most?
Any thoughts here? Perhaps i am just missing something.

[JPnyc]

I know, it's the new thing, and frankly it makes me a little ill. As far as I can figure, companies prefer modular code that anybody can upkeep, as opposed to custom written solutions. But, just like buying a suit off the rack, it will never fit like a custom tailored one. Yet every job you see today, they want someone familiar with any number of the various JavaScript libraries. Nevermind that it's less efficient, they don't want something they don't understand being used. They want standardization.

[NogDog]

Maybe we need some sort of a JS library application that will generate the necessary javascript file based on what will actually be used, so that you then end up with a JS file with only the functions/classes you'll actually use. (I.e., sort of like if you program in a compiled language and use some 3rd-party library; then when you compile your executable it only compiles in the parts of that library your code actually uses.)

[thraddash]

Jarrod1937, you are my new best friend.

Everyone has access to all aspects of programming without the understanding of what is happening in the background. It would be beneficial to download a library or two and take them apart, find out how things fit together. But I know that not everyone is interested in the technical side of things, especially those who still know what sunlight looks like.

[tracknut]

Maybe we need some sort of a JS library application that will generate the necessary javascript file based on what will actually be used...

If it was real good, we could call it a "compiler". :)

There are all sorts of reasons folks might have for using interpreted languages, but "generates efficient code" isn't one of them.

Dave

[eval(BadCode)]

Because I don't need or want to know anything about javascript, just toss in 4 lines of code written for jquery and move onto something more important. It fixed up my 40 lines of code that wasn't working in IE7 or 8.

I would use that "js compiler" if you made it though.

[Jarrod1937]

Because I don't need or want to know anything about javascript, just toss in 4 lines of code written for jquery and move onto something more important.

Thats where i disagree. You, in my opinion, should always be aware of whats happening on your site. Those 4 lines of jquery may be hiding the underlying core functionality that it is making use of. In extreme cases this could take down your web server (aka, using long polling on an apache server). On the less extreme side, your users would appreciate the increased speed of the site.
Broadband is now mainstream and dialup is for the minority... but the "Broadband" connections out there may still be as low as 1.5 Mbs, which is quite easily to saturate.
However, i can see wanting to use something like jquery to ease the development time and testing stages... but as thraddash said, it is still quite worthwhile to dissect those libraries. You may find that the functionality you're using from it can be replicated with much less overhead.

[Jarrod1937]

I know, it's the new thing, and frankly it makes me a little ill. As far as I can figure, companies prefer modular code that anybody can upkeep, as opposed to custom written solutions. But, just like buying a suit off the rack, it will never fit like a custom tailored one. Yet every job you see today, they want someone familiar with any number of the various JavaScript libraries. Nevermind that it's less efficient, they don't want something they don't understand being used. They want standardization.
Thats actually something i've never considered. Even though it does make sense from a business standpoint, it is not the best method (short or long term). As mentioned, the solutions tend to be quite bloated, and even though you're using a library with a rather large feature set, the end result may actually be less adaptive as you're constrained to the library rather custom code. Thankfully, my main job requires me to design for site speed, as its an ecommerce site where speed increases conversion rate, so i am often allowed to seek out or build the most efficient method i can.

[JPnyc]

I think it also cuts down development time, particularly in the event of extremely complicated functions. But I'm going to make a bold prediction here. I predict this fad will pass as it becomes more commonly known just how inefficient it is. Right now it's the fashion. We know how fickle that is.

[eval(BadCode)]

26.5 KB + lets say... another .3 for my 4 lines of code. My 4 lines being exclusively ajax to take care of M$IE trouble I had when writing it myself.

You may find that the functionality you're using from it can be replicated with much less overhead.

Probably 26.4 less KB and 1 less request.
I tried and failed. But at least I tried.

In extreme cases this could take down your web server (aka, using long polling on an apache server). On the less extreme side, your users would appreciate the increased speed of the site.

I have bigger problems than 26KB.

I have style rules so inefficient that there's 1 for every Chinese citizen. I have 4 <style> tags. I have 2 jquery plug-ins. What does 1 of them do? I don't know, haven't had time to figure it out yet. There's google javascript which probably returns every web bug and it's cousin. There's a meta tag for content and it has no values. 15KB of comments. An html comment called "random seed" and its the same for every page (that's my fav). Every file in the web directory has a .LCK file for it (if you don't know what this is, it's a dreamweaver file that tells you someone else has checked it out). So I made an alias called "WTF" in bash to recursively remove them if they're over 3 days old. My guess is that dreamweaver crashed when it was closing because it couldn't handle removing all of the .LCK files it created. I know who keeps doing it too, it has him name inside of THOUSANDS of .LCK files, they're in every directory.

More like crash the worldwide network.

http://www.yodaspeak.co.uk/yoda-small1.gif So reckless these days, the youth is. Left me with this mess they did. From Craigslist, they come.

Better than subway.com

[Jeff Mott]

I hope everyone is willing to hear a viewpoint from the other side of the fence. :)

Sounds like most of the positives have been mentioned, that libraries like jQuery tend to cut development time and promote modularity and standardization.

The most worrisome negative I'm hearing is the added K-weight.

jQuery weighs in at 26K when minified and gzipped (which it always should be in production environments). That's in the same weight class as, I'd say, a single medium-large image. And though that's sizable, 26K is still a far cry from "inefficient."

Also, there's a lot of performance research (http://developer.yahoo.com/performance/rules.html) available these days. And though K-weight is certainly a factor, it isn't the most crucial.

Consider the performance of e-commerce site factorydirectcraft.com. (http://www.webpagetest.org/result/110110_Y8_86PQ/1/details/) Most of this page's load time comes from HTTP requests for images. Notice how much time is spent just waiting for the first bytes to arrive. jQuery is in there, but it's by no means the performance killer it's made out to be.

I certainly agree that it's important to be mindful of performance, but we need to focus on areas that have the greatest impact. jQuery, it turns out, comes with very little cost to performance.

[JPnyc]

Well there's a little more to it than just load time. There's resource use to be considered on the client end. I've seen some of these functions and at least in the cases I viewed, I could've solved the issue with a lot less code. People are using these libraries for even remarkably simple things you could write yourself in 1/2 hour.

[tracknut]

I would add that this isn't a new trend at all, at least for the industry as a whole. 30 years ago (geez, has it been that long...) I was developing embedded graphics code, and we always had situations where various developers wanted to use libraries of code for easy functionality adds and faster time to market, whereas other developers wanted to code everything in assembly, and not use any pre-developed solutions, for speed and code size. This was in an era where we needed everything to fit into 128kb, typically, so usually the assembly/hand code vote won out.

Most of my career was in the programming field, and I've seen this same trend all along. Frankly in virtually every case, additional functionality wins over dissecting, optimizing, and re-coding on one's own. Since that one instance of embedded code though, the functionality/get it out the door vote has always won the argument. It's a business, and using up an extra 26k here or there is far less important than getting product out the door.

For those not in it for a business, it becomes (IMO) largely a hacker's hobby if one really wants to know what's going on within a whole system. A small percentage of people have that interest, but most will be more focused on additional functionality rather than performance, code size, or other hacker's pursuits.

Dave

[Jarrod1937]

I hope everyone is willing to hear a viewpoint from the other side of the fence. :)

Sounds like most of the positives have been mentioned, that libraries like jQuery tend to cut development time and promote modularity and standardization.

The most worrisome negative I'm hearing is the added K-weight.

jQuery weighs in at 26K when minified and gzipped (which it always should be in production environments). That's in the same weight class as, I'd say, a single medium-large image. And though that's sizable, 26K is still a far cry from "inefficient."

Also, there's a lot of performance research (http://developer.yahoo.com/performance/rules.html) available these days. And though K-weight is certainly a factor, it isn't the most crucial.

Consider the performance of e-commerce site factorydirectcraft.com. (http://www.webpagetest.org/result/110110_Y8_86PQ/1/details/) Most of this page's load time comes from HTTP requests for images. Notice how much time is spent just waiting for the first bytes to arrive. jQuery is in there, but it's by no means the performance killer it's made out to be.

I certainly agree that it's important to be mindful of performance, but we need to focus on areas that have the greatest impact. jQuery, it turns out, comes with very little cost to performance.

I see you've been doing some research there ;-)
But if you look around, jquery is loaded conditionally and used only when needed to for more complex items. However, i've seen some sites load jquery, and sometimes another library too, on every page request because it is needed for their basic code. Now, this may seem moot if you factor in page caching mechanisms, but you should know that page caching doesn't always work as intended, so you must factor in the file(s) being downloaded every time, or at least an extra 304 per page request.
Though, in my opinion, you should use jquery's file size without gzipping (which is a must). That is because not all browsers support gzipped content and those that do can still request content without it (firewalls and some anti-virus apps can mess with the headers so that it can analyze the contents non-gzipped, users can turn it off...etc). So the actual size is 54 KB (or 76 KB depending on the version). That can add to the total page load time, and the reasoning is, why use it and thus load it when you don't have to? This is especially true for my most recent case, where the end result was a 2.4 KB script, which is so small you might as well load it inline on the page its used on (potential savings of 200-400 ms for page load time depending on user location).

Though, from what i can tell the main consensus is that the libraries, despite their downsides, provide such a boost in productivity that their use is worth it. So at least i have my answer. However, my question has never been "Why the use of javascript libraries"... its been "Why the overuse of javascript libraries". If you overuse javascript libraries and never learn the underlying code you're looking for trouble in the future when the project requirement is not to use a library or to use a different one. You also leave yourself vulnerable as you lack an understanding of the underlying code and so you could leave yourself open to attack and not know it. You also add in the extra KB and http requests when it may not even be needed. And lastly, as mentioned, the functions themselves may not be as efficient for your particular use.
By all means feel free to use a library (as i do myself), but not for every occasion, especially when the functionality can easily be programmed yourself. The overuse of the libraries is the issue i'm getting at.

[Jarrod1937]

Most of my career was in the programming field, and I've seen this same trend all along. Frankly in virtually every case, additional functionality wins over dissecting, optimizing, and re-coding on one's own. Since that one instance of embedded code though, the functionality/get it out the door vote has always won the argument. It's a business, and using up an extra 26k here or there is far less important than getting product out the door.

This i can understand as it makes since. If you have a deadline and you don't have the time to mess with all the intricacies, then why not use a library that'll ease the development?


For those not in it for a business, it becomes (IMO) largely a hacker's hobby if one really wants to know what's going on within a whole system. A small percentage of people have that interest, but most will be more focused on additional functionality rather than performance, code size, or other hacker's pursuits.

Now this i just find hard to understand. If you lack the understanding of the core functionality the library bases itself on, then you're just limiting yourself to what you can do. To me it would seem that understanding whats going on in the entire system would lead to to additional functionality (and security) down the road. Not to mention that you can attain this functionality with the pluses of better performance, code size...etc. Please forgive me if i had too vaguely stated my initial position, my main curiosity is not just about performance (though that was a biggy), it was mainly about why so many rely on a library for something that is already close to the core functionality of the language itself (hence the comment "but not when you're only using 1% of the libraries feature set"). Its almost like using a "calculator" library in c++ to do arithmetic manipulations, sure its interface may seem cleaner compared to the core c++ code, but the functionality provided is already so close to the base language that you might as well use that. Sorry if i seem argumentative or preachy, just trying to get a grasp on other's thinking toward these topics.

[tracknut]

Now this i just find hard to understand. If you lack the understanding of the core functionality the library bases itself on, then you're just limiting yourself to what you can do. To me it would seem that understanding whats going on in the entire system would lead to to additional functionality (and security) down the road. Not to mention that you can attain this functionality with the pluses of better performance, code size...etc.

If you'll forgive another personal trip down memory lane... I met my future wife as a programmer, when they put us on a project together. Typical programmer/analyst type jobs, both of us. Go see the customer, write up and agree on a requirements/scope document, crank out the code, sign it off. As we started doing this stuff, it became clear that she was far better than I at the "go see the customer" half of the job, and I was far better at the "crank out the code" part of the job. That happens, people aren't all the same. But my point is that neither of us really were desperate to "be the best we could" at the part the other was good at. So while this discussion might be focused on why she didn't want to spend lots of time/brainpower on becoming a hot shot programmer, and yes she would easily fit into your "overuse of libraries" category, she could just as easily be typing on a forum called WorkWithPeople.com right now, where they're talking about why someone would care to understand exactly how the computer works, when there are tools like content management systems, libraries full of nifty routines, and god forbid, clip art :) available, all for free.

Please forgive me if i had too vaguely stated my initial position, my main curiosity is not just about performance (though that was a biggy), it was mainly about why so many rely on a library for something that is already close to the core functionality of the language itself (hence the comment "but not when you're only using 1% of the libraries feature set"). Its almost like using a "calculator" library in c++ to do arithmetic manipulations, sure its interface may seem cleaner compared to the core c++ code, but the functionality provided is already so close to the base language that you might as well use that. Sorry if i seem argumentative or preachy, just trying to get a grasp on other's thinking toward these topics.

I'm not sure whether my example relates to your last section here, but this sounds a bit like "once you have a hammer, everything looks like a nail". Once you install JQuery, perhaps the answer to many questions is "JQuery can do that"?

Dave

[Jarrod1937]

If you'll forgive another personal trip down memory lane... I met my future wife as a programmer, when they put us on a project together. Typical programmer/analyst type jobs, both of us. Go see the customer, write up and agree on a requirements/scope document, crank out the code, sign it off. As we started doing this stuff, it became clear that she was far better than I at the "go see the customer" half of the job, and I was far better at the "crank out the code" part of the job. That happens, people aren't all the same. But my point is that neither of us really were desperate to "be the best we could" at the part the other was good at. So while this discussion might be focused on why she didn't want to spend lots of time/brainpower on becoming a hot shot programmer, and yes she would easily fit into your "overuse of libraries" category, she could just as easily be typing on a forum called WorkWithPeople.com right now, where they're talking about why someone would care to understand exactly how the computer works, when there are tools like content management systems, libraries full of nifty routines, and god forbid, clip art :) available, all for free.

Haha, point taken, i may just be being a bit narrow minded with my view on the subject. Different personalities, strengths and interests all lead to varying perspectives on such issues, including ones that are quite the opposite in nature.

[Jeff Mott]

my main curiosity is not just about performance (though that was a biggy), it was mainly about why so many rely on a library for something that is already close to the core functionality of the language itself (hence the comment "but not when you're only using 1% of the libraries feature set").

I don't encounter this scenario often in my job, so I can only speculate... but I'd think people are fine using jQuery for small tasks because, frankly, jQuery has a small footprint. Despite all the ranting about performance, jQuery's impact is actually very small when measured with net tools, and even smaller when measured by users' perception.

So why use jQuery when you only use 1% of the library? Why not? -- is the answer. Because the downsides are almost nonexistent.

[Jeff Mott]

Maybe we need some sort of a JS library application that will generate the necessary javascript file based on what will actually be used, so that you then end up with a JS file with only the functions/classes you'll actually use. (I.e., sort of like if you program in a compiled language and use some 3rd-party library; then when you compile your executable it only compiles in the parts of that library your code actually uses.)

Interestingly, most libraries now have loaders, so you can dynamically load only the functionality you need.

For instance...

YUI
YUI().use('dd', 'anim', function(Y) {
// Y.DD is available
// Y.Anim is available
});

Closure
goog.require('goog.dom');
goog.require('goog.editor.Plugin');

Strangely, jQuery is one of the few libraries that still doesn't have a loader.

[sohguanh]

Strangely, jQuery is one of the few libraries that still doesn't have a loader.

I was suspecting could it be other competing JavaScript libraries split their functionalities into different JavaScript files. Then depend on which you want, they only serve that JavaScript file to you and not the rest of them?

In contrast JQuery code is all into a single file. This mean it have some problem duplicating the "dynamic loader" concept.

I think this is more of design issues rather than JQuery being bloated (in fact I think 26K+ is ok for me actually).

I also agree if one only use 1% of JQuery, then just write your own version for that small functionalities. But if you are going to use say 30-40% it is more than justifiable to go for a full-blown JavaScript libraries.

Please note this library concept isn't anything new. In Java, C, C++ etc etc using pre-built libraries already exist and JavaScript ain't no exception either. It could be JavaScript has progressed so far that it is behaving more like those full-blown programming languages.

This is good progress for JavaScript! It want a place to be side by side with those traditional programming languages cousins. JavaScript has grown up :P