Switching back to Vanilla…JS

Back in the days of the second browser wars, jQuery and other libraries emerged to try and conquer the emerging browsers into a cohesive and easy to use syntax. Around 9 years ago, the Javascript world was quite a buggy and an inconsistent place with Internet Explorer 6 and 7 in play. Firefox was starting to emerge, Netscape Navigator was still around, and Chrome didn't exist yet. Having to write any decent Javascript that worked cross browser was a nightmare at times. Mootools, Prototype, and jQuery introduced easier cross browser DOM and CSS manipulation as well as convenient animation options. It's no wonder developers across the globe grabbed these tightly with their calloused, worn out fingers. Many faces were saved from keyboard smashes and the web world hasn't really let go since.

Fast forward to today. It's almost like a developers' paradise in comparison. Chrome and Firefox pushed for automatic updates and standardization of the open web. Microsoft learned from its mistakes and is trying with all of its might to shove IE under the rug and push forward with Edge. IE6 lost its grasp on the world and IE8 has finally as well. A lot can change in 9 years - and indeed it has. Developer tools are packaged into every browser, CSS3 introduced a whole new approach for animations and transitions, and ECMAScript 5 spec is pretty much universal with 6 now starting to come in. All of this begs the question - in today's browser market, does it make sense to still hold onto these savior libraries of the past?

All of these libraries helped solve DOM navigation, AJAX support, event models, CSS2 support, and animations across all browsers. There are a lot of smart people maintaining these libraries , as well, so the solutions are very well done. Also, it's likely that without these the main browser companies wouldn't have accelerated their Javascript implementations. So, by no means am I looking down on jQuery and the like. We are even still utilizing them on a regular basis ourselves.

The Pains of Abstraction

However, in order to do so they had to write abstraction functions to get around the issues. Something often forgotten is that these libraries aren't built on a magical new language but rather written in plain old vanilla JS. At the time, it made sense to have the browser parse an abstracted JS file where the syntax will run technically slower than the native alternatives. Most of the time, back then, there weren't really good native Javascript alternatives. Nowadays, if something works in IE you can almost guarantee it will work in Chrome, mobile device versions of the browsers, etc. Also, the amount of code to write out the same functionality isn't very different either. For example:

var items = $(".css-selector")

is the way to get all of the items with a class of css-selector in jQuery. Since IE8, this has been available:

var items = document.querySelectorAll(".css-selector")

and it ends up running faster in processing. And if you only need to worry about modern browsers this approach will run even faster.

var items = document.getElementsByClassName("css-selector")

Speed isn't the only reason to start moving away from abstraction, though. Another reason is knowledge and growth of the developer community. If you check stackoverflow or most forums, when a user has a question the most often immediate answer is "use jQuery". This doesn't teach a new developer how to build anything on their own without a library. It also continues the idea of "magic" happening inside and normal developers couldn't possibly write alternatives. The more developers let go of the safety blanket of jQuery and the like, the more likely they will develop their own custom needs for a site and may even end up not needing the bloat of a full library. If it is a fairly basic site, you could even debate on whether you would need a separate http request for a script item at all.

Animations and Offloading Work

The utility of jQuery and other libraries was also in the ability to do animation work. You could make elements slide up, fade in, etc. With further libraries on top of those libraries you could then animate colors and do more complex animations. However, with the large support of CSS3 a bit of that strong need for JS to animate can be offloaded to the browser. Most of the animations and the like for sites are subtle changes to the design of the site and not complex flash pieces. CSS is amazing at handling that with relative ease. You can have elements slide in, fade out, or even do barrel rolls across your screen without any Javascript needed.

SVG libraries are gaining traction as well as modern APIs like canvas. These don't tie into jQuery and you will need to know vanilla JS to better understand them. These more modern approaches to imagery and drawing also offload the work. More and more APIs for HTML5 have been drafted and implemented across browsers (though the support is a bit less friendly at times and caniuse.com will continue be your friend). However, if you go with a progressively enhancement approach, a lot of the fancy features of animation and API support could be focused on just those browsers that support them.

So are Abstraction Libraries dead?

By no means are we done with jQuery and you'll notice I reference it more than the others, but when it is on 65%+ of websites you can see why. However, there are newer libraries and abstractions that fit the needs of today. Node.js is creating a new era of Javascript related web development as well as Angular 2, ember.js, and modern application frameworks. These again are libraries that are written or utilize vanilla JS and have abstracted them to become more powerful for the browsers of today. With ECMAScript 6 you are now starting to see Babel, traceur, and other libraries trying to polyfill and create cross browser support like the days of jQuery, Prototype, and Mootools (almost 10 years ago).

The examples of writing in vanilla JS often seem simple enough, but it does get more complicated as you get deeper, so it always seems nice putting back the safety blankets. If jQuery is a faster approach and will get the work done well and performance isn't as much of a factor, then continue to use libraries like that. However, as developers we can't lose sight that the "magic" of these libraries is vanilla JS and you can wield it just the same. I'm not the only voice mentioning this. With more voices, we can make sure more of us avoid the safety blanket and potentially create the next library that will help the community.

About Author

Nick Goodrum
Nick has been pushing forward the "Front End" development world of Americaneagle.com for over 4 years. Owing to being a major enthusiast for best practices and modern techniques (accessibility, page load, UX, you name it…) he's more than happy to talk your ear off about it.

Featured Posts