I program in Java and it doesn't make sense to me to think about learning a Java library or a framework without knowing the actual language the thing is built with. Same goes for C. I always avoided JavaScript simply because I wasn't interested in the client side of things but that has changed now.

I'm confused as to how and why do people avoid learning JavaScript and instead jump right ahead with a library like JQuery ? How can I program without knowing the features of JS, what is a prototype based language, functions as first class citizens, OOP, closures, etc.

Also, are most of the things today in the client-side world built with the help of third party libraries?

  • 5
    I share part of your dissatisfaction. I have seen this trend as well. I think what is happening is for the most part, people who have never seen javascript and need to learn client side scripting: Naturally find a ton of tutorials that happen to use jquery for EVEN trivial things! Its bad education I guess. But this fad and hype will die down.
    – Darknight
    Commented Aug 8, 2012 at 21:25
  • 1
    jQuery is a javascript library. If you use jQuery, you use javascript; you can't do it without knowing JS.
    – tdammers
    Commented Aug 9, 2012 at 5:44
  • because programming directly to the DOM in a portable cross platform way is next to impossible, and it sucks in general.
    – user7519
    Commented Aug 9, 2012 at 12:03
  • 1
    @tdammers yes you are correct, however some people are unaware of this! I've head people talk about jquery as its a language eg "forget javascript man, use jquery" or Job Agents "can you code in jquery?"
    – Darknight
    Commented Aug 9, 2012 at 14:05
  • 1
    I do have to say though, it's a little surreal to hear a Java dev wondering if client-side web development is engaged in over-use of libraries. Encouraging, mind you, but weird. Commented Aug 9, 2012 at 16:47

6 Answers 6


jQuery's primary role is to normalize the DOM API which is the one thing browsers haven't agreed on for over a decade (until IE9 came out). It's better thought of as a tool than a library. It's basically just a factory function that returns an adapter merged with a bit of decorator that wraps and normalizes the DOM object API with lots of cruft reduction and some additional goodies like the animate function and an event system that lets you fire and listen for new events on the fly on any object without even defining them somewhere first.

What it doesn't do is help you with writing more complex, maintainable app-oriented code (well, the event thing is neat-o but easy enough to DIY), use objects well, or use any of the core ECMA spec obects that really form the basis for the core language of JavaScript.

Among proper JavaScript devs, it takes very little time to filter out the devs who are going to be useful on a project from web designers or CMS-only devs gunning for a salary increase by doing awful things with a tool they'd rather not understand under the hood if they can avoid it.

Also, the DOM API is pretty verbose with method names that practically write their own documentation (by approaching paragraph length basically), which is a good thing, IMO. We want the core native stuff to be obvious and spelled out. But the tedious nature of writing with it encourages us to use JavaScript to do something it's very good at. Eliminate cruft, normalize, and bend the API to a paradigm that works better for us. I personally think jQuery did a bang-up job of this compared to most of its contemporaries and that you can learn a lot about JavaScript (like how to keep your objects really lightweight as far as memory is concerned) by studying jQuery under the hood.

But I wouldn't use it as a pre-fab UI library namespace. And I wouldn't discard loops in favor of using .each on everything. And I often downshift to DOM API methods when JQuery is adding work without really eliminating cruft which brings up one of the most important features of jQuery to those of us who actually know what we're doing. It doesn't get in your way when you don't want it there.

But make no mistake. If you don't know how to do it without jQuery you're at best an entry-level JavaScript/client-side dev. On the flip-side if you only know JavaScript and only have minimal understanding of CSS, you better be focused on something other than UI problems.

Edit: I realize I focused on JQ a bit too much for a question that was asked more generally.

