
A Dive Into Plain JavaScript - jcxplorer
http://blog.adtile.me/2014/01/16/a-dive-into-plain-javascript/
======
hawkharris
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.

~~~
pedalpete
I actually found that using backbone.js helped more with learning how to
structure an app and about working with objects than writing vanilla
javascript.

I was writing single-page applications just before jQuery was introduced, and
I can tell you, my code was spaghetti because I didn't understand OO or
functional design patterns. I didn't find jQuery to be a massive improvement
in that, because I just linked data to DOM elements and everything was still
all over the place.

Backbone forced me to write javascript in a cleaner way, even when I still
didn't know what I was doing. I was breaking up my code into better methods
and providing a better overall structure to my apps.

Now with Angular, I've taken that a step further to modularizing code, but I
don't know how well I would have gotten on with Angular if I hadn't first
learned so much from Backbone.

------
wambotron
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.

~~~
coderzach
An even better solution is to use something like component.io or browserify.
Then you still write mostly plain javascript, but can pull in small components
and utilities when needed.

------
badman_ting
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.

------
robmcm
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.

------
indubitably
A couple more links on this topic:

Vanilla JS vs jQuery
[https://gist.github.com/liamcurry/2597326](https://gist.github.com/liamcurry/2597326)

weaning yourself off jquery
[http://substack.net/weaning_yourself_off_jquery](http://substack.net/weaning_yourself_off_jquery)

~~~
voidr
> Vanilla JS vs jQuery
> [https://gist.github.com/liamcurry/2597326](https://gist.github.com/liamcurry/2597326)

I checked this and it is an opinionated BS.

You can't just replace $.fn.ready with a 'DOMContentLoaded' event.
'DOMContentLoaded' is not supported in a older versions of IE.

Also what if instead of this: "var newDiv = $('<div/>')" I need this: "var
newDiv = $('<div data-bar="true">Some text<div class="foo"/><')"?

So overall that post is comparing apples to oranges.

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

~~~
Dunnorandom
You could also just convert the NodeList to an array by running something like

    
    
        [].slice.call(nodeList)
    

That way you get _all_ array methods, not just forEach.

------
taf2
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>

~~~
antiufo
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.

------
kristiandupont
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.

~~~
andrethegiant
Maybe footprint isn't as big of an issue anymore, but memory usage can still
be. Including a framework increases the amount of memory a page consumes --
not just by the size of the script in bytes, but by how much memory the
objects in that script consume. On phones or other devices memory can be
limited.

------
vkjv
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(' '); }

------
starikovs
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.

------
eli
I still need to support IE8 :(

------
starikovs
Thanks! Very intereting :-)

