6 Reasons To Use JavaScript Libraries & Frameworks
I've seen many articles around the internet from JavaScript fundamentalists that advocate writing your own JavaScript code instead of using JavaScript frameworks like MooTools, Prototype / Scriptaculous, jQuery, MochiKit, YUI Library, and Dojo Toolkit, and I just cannot agree with their reasons for not using these spectacular frameworks.
Among other reasons, fundamentalists state:
- You don't learn the deep-down JavaScript code because you're using shortcut functions within the framework
- Javascript frameworks are bloated and contain a great amount of code you will never use
- You shouldn't make users download more than what's needed
- You shouldn't trust the code of others for your purposes (if you want it done right, do it yourself mentality)
Ridiculous. Don't listen to elitists! You SHOULD use JavaScript frameworks for the most important reasons.
Don't Reinvent The Wheel
Why write code that's already been written (better)? A good programmer is a lazy programmer, so be lazy. The tools are there -- use them.
Do More With Less Code
Most JavaScript frameworks provide function "chaining." Chaining allows you to do more with less code. Less code means less maintenance time, less download time, and less coding time. Check out MooTools chaining.
Save Time -- You Don't Code Your Own OS, Do You?
I love JavaScript as much as the next guy, but some programmers REALLY love developing JavaScript. Let the experts do the tough part, you take their work and make what you'd like of it.
Chances Are, You Aren't The Expert
As big as any programmer's ego is, there are people out there that are smarter, more inventive than you. Most Web Developers need to be a jack of all trades and it's difficult to keep up with every language when you're needed in every facet of a website's construction and launch. The minds behind the frameworks have their eyes on JavaScript daily -- trust in them.
Speed Thrills
The creators of these JavaScript frameworks have their own private pissing contest when it comes to JavaScript speed put a lot of effort into making sure their frameworks are fast. The first job of JavaScript for mass web visitor usage is to be fast -- users expect accuracy, speed is the most important part. Who's fastest today? Check out SlickSpeed.
Avoid Cryptic JavaScript Base Code
Why use JavaScript's default functions when you can use a framework's English-named functions? For example:
//standard JavaScript document.getElementbyId('mydiv').style.color = '#f00'; // camel-case the style! //mootools JavaScript $('mydiv').setStyle('color','#foo');copy//standard JavaScript document.getElementbyId('mydiv').style.color = '#f00'; // camel-case the style! //mootools JavaScript $('mydiv').setStyle('color','#foo');These are the reasons I use JavaScript frameworks. Need I say more?
Do you have more reasons? Please share them!
-->Related David Walsh Posts
Written By David Walsh
Debuted on Wednesday, September 5, 2007.
Feedback Welcome
Was this blog post helpful?
Brilliant Discussion
ktor on September 5, 2007 @ 7:53 am
7. Unified browser API, most of the time You dont have to think about browser compatibility because guys from Your framework took care (btw. I love jQuery).
Reply0
0
david on September 5, 2007 @ 8:25 am
Excellent point ktor! I don’t have every browser at my disposal but the creators of the frameworks test their code on every A-grade browser. I wonder how many “workarounds” they need to do (*cough* Internet Explorer *cough*).
Thank you for your addition!
ReplyCraig Francis on September 6, 2007 @ 3:42 am
While I agree with the reasons for using the frameworks, I have had several bad experiences:
- Just before website launch (tight deadline), the JS stopped working in a specific case, and I had no idea what the framework was doing in order to fix it.
- Quite a few frameworks rely on browser detection (userAgent), not on feature detection… this can cause issues when a new browser is launched (IE7), and you have to wait for the framework to be updated by someone else (instead of fixing your own code, which you already understand).
- Many of the frameworks trigger errors in the Firefox strict error checking mode (MooFX was, when I used it, guilty of this).
- Had a couple of cases (UFO Flash replace), which did not support the XML content type (document.write in FF1.5)… although I don’t use XML on the Live servers, its really useful in development to ensure your tags are nested/closed correctly.
- Having to use 2 or 3 frameworks as the one you originally built the site in does not have a feature another Framework provides… this really starts to increase the page size, and causes issues with over-rides on the “window.onload” etc.
- Frameworks can suddenly die… end of life, and there is no longer any more support.
But then again, I only do simple “helper” functions on websites, so I don’t really need the Frameworks… I’m sure in bigger, heavy JS sites, the Frameworks might help.
For now though, I like my JS, which has been written to be easily understood, instead of being small, fast and difficult to understand.
For some examples, see my website:
ReplyBill Goates on September 6, 2007 @ 4:41 pm
I will be the elitist then.
A good programmer is lazy, but he also knows exactly what all his code does. That includes the code of the framework he is using.
A single framework is maybe not bloated, it is if you only use one function out of it. Also a frameworks itself doesn’t do much, it provides some basic functions. For a full webapplication, you will need to include user controls and program logic. And before you know it, you created a monster using multiple frameworks and component libraries good for over half a meg of javascript files.
There is another solution. ‘Borrow’ only the few functions you actually need and understand, and slowly buildup your own library. If that’s still to much coding for you, I don’t think you should be using any frameworks or code professionally at all.
ReplyExcellent points Bill, though I disagree that frameworks shouldn’t be used professionally. Look at Apple (Prototype), Digg (Prototype), or cNet(MooTools).
If you know and understand the language thoroughly, a framework should be a great help.
Thank you for your post!
ReplyIt is my obviously failed attempt to sound elitist that went wrong, but I meant to say that if you don’t understand the code of a framework, don’t use it. And if you understand it, cut out the pieces you need.
ReplyBaz L on September 18, 2007 @ 7:29 am
I couldn’t agree more. I really agree with the lazy thing. That’s me.
Also, this “code it yourself” mentality has never really struck me and I’m glad.
If it’s done, it’s done. Especially since it’s done by a team of people concentrating on just that one thing over a period of several months.
Whereas if I were to do it, I would code something that I need in the next 20 minutes. There’s no way to put enough thought into things like that.
ReplyRob on April 26, 2010 @ 10:09 pm
I personally take a similar approach to Bill, in that I have “borrowed” and collected a small library of objects and prototype methods, which I have refined and tested over time with necessity.
The majority of the functionality I would use a framework for, I often find, can be distilled into a dozen or so prototype methods, ajax methods, cookie methods and DOM queries/manipulations. The majority of most frameworks, in my experience, is basically wasted space. The dollar sign function, for instance, is very easily reproducible.
These collected methods, in combination with my use of method chaining, and structuring my code with the module pattern, allow me to write extremely efficient, flexible and portable JavaScript.
That is not to say that a framework is not the right choice for many or most people. All claims of elitism aside, my philosophy is that if I understand 100% of my codebase, I can debug 100% of my codebase.
ReplyKieran on July 25, 2010 @ 9:05 am
My problem with frameworks is that, there are problems in them and parts arnt cover’d by all browsers. There has been a problem with jQuery and chrome AJAX for a long time, i know loads of websites that use jQuery and they will give any reason other then we cant code the JS out self. And the chrome problem is an easy fix in proper JS.
Also yes be lazy but for your laziness who is footing the bill ? the computer. the more lazy you are the more the clients computer has to work, and i for one hate slowness. Image if someone uses a phone to go on your site ? 1 page would be ok but if they start opening lots of tabs and everyone used libraries
Replyvladimir prieto on October 23, 2010 @ 4:15 pm
Mootools Chaining link isn’t right. the new link is:
http://demos111.mootools.net/Chain.Periodical
;)
Replyanthony on April 8, 2011 @ 4:02 am
There is pros and cons of the library. The simplicity and magic is that you get them all readymade on the plate instantly and mostly freely. No when you spend time to create such libraries, you need lots of time and resource to get such library.
Instead you can go through the features of some of the libraries, its coding and can decide before hand if you need to use this library. I guess there is no way that anyone can stop you from writing functionalities that are not there in the library. You can write anytime.
ReplyJoin the Discussion!
Share your thoughts without being a jerk! And wrap your code in
<code>tags, f00!
Learn to use a Library and Framework like JQuery or build your own library - What do you think?
No comments:
Post a Comment