Most other popular JS tools/libraries/frameworks are either UI libraries, none of which I'm a big fan of (too inflexible typically), and rapid-application building frameworks that apply concepts from MVC or similar patterns. I'd rather DIY architecture personally (and I'm a little wary of this model-binding in templates trend) but these new frameworks aren't the sorts of things implemented by JS devs who can't handle code problems that require JS-literacy themselves I would wager.

  • the event thing is neat-o but easy enough to DIY - Actually, just like the DOM normalization, it's just wrapping up existing browser features.
    – Izkata
    Commented Aug 9, 2012 at 20:46
  • How do you add a listener to any object with native event methods? e.g. var foo = {}; foo.addEventListener('whoopie',function(){}); Commented Aug 9, 2012 at 21:39

Most JavaScript developers use a framework since JavaScript as a language contains quite a lot of cruft and otherwise undesirable functionality. It has some really powerful functionality but there are also plenty of ways to shoot yourself in the foot.

I've used jQuery and YUI and the past. When using a good JavaScript framework programming in it is a significantly more enjoyable experience. I tend to favor jQuery these days because it allows me to write very clean functional-like code. jQuery also relies heavily on CSS selectors for DOM querying so it feels a lot more natural to write $('#some_element') than writing document.getElementById('some_element').

I recommend reading JavaScript: The Good Parts by Douglas Crockford to learn some tips for very effective (and beautiful) Javascript programming. This book won't teach you how to write nifty JavaScript effects or AJAXy magic but it will teach you about the language, what to rely on, and what to run away from screaming. It's a fairly short book but I'd recommend reading it a few times.

  • 1
    Tell me how does jQuery stop people to shoot themselves on the foot please? As I feel sometimes they shoot themselves on the foot with jQuery itself (eg, chaining is a perfect weapon to kill your code-maintainability.) I'm not saying it can't be used for good purposes, but as you know, guns don't kill people.
    – Aadaam
    Commented Aug 8, 2012 at 22:43
  • 1
    The CSS like selector is nothing jQuery specific. Infact, the selector engine in jQuery is sizzle: (sizzlejs.com). Apart from that, there is a native way. You can do the same with the document.querySelector (developer.mozilla.org/en-US/docs/DOM/Document.querySelector) And never mind the short $ sign, as you could always create that shortcut if you like. Commented Aug 9, 2012 at 5:51
  • A javascript library may be a useful tool to make web development easier and more rapid for developers, but honestly, why should I use a library like Jquery or Mootools if I only want to use like 2 or 3 functions they contain? Its better to write a method yourself rather than containing an ~80KB library to your code. Of course if the project is large a use of a library is a must.
    – user61465
    Commented Aug 9, 2012 at 11:28
  • I thought they dropped sizzle. Or did they just integrate inside the JQ function rather than externally? Commented Aug 9, 2012 at 19:28

When we used to develop in JavaScript we had to write three version of the same function in order to make the function works in IE, Safari and Firefox.

JQuery take care of this problem (not perfect but better than doing it from scratch) and let you focus on the function itself.

  • 1
    This is becoming less so with more modern browsers. I mostly write from scratch, I just don't need all the library overhead most of the time. I haven't had much trouble cross browser wise. Perhaps this was true for much older browsers?
    – Darknight
    Commented Aug 8, 2012 at 21:28
  • @Darknight: true in deed but large corporation are slow with updating their browsers and we end up supporting old versions
    – Amine
    Commented Aug 9, 2012 at 13:40
  • It's definitely getting easier and easier to do it without JQ. If we didn't support IE8 I'd be giving serious thought to whether we need it but I'd still consider it necessary to write my own wrappers to zap the DOM API cruft. Commented Aug 9, 2012 at 19:34
  • 1
    @ErikReppen: IE8 is heaven in consideration to older versions :)
    – Amine
    Commented Aug 9, 2012 at 19:48
  • When I first learned this stuff I was still considering IE5. And yes, I definitely agree. Especially for finally being able to do the vast majority of CSS2 stuff. JS in regards to the DOM API is essentially unchanged from IE6 though. Commented Aug 9, 2012 at 20:03

