Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
4  
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 Aug 8 '12 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 Aug 9 '12 at 5:44
    
because programming directly to the DOM in a portable cross platform way is next to impossible, and it sucks in general. –  Jarrod Roberson Aug 9 '12 at 12:03
    
@JarrodRoberson cross platform in raw js, annoying yes "next to impossible" certainly not :) –  Darknight Aug 9 '12 at 14:03
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. –  Erik Reppen Aug 9 '12 at 16:47

6 Answers 6

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.

share|improve this answer
6  
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. –  Charles Salvia Aug 8 '12 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. –  Jerry Saravia Aug 8 '12 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. –  Erik Reppen Aug 8 '12 at 20:13
    
@CharlesSalvia: Javascript's Lisp influence comes from Scheme actually, not CL. –  tdammers Aug 9 '12 at 5:47
    
@Erik: Well if someone is such an idiot and he's using IE8 nowdays... well i think we should not care anyway if the app would be a little slower for him. As you probably know almost everything is slow as hell in IE. From string OPs to DOM manipulation. Actually the whole DOM is broken (you can't manipulate on SELECT's and TABLE nodes)... so... why should we care anyway? If something is working that's only because we wrote inefficient code that IE8 can handle and the fact it works is a huge success. We should move forward and try to drop IE support altogether from whatever we can. –  Slawek Aug 9 '12 at 10:09

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.

share|improve this answer
    
+1 to jQuery, well mentioned ! –  Yusubov Aug 9 '12 at 4:11
    
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 Aug 9 '12 at 20:46
    
How do you add a listener to any object with native event methods? e.g. var foo = {}; foo.addEventListener('whoopie',function(){}); –  Erik Reppen Aug 9 '12 at 21:39

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.

share|improve this answer
    
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. –  Charles Salvia Aug 9 '12 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 Aug 9 '12 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 Aug 9 '12 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 Aug 9 '12 at 9:54
    
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 Aug 9 '12 at 9:58

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.

share|improve this answer
    
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. –  Erik Reppen Aug 9 '12 at 19:26

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.

share|improve this answer
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 Aug 8 '12 at 21:28
    
@Darknight: true in deed but large corporation are slow with updating their browsers and we end up supporting old versions –  Amine Aug 9 '12 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. –  Erik Reppen Aug 9 '12 at 19:34
1  
@ErikReppen: IE8 is heaven in consideration to older versions :) –  Amine Aug 9 '12 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. –  Erik Reppen Aug 9 '12 at 20:03

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.

share|improve this answer
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 Aug 8 '12 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. –  Bruno Schäpper Aug 9 '12 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. –  Nickolas Aug 9 '12 at 11:28
    
I thought they dropped sizzle. Or did they just integrate inside the JQ function rather than externally? –  Erik Reppen Aug 9 '12 at 19:28

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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