jQuery Vs. JavaScript – The Masters Share Their Views On Vanilla JS

Addy — Tue, 25 May 2010 00:03:05 +0000

We’ve got a really great post for you today guys. We’re going to explore whether it’s fundamentally important for designers and developers to understand how to use vanilla JavaScript and not just it’s derivative frameworks and libraries such as jQuery and MooTools. You might be asking ‘why?’, but read on and you’ll find out!. Because this is a topic that can invoke passion on both sides of the debate, I’ve asked a few familiar names to join the discussion including David Walsh, Chris Coyier, Marco Kupier, Janko Javanovic and James Padolsey. All of these authors use jQuery regularly and are in a good position to advise on the pros and cons of knowing vanilla JS.
Before we begin, I’d like to take this opportunity to introduce James Jackson as a new member of the site team who’s contribution to this post was invaluable. So let’s get started!.

We all know that JavaScript frameworks have made it significantly easier to create rich animated effects and interfaces in our web pages – the type of thing which previously would have taken a lot longer if we were writing everything from scratch. I’ve seen coders creating sliding effects and javascript animation for over 10 years but until now, the effort required to achieve the effects through plain JS were sometimes considered too much hassle. Throw in cross-browser compatibility issues and you had a nightmare. jQuery, MooTools and other frameworks have changed this.

They haven’t altered the underlying javascript (it’s important to point this out), but they have introduced an easier layer of access to JS and it’s core functionality which was previously missing.

The question we’re asking today is whether it’s important for people who use libraries like jQuery to understand how the underlying javascript works. My personal opinion is that it is – whilst you can "get by" knowing how to use many of the basic functins jQuery offers, I think that there’s a certain power in knowing why a particular selector should be used over another or how to create something from scratch if jQuery doesn’t particularly support executing it well.

Let’s now delve into this topic further with James.

jQuery Vs. JavaScript

jQuery is the key to the Web 2.0 lock.

I’m not afraid to say it, and furthermore, I’m not afraid to utilize a well known buzz term like, "Web 2.0". Now, throughout this article, I’m going to be referencing jQuery quite a bit but that’s only because it’s my favorite Javascript library and the one I know the best. You could easily support any number of other libraries in a similar fashion.

That said, jQuery has helped a whole new generation of coders approach that ever alluring, and always intimidating field of web scripting. Browsers themselves are greatly measured by how well (and quickly!) they can support Javascript, and jQuery alike.

Most people reading this article are likely already quite familiar with jQuery, so I’d like to take a generous step backward and talk about what lies beneath it. Javascript itself.

We all understand Javascript in different ways, possible by the vast variability of its usefulness, but at its core Javascript really showcases itself as a powerful, easy to use scripting language that is more accessible than many of its influences. The notorious C, and its derivitaves, is often understood as a pipe dream to many modern developers and yet every single Javascript programmer utilizes a syntax almost indisinguishable from C’s without ever realizing it.

jQuery further blurs the lines with its own, innovative syntax which causes its biggest strength to also be its biggest weakness: approachability. Within any system, its a common rule of thumb that the simpler it is to use, the more removed from the source material it gets. jQuery is no exception.

A great deal of jQuery programmers I have known since its inception have been drawn to jQuery for its simplicity, betwitched by its seeming ability to allow the average web designer to magically produce Javascript effects that were otherwise impossible. When a client wants something to zoom across the screen, or to showcase a slideshow of photographs, jQuery answers the call. With a few script includes and some copying and pasting, its not only possible but extremely effective. With the overwhelming amount of customization that jQuery Plugin developers put into their modules, coders can even have intricate control over these effects without ever touching a single line of raw Javascript. jQuery takes care of all of it for you.

The problem herein lies in the moment that every late-night script surgeon will inevitably encounter: when something doesn’t do *exactly* what we need it to. We try tweaking the settings, finding an alternative plugin or scaring ourselves witless looking at the wall of code within the plugins themselves.

Don’t worry — we’ve all been there. This frustration, however, doesn’t have to halt our programming process and can instead offer an exciting challenge. If we understand the underlying code well enough, then virtually nothing is outside of our grasp within the world of Javascript.

Virtually any element within a web page, through the most popular operating system on the planet — the web browser, is accessible and can have its attributes changed. New elements can be created, manipulated and even removed from existence. Your keyboard becomes your brush and the browser becomes your canvas. Literally, even now with HTML5.