On the whole, Javascript frameworks solve DOM interaction problems. The rest JS has nothing to do with the DOM.

Of course, many frameworks supply functions to JS behave more like a standard OO language, such as by adding "classes" (uugh, now my mouth tastes dirty). I'd say, just learn JS for what it is and avoid that crap. To me it's like trying to program C++ as a functional language. You can kind of do it, but it's better to learn C++ as it really is.

  • This is no longer really true. Recent years have seen a whole generation of more application-oriented client-side frameworks that build on MVC and similar patterns. A lot of them normalize DOM stuff for you but that's becoming more and more trivial as normalizing techniques improve and the last of the proprietary IE DOM API browsers gets very close to leaving the playing field. Commented Aug 9, 2012 at 19:26

JS has more in common with languages like LISP or PROLOG than Java. Syntax is similar to Java, which is misleading and the frameworks are designed for not-so-clever PHP beginners. So they try to emulate some outdated, horrible OOP model. And the code these beginners produce is just sub-standard, ugly and hard to modify.

Of course that OOP model works on server side very well, but it's horrible for client side UI. JS has completely different programming model, very well suited for UI developping (easy callbacks, prototypal inheritance, super-easy encapsulation, very clean object model, etc.).

jQuery... that's most easy to use, but it is most horrible. With constructs like parent().parent().parent()... it's designed to "shield" you from "real" JS by providing some horrible PHP-like OOP model. That's why, probably is so widely adopted. People don't have time to learn JS so they just use jQuery and pretend it's Java or PHP.

instead jump right ahead with a library like JQuery ?

Just stay away from it. There is no worse code in JS that code written using JQuery. Or course if you previously used Java it'd look "ok" for you. But that's not true. You can write so much better, error-free and modular code using pure JS or mootools (because it's extending JS rather than replacing it's object model).

