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');
These are the reasons I use JavaScript frameworks. Need I say more?
Do you have more reasons? Please share them!
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).
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!
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.writein 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.onloadetc.– 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:
http://www.craigfrancis.co.uk/features/code/jsLinkedWidget/
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.
Excellent 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!
It 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.
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.
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.
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
Mootools Chaining link isn’t right. the new link is:
http://demos111.mootools.net/Chain.Periodical
;)
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.
Most of the time, I’d advocate learning the language (that’s how I learned anything that I do know up to this point) such as PHP or Java by handwriting it. The case of JS is quite…special. It’s a language that is very unfamiliar in its inner workings, because it thinks much different from other C-style languages.
JS is not only very different despite having a PHP/C like syntax, the browsers are also plagued by differences in their implementations of JS. These issues combined create massive headaches and is often the reason people don’t want to learn JS at all.
My suggestion is to read David Flannigan’s book on the language, Crockford’s book, and write some basic JS to get the hang of it. Once you get familiar with the basics of the language, I would suggest going on to a library (and you can even learn JS then).
You just need to get features created on the client and that is what JS does, frameworks make it easy and they make JS beautiful (more beautiful than any vanilla JS).
I decided to learn MooTools a while ago, I’ve been converted by this site’s awesome admin. :)
I want to write code that is unobtrusive, reusable, and best of all, free from the differences of browser implementations (or at least “almost” free).
Not only that, organizations such as Google/Youtube are making use of them and jobs are hiring people who know them because of what they offer web applications. It’s cheaper, smarter, faster, and gives better results. I used to be pretty elitist myself, I still am when it comes to learning most technique, but not in the special case of JS (even though I’m still going to be learning the original language).
When it comes to learning most technology*
I’ve been coding one thing or another for 35 years, and I have to agree with the author. No matter what anyone says, there is a place for these libraries.
Yse there is always a trade off. The more functionality built in, the more weight it may have. Any framework has it’s “method of operation” that may or may not suit your needs. And yes, the more feature rich you build anything, the less flexible it becomes. But if you design websites, then you want features, and you know what flexibility you are willing to trade.
As for moving the cost of work to the client PC, thats an issue for performance QC, and once again we have to remember that the tradeoff is possibly hours or days of coding and testing something that you are simply not that familiar with, compared to an incredibly reduced time touse the libraries.
And for all those that doubt this, I would suggest you return to coding 80×86 assembler in edit.exe, or code your word processing documents in RTF by hand.
Lets face it, the smart coder is an integrator, using the best of class, and not starting over from scratch every time.
I couldn’t agree more. But as much as possible it’s still advisable to learn javascript’s fundamentals.
Some reasons against you :
– No need to be programmer for using jquery and those thousands plugin, code in given everywhere in internet. If you love your website developper job and you want to keep it, you don’t have some interests to make website dev easier (it count too for CMS)
– When i want a javascript touch in a page, the most often, my javascript code minified and gzipped is less than 2kB. jQuery weighs 32kB. 32kB of javascript navigator must compile every time…
I have more and more reason but i want to nuance a little : if i dont know how to do something in javascript , if i have no time and if jQuery or other make it easier, i will take it…
However, it’s only engage me, if you aren’t able to product code faster than frameworks in case of light scripts, you have interest to use them, you’re right.
the use of frameworks is awesome in any programming language especially in javascript…frameworks make people more productive and saves time….ye know life is too short to spend it reinventing the wheel when the wheel is of minimal value to anybody…lol
Unless your building a large complex single web page application I don’t see the point in these frameworks at all. Simpler to stick with the languages as they are and use jquery.
Why re-invent the wheel for simple form validation? Since when did this need a framework?
Why re-invent the wheel for simple form ajax posting and response processing? what success: & error: in jquery not good enough?
Why use a client side router? Especially when you can pickup GET params via js? I also don’t like the security of aspect of client side routing.
Why re-invent the wheel for simple page styling and css? Since when has this ever been complicated? (till now)?
If you know HTML, CSS & JavaScript well enough, none of this is an issue and can be done in a fraction of the time and to design with no framework. The longest part of this is styling for creating selectable / de-selectable and mouse over and out in those states. A user manager is typically on it’s own page and url, a crud manager for a any database table is typically on it’s own page, framework deployed and written for each page? Why bother? For me I could write the user manager is much less code to design with browse (inc js list search), add, view, edit, delete. No npm, no compile, no nodejs, no server (however I do recommend minification).
Frameworks on the serverside I can get behind, but JS frameworks, best I can see is that if a client wants me to work with a JS framework the job takes longer and costs them more and fills my pockets even more. The other is, it’s nice to ensure front end developers work in a common folder structure.