jQuery provides a proverbial ‘Paint by Numbers’ tool for us, but when we need to break away from the lines and numerical digits, the paper beneath needs to be understood as well.

I’m sure it goes without saying, but I’d bet that the average jQuery enthusiast without extensive knowledge of Javascript doesn’t fully realize what jQuery is: a collection of Javascript. It’s not a new environment, it’s not an expansion pack; it’s a big pile of Javascript that draws a curtain between you and Javascript. All the web’s a stage, and the DOM is its players.

Most readers, who are familiar with jQuery know of the $() identifier. It allows you to select, or create/remove, any element on a webpage and manipulate it. If we want to grab an element like this:

Then all we require to select it is:

$("#example")

From there, we can affect it in the multitude of ways that jQuery provides. What does this $() mean, though, exactly? How does it work? Is it magic?

In all actuality, $()’s usefulness, speed and versatility is bound only by your understanding of it. Before we delve further into this, lets remember that $() is a jQuery selector which can take more than one parameter, element IDs separated by commas and returns elements as objects in an array. For the sake of simplicity, let’s imagine that we’re just trying to get the very first element matched in the DOM with a particular ID (in jQuery this translates to $(‘#example’)[0]) In this case, we could achieve this in standard vanilla JavaScript as follows:

document.getElementById("example")

Now, because Javascript has this functionality included right into its core, calling elements in this way greatly speeds up jQuery (tests show that getElementById is faster than standard selection in jQuery, however, this is only when you want to grab elements of a particular ID rather than a collection of elements). Because we’re making it so that jQuery doesn’t have to churn through functions and translators, and instead can just use Javascript’s built-in functionality to jump right to the item. Again, let’s remember that jQuery actually provides us with ways of accessing elements by much more advanced selection techniques, however, if you know exactly what you’re after, vanilla can help.

What does this mean to you? SPEED.

By understanding this aspect of Javascript, you can literally cut whole chunks of processing time out of your plugins and scripts. We should note however that jQuery’s use of the Sizzle selector engine has done it’s best to eliminate redundancy when looking up elements in the DOM, but there are still gains to be made for those that understand the underlying javascript.

The Animate feature of jQuery, as mentioned above, allows us to move any element on a page around the browser’s view port with only a few lines of code:

$("#element").animate({ left: 100px; });

This makes moving #element 100 pixels to the right extremely simple. However, let’s assume that we want to add a wavy-animation to our element, so it doesn’t mearly glide to the left but instead waves around (as though our precious #element has had a few to many Box Model Martini’s). This is possible with jQuery, of course, and there are even plugins available to accomplish it. Let’s further assume that either we have a very specific vision for how it will animate or (more likely) our client does.

Either way, time will be spent. Whether its time spent looking for the appropriate plugin, or writing the code ourself.

If we briefly break down jQuery.Animate, we get a very simple process: an event occurring within an interval or timer, selecting the element (by ID) and changing its ‘style.left’ property incrementally through CSS. . Animate() of course supports a wide range of features including intervals, easing and other plugins, but if we wanted to take animate at it’s most basic and wanted to re-create this in basic javascript (moving an element across the screen), lets see how we cold create that code.

var example = null; // object

function doMove() {
  example.style.left = parseInt(example.style.left)+1+'px';
  setTimeout(doMove,20); // call doMove in 20msec
}

function init() {
  example = document.getElementById('example'); // get the "example" object
  example.style.left = '0px'; // set its initial position to 0px
  doMove(); // start animating
}

window.onload = init;

And we’re done. Now obviously, there is a LOT more going on behind the animate function – it supports chaining, easing plugins and a greater level of modification than simply moving an item across the screen, but in its most basic form, that’s what we’re trying to achieve.

This is a more advanced example, so what if you want to mimic a much simpler function of jQuery? Say, the hide() command?

$("example").hide();

This comes in really handy, as you can hide elements that are not currently needed in your application. What does this function *do* exactly, though? As with so many things, the better we understand something, the better we can innovate.

Much of what makes Web Apps so functional (and, let’s admit it, pretty) is affecting their CSS attributes: their color, their opacity, their location on the screen, etc. The hide() function affects one of the most used CSS attributes: display.

To translate the above hide command, we could also imagine it like this:

 $("#example").css("display","none");

Of course, the hide() command gives you more control over the effect, but by using the css() command instead, we can now do some pretty interesting things, such as:

Blend an object in with the text, rather than putting it on its own line:

 $("#example").css("display","inline");

The opposite, take an inline element (e.g. ) and make it take up a whole line:

$("#example").css("display","block");

That’ll get someone’s attention!

Far too often, a jQuery developer will find themselves poking and prodding a bit of jQuery code, trying to get it to behave properly; when their answer is just a css() command away.

This is not to say that you have to choose between Javascript or jQuery, though. By combining the two, we can still use jQuery for what it’s best at: selecting elements and manipulating their attributes. For example, instead of using the whole line of document.getElementById("element") we can save ourselves some code by using $("#element"). jQuery has a built-in checker for elements selected by that and will essentially translate it to our full "getElementById" line, anyhow, so we are literally just using it to abbreviate our code.

This is just the tip of the iceberg. Technically speaking, jQuery is a collection of snippets that allow someone to abide by the D.R.Y. (Don’t Repeat Yourself) method of programming. I urge you, however, to take advantage of jQuery, but not completely depend on it to code.

jQuery is a tool. Javascript is the garden. Together, they can allow us to cultivate endless abundance if utilized in harmony.

Knowing jQuery (among many other scripting libraries) in this modern world of web development is crucial. It provides quicker turn around times, opens your code up to a vast world of other developers and makes your code efficient, and easy to read. However, even the best tools are only as useful as the person who wields them.

If we have not only a better understanding of our tools, but also our environment, then we can help usher in — if not pioneer — the next era of web developers.

Thoughts from:

David Walsh

"Learning JavaScript is absolutely paramount to becoming an effective Web Designer or Developer. While the JavaScript libraries do as much as possible to ease the pain of some of JavaScript’s more time-consuming tasks, libraries cannot anticipate their every use. Without proper knowledge of JavaScript, a developer can spend hours debugging an issue that should really only take a few moments. Spending the time to become a ‘Vanilla JS’ expert will allow a developer to more easily learn *any* of the popular frameworks, thus making that developer far more valuable."

Chris Coyier

"I’d love to tell you all about how life will be better if you learn and understand JavaScript before you learn libraries. Or at least, that you should go back and get those fundamentals after starting out with libraries. Here is reality for me though: I’m terrible at vanilla JavaScript. It would be pretty hard for me to try and get day-to-day design work done if I couldn’t use jQuery. In fact, I probably just wouldn’t do it, and stick to design and markup. I’d love to go back and get those fundamentals, and I probably will over time, and it will make me better, but I’m also living proof that you can still get the job done being a library junkie."

Janko Javanovic

"I will be glad to give an opinion about js/jQuery. I agree that developers should have at least some understanding of JavaScript. jQuery and similar libraries might be a good way to get people interested in JavaScript in general. But in the other hand it might actually be a stumbling block – it’s so easy to use jQuery that many don’t need a deeper understanding of JS.

Lack of knowledge become obvious when developers need to modify/extend some jQuery code. They don’t understand it fully. And then they cry for help. So I’d say it would be better for them to learn a few things about JS and try figure things out themselves. Otherwise, chances are they will never learn."

Marco Kuiper

"Very interesting topic, especially since I learned jQuery before learning actual JavaScript myself (the only JavaScript I knew before that were the "mouse following clock" and "disable right click" stuff – you know, back in the days…). But at the time I started to get a hang of jQuery, I did wanted to learn more about JavaScript. Why? Basically because I wanted to get the maximum out of jQuery.

For example, take a look at speed. I learned that using an ID selector ( $("#myelement") ) is around 100 times faster than a class selector ( $(".myelement") ) . This is because the ID selector maps to the native "getElementByID()" JavaScript function. The same is for using tag selectors ( $("body") ), since that maps to the native "getElementsByTagName()" JavaScript function. The class selector loops through all the objects in the DOM to find the specified elements. There are more speed tricks for jQuery that you would know if you knew how JavaScript works.

I truly love the way how you can create elements in jQuery 1.4; Simply apply an element name to the jQuery core method and you’re ready to go ( $("
") ). Before that way was implemented in jQuery, you could simply use the native JavaScript method "document.createElement()". Although it isn’t as great as the way jQuery creates elements, it did allow you to create elements using JavaScript. Using those kind of methods even before it was added to the jQuery core, and you were sure to be one step ahead of the rest.

The last example I want to show you, is the use of parameters. The jQuery ".bind()" method attaches behavior to a specified element. The first parameter is the eventType, like "click", "mouseenter" and "mouseleave". How would you know which eventTypes you could specify, if you don’t know the implementation of JavaScript ("object.onmouseenter" etc.)? And why do you use all those curly brackets (when creating objects) and using functions as parameters ( $("#myelement").click(function() { var doStuff; } ); )? All that kind of stuff is JavaScript that you’re using. If you’re using it, use it and learn it correct.

So, if you want to get better at jQuery, take a look "under the hood" to see the JavaScript engine that is working hard for you. Learn and master it!"

James Padolsey

"I agree that there is a problem with the terminology used throughout the jQuery community. jQuery uniquely appeals to people with minimal programming experience and that makes it all the more complicated to explain it in the right way. I’ve always been a proponent of learning JavaScript and the DOM API before any library. I’m not saying that this is the only way; obviously there are people who have learnt it the other way round, and they’re just as proficient as you or I. But, still, there is a difficulty to overcome, and I think there’s a lot of progress that needs to be made in the way that jQuery’s paradigms and implementation are explained to beginners. I think you’re right about “wrapping” being misleading, but, it is a helpful metaphor which gives beginners confidence when using jQuery.

Let’s face it! Most people that use jQuery are not looking to become an expert. They don’t care about its internals or what really happens when they call the magical dollar. They just want it to work. The people who really want to dig into it will do so by their own means.

I’ve used some of these metaphors myself, such as “caching” — it can be misleading but most “web” people understand the term. If I said “reference” instead then I’d have to explain what a reference is and how objects in JavaScript are different to primitive types, and how an identifier is simply a pointer to an object in “memory”… it gets complicated very quickly.

jQuery is one of those cool technologies that gives you tremendous power right off the bat! That’s what appeals to beginners, I think. They feel powerful; they feel that they pretty-much understand jQuery and how it works. We wouldn’t want to shatter that confidence by the realisation that they, in fact, still have a lot to learn about jQuery, JavaScript, and the DOM.

Don’t get me wrong. I really do support the idea that beginners should be taught correctly right from square one, but I think it needs to be done delicately. You can’t drown them with complicated words and ideas; that’ll surely scare them away."

I would say that learning APIs and abstractions such as the DOM, jQuery, Mootools, Prototype, Dojo, ExtJS and others is quite pointless for the beginner because there are literally thousands of libraries, toolkits and frameworks that the beginner _could_ pick up…. Obviously the DOM is central but at the end of the day it’s just a bunch of method-names and argument signatures that you have to remember.

What needs to be taught is **JavaScript** … or rather, ECMAScript.. the real thing — i.e. hand out a copy of the ES3 specification. (actually, that’d definitely scare people)

The problem with learning JS is that most of the really good resources are simply not geared towards beginners. Websites like w3schools and "javascript.about.com" ARE geared towards beginners but their content is crap — it’ll get an individual past the noob phase but not any further. They need to be learning about primitives, objects, variable declaration, function declaration, function expressions, scope, closure, operator precedence, booleans… blah blah blah… The rhino book is what they all really need.

Most of the people using jQuery don’t even want to "program", per se; they just want to add cool’ness to their websites. Telling them they defined a global instead of a local var, and they should probably use function declarations because it makes debugging easier is pointless because they really couldn’t care less. The devs that really care about code quality and all the stuff we love are already on the path to enlightenment."

Conclusions

And that’s it guys. What are your thoughts on the topic?. Do you think that it’s important to have an understanding of basic JavaScript?. We’d all love to have an open discussion on this and we’d really like to hear your opinions in the comments section below. If you liked the post, remember that you can easily share it with your friends and colleagues just be clicking the jQuery Vs. JavaScript – The Masters Share Their Views On Vanilla JS button. I hope you found this post useful guys!

.

AddyOsmani.com | Where Web Businesses Grow » mootools

jQuery Vs. JavaScript – The Masters Share Their Views On Vanilla JS

22 Excellent Examples of Advanced jQuery UI's in action