A Dive Into Plain JavaScript

http://blog.adtile.me/2014/01/16/a-dive-into-plain-javascript/

by jcxplorer • 13 years ago

63 19 13 years ago

blog.adtile.me

taf2• 13 years ago

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• 13 years ago

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• 13 years ago

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.

andrethegiant2• 13 years ago

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.

badman_ting• 13 years ago

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.

eli• 13 years ago

I still need to support IE8 :(

hawkharris• 13 years ago

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• 13 years ago

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.

yaph• 13 years ago

One of the main Problems with JavaScript is not the language itself, but the browser implementations. It was a huge pain to write cross-browser code when jQuery came out. jQuery took away a lot of these efforts and certainly had influence on the things you can do in modern browser these days, e. g. document.querySelector.

While I don't read your comment as a criticism of jQuery, I feel that jQuery gets bashed too often these days for insufficiencies in code. In the vast majority of cases such insufficiencies are not caused by the libraries, but by the developers using them.

andrethegiant2• 13 years ago

* 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• 13 years ago

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.

robmcm• 13 years ago

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.

starikovs2• 13 years ago

Thanks! Very intereting :-)

starikovs2• 13 years ago

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.

wambotron• 13 years ago

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• 13 years ago

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.

vkjv• 13 years ago

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

indubitably• 13 years ago

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

voidr• 13 years ago

Vanilla JS vs jQuery 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.

A Dive Into Plain JavaScript

Related Stories