A Dive Into Plain JavaScript

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

e.g. #textnode

    #textnode#textnode

   

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.

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.

* 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)).

Which can be safely ignored when using the firstElementChild, nextElementSibling properties and so on. They are not available in old browsers, but a polyfill should be available.