Using that BS those frameworks provide (like "classes") it's like going back from C++ to C, just because you can't think beyond simple functions and global variables. So you need something that'll "dumb down" the language so you can write some very crappy code without learning any new things.

  • You're probably going to get downvoted, since JQuery is very well liked, but I won't downvote because I sort of agree, in the sense that I also believe that pure ECMAscript can be a very productive, beautiful prototypal/functional language. The problem is that in the real-world, Javascript is most often used as a DOM API, and the actual W3C DOM specification is quite verbose/cumbersome, to say nothing of all the cross-browser inconsistencies. Without JQuery or some framework, you need a function library for abstracting away browser differences, and even simple Node selection is a pain to type. Commented Aug 9, 2012 at 0:51
  • Tell me please, where exactly does jQuery try to implement class-based OOP? Whenever the word 'class' is mentioned in the documentation, it refers to the class attribute of a DOM element, or a CSS class (which is practically the same thing in this context); I've never seen it used in the OOP sense. The only thing I can think of that jQuery does in terms of modifying the object model is that it automatically binds functions, so that this doesn't always behave as you'd expect in pure JS, but that's a quirk I can live with; more often than not, it does exactly what you want anyway.
    – tdammers
    Commented Aug 9, 2012 at 5:51
  • That's simple... because with jQuery you get many bad practices boundled. You mentioned this binding. That's a start, you get HORRIBLE chaining (it's impossible to read to everyone but code creator), then you have something that resembles pointer/type conversion, for example in jquery you can use getElementById and then you need to convert the object you get to jQuery object to use jQuery methods on it. It's a HORROR, it's like writing in 2 parallel programming languages. Depends on what you use (jQuery or JS method doing the same)... you get 2 different things.
    – Slawek
    Commented Aug 9, 2012 at 9:49
  • So this is (i think) the worst property of classical OOP that jQuery is "adding" to the language. 10 "String classes"... now in beautifully designed JS you get 2 objects of type NODE (DOM) with different methods. Now look at mootools, it's designed just like JS framework SHOULD be designed. You can call $$, getElementById, replaceNode... and you'll always get an extended object with mootools and JS methods. It's a beautiful design. Not something like jQuery where it seems you're working with 2 parallel programming languages. In jQuery you can't even use native methods on jQuery DOM objects!
    – Slawek
    Commented Aug 9, 2012 at 9:54
  • 1
    You may think it's nothing but in complicated apps, you need either to switch to using jQuery methods all the time or the code becomes a mess because you never know if the object is using "JS" subset of methods or jQuery one. Even a simple comparison is very hard to track later in such badly designed framework. I know people like jQ... because it requires them to learn almost nothing. And that's just a start. this behaves differently depending on if you used jQuery event handling or "native" one. This lib is so badly designed that it's impossible to work on a project with more than 1 dev.
    – Slawek
    Commented Aug 9, 2012 at 9:58

People learn differently.

==Top down approach==

Some jump into the library and learn how to work with the library and inevitably learn some of the javascript, or base language, features.

==Bottom up approach==

Others like to learn about the pieces and then how they are put together to create the library they're using. Sometimes they feel that to be more effective they'd like to know the nooks and crannies of what they're using and the language it's written in.

The approach you take largely depends on you AND how easy the library is to use. If the library is hard to use then either users won't use it OR they'll be forced to do a bottom up approach.

Fortunately, javascript appears deceptively similar enough to java and other languages in terms of syntax that most users feel they can take a top down approach while relying on their reference language for help to determine how things are working. This happens even though, as stated in the comments, Javascript is very different from Java and draws more inspiration from LISP/Scheme than from Java.

The top down approach works with javascript/jquery quite well but what inevitable ends up happening is that the user ends up coming up with a Java like solution to their problems when a simple javascript convention would be easier to implement. This is a drawback but only until they realize that javascript can make some tasks easier. Until then, to the user, javascript becomes Java just on the client side.

Eventually they run into some weird bug or code they can't understand, like the way closures work, and have to dig into javascript basics more than they have to.

I don't know how much of client-side code is built with 3rd party libraries but I do know that they can make life much easier since you don't have to 're-invent the wheel'. Cave men did that a while ago so focus on other things if you can. If you're in a limited environment then you might have to write your own library but basing it on a 3rd party library is NOT a bad idea because they've thought of, faced, and solved more issues than one person could hope to cover in the same amount of time.

  • 7
    javascript is similary enough to java and other languages in terms of syntax : this is probably the biggest problem people face when learning Javascript. The superficial similarity in syntax between Java and Javascript is incredibly misleading. The truth is that Javascript probably has more in common with Lisp than it does with Java. Commented Aug 8, 2012 at 18:57
  • I agree. I should make it clearer. The syntax is deceptive and leads people to believe the language is a lot like Java. Commented Aug 8, 2012 at 19:29
  • 1
    You really should know the DOM API and the problems JQ solves for varying browser interpretations before using jQuery professionally though. For instance, $('.someClass') is massively ineffecient selector to use in IE8 and below. Reason? No native getElementsByClassName method. It has to hit every tag in the DOM and do matches on className properties at the interpreter level. It takes more than basic CSS syntax knowledge to use jQuery well. Commented Aug 8, 2012 at 20:13
  • @CharlesSalvia: Javascript's Lisp influence comes from Scheme actually, not CL.
    – tdammers
    Commented Aug 9, 2012 at 5:47
  • 1
    I'd love to. Not always my choice. And to Joe Six-Pack and Suzy Cream-Cheese, upgrading a browser may seem a little more intimidating than you realize. And technical people can be change-averse too. My father's an Electrical engineer with a fellowship who's been doing light programming as a hobbyist and a professional since the '60s. It took him forever to drop IE6. To a major retailer, telling people to just upgrade their browser or allowing them to have an awful experience is unacceptable. I'm personally deeply grateful I only have IE8 to deal with. I can finally use 99% of CSS2. Commented Aug 9, 2012 at 15:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.