A Dive Into Plain JavaScript

If learning JavaScript feels like jumping into the ocean and trying to swim for the first time, jQuery is, in some ways, like a motor boat driving beside you. The driver says, "Hey, hop on in. Why learn the basics of swimming when you can start covering ground?"

Speaking from experience, failing to learn the foundational aspects of the language in the beginning leads to a lot of poorly organized "spaghetti" code. It took me a lot longer to appreciate concepts such as closures and the nuances of DOM events because I relied on jQuery to do the heavy lifting for me.

Having said that, I have a lot of respect for John Resig and his essays / books (i.e. Secrets of the JS Ninja). After taking the time to learn about Resig's functional programming style and the design decisions underlying jQuery, I gained a much deeper appreciation for both the library and plain JavaScript.

Plain JS is great! I love writing it.

That said, as a site (or app) grows, you generally end up writing more utility functions than you expected, and at some point it cancels out the benefits of NOT using jquery (or another lib). You have to weigh these decisions out, but saying "plain JS is better than jquery" is misleading since, in the end, jq is also written in plain JS. Think of it as all of those utility functions you DON'T have to write.

Just make sure you understand vanilla JS and I see no issues with leveraging libraries to make dev time faster. Those libs are generally tested enough to ensure cross-browser compatibility and save you the headache of rolling your own everywhere.

Different frameworks can have very different approaches to doing similar things. I started writing Javascript in a place that used Prototype, a library which is now either defunct or just unused, but anyway its approach (and purpose) were rather different from jQuery. For instance, Prototype relies heavily on altering the built-in types, which today we consider a no-no.

I'm talking about this because I think it's interesting that people are moving from starting with jQuery to attempting not to use any framework at all. I'm in favor of that because it's best to know what you're working with before you start adding on, you taste the soup before you add salt.

But personally I wouldn't want to work on any kind of real project without something to handle a lot of the more tedious aspects of JS development. Of course there are always polyfills and "micro libraries" but at some point you are replicating some of the professed downsides of using a framework, or to put it differently, how many micro libraries equal a framework?

Another company recently posted about eschewing JS frameworks, followed by a lively HN discussion, only to announce their in-house "library" that does many of the same things we need frameworks for. IT seems like there's a circle here where a lot of people go from all jQuery -> questioning jQuery as a crutch to "real js development" -> realizing all the things that jQuery or similar handle for us -> resignation and acceptance.

So it may ultimately be more useful to compare the approach of different libraries or frameworks to see what we can glean from them in how we write our own JS, what works and what doesn't. Not to mention, there are things that jQuery just does not have, that would be super useful and show up in other frameworks, so those things just don't show up on people's radar if jQuery is the only framework they've tried. I'm talking about anything at all for dealing with cookies. (Cookies, for god's sake! Not exactly an esoteric corner of web development!) I'm talking about turning a query string into an object and vice versa. Imagine you need to take a URL, modify one value in the query string, and write it back out. How do you do it?

Anyway, yes, definitely learn about document.querySelectorAll. Because part of what you learn when you do it this way is that that function does not return an array of elements like you may have hoped/expected. Welcome to the desert of the real.

It's great to know what a library like JQuery is doing under the hood, but if you are going about your daily development using a progressive enhancement to access the dom using document.querySelector you are removing support for IE7 for no real reason.

You can query the dom in IE7 using other methods and this is the goal of a library like JQuery.

Progressive enhancements are aimed at providing an alternative for browsers that don't support functionality, not that don't support functionality the way you want to coded it.

A couple more links on this topic:

Vanilla JS vs jQuery https://gist.github.com/liamcurry/2597326

weaning yourself off jquery http://substack.net/weaning_yourself_off_jquery

* Why feature detect classList with `if ("classList" in document.documentElement)` and not `!! document.documentElement.classList` like described at the beginning of the article?

* Why add a style to a cloned node instead of directly to the node? Performance improvements?

* `$ = document.querySelectorAll.bind(document);` won't let you have a shorthand for performing a query selector on an element. For that, you also need something like `Element.prototype.$ = Element.prototype.querySelectorAll;`. Likewise, you'll probably want the `on` shorthand applied to document and window too for consistency's sake.

* I also like to cast Array's forEach method to NodeList to iterate over values from a querySelectorAll. That way you can do $('a').forEach() instead of [].forEach.call($('a'), function(el)).

great write up. one thing to remember when traversing the DOM using native APIs whitespace matters.

e.g. <div>#textnode

    <span>#textnode</span>#textnode

   </div>

This is interesting in the same way I find it interesting to write C code to be closer to the hardware but I don't think the "so much smaller footprint" argument is very strong.

jQuery is cached more or less everywhere in every browser and CDN on the planet. Going around it seems silly to me.

There's a bug in the removeClass() function. If you use a class with a reserved regex character it will fail.

I'd rather see this done with a small sets library anyway. removeClass = function (el, cl) { el.className = _.without(el.className.split(' '), cl).join(' '); }

Now I'm thinking about the need of MVC framework at the server side %-) Many of things you really need at the server side you can do without a framework and as a result you'll control/understand your code better.

I still need to support IE8 :(

Thanks! Very intereting :-)