Let's not have a JavaScript library anymore

Published 2012-03-30

⚠️ Wait up! The article you're viewing was published a long time ago (in internet years), it may be irrelevant or completely incorrect by now. Thread carefully!

JavaScript libraries bring a lot of features, and a lot of footprint. Most developers don't even use 10% of all the features most libraries have to offer. So maybe we should get rid of the library then?

When you never start using (or stop using) a JavaScript library, you'll save on bandwidth and performance by definition and you'll eliminate a lot of dead code in the process. You'll also lose an important dependency on code that's not "yours". But there are some trade-offs, like the steep learning curve for starting developers, most of them "know jQuery", but no real JavaScript. And you'll miss out on possible plugins and community support.

The moment you stop using a library and start developing something complex from a JavaScript perspective, you'll start running into problems you have to solve differently this time. The most common features used from libraries include the selector engine, event binding, DOM traversing/manipulation and http requests. And maybe animations, but I'm not going into that one in this article, it's already becoming a slight bit lengthy.

Anyway, I think it's a great idea to get those missing features back by including polyfills in your project. Over time, less and less of your code will be executed and it'll still be working! Isn't it great?

One more thing before I'll dive deep: I would only advise those of you who consider themselves already "more than just jQuery developers" and have some experience with design patterns to try this, it's easy to make a mess when you don't have a clue what you're doing.

Selector Engine

In selector engine land, Sizzle is the most promising at this moment, it tries to be the universal engine for all libraries, and it got embedded in a few big ones already (jQuery/Dojo/Prototype). But there are lots of selector engines, and some JavaScript libraries even introduced their own, I'm not going into all of them. For more selector engines, see microjs.

So those engines are a lot of code, which we only need for IE <= 7. Somehow we'll have to include it for IE <= 7, but not for all the other browsers. Polyfill to the rescue! A while ago when I needed exactly that, it wasn't there yet, so I put my own polyfill with Sizzle together, you can find it as a Gist on Github. It's really only the engine with a wrapping function around it, if the spec is already implemented by the current browser, it doesn't do anything at all, but if it isn't implemented, it polyfills querySelector() and querySelectorAll() with Sizzle immediately behind the functions.

Events

Events are more easy, you can just implement those yourself, or at least you don't have to steal a lot of code. There are of course 2 event models, W3C's and Microsoft's. The most simple solution would be to take John Resig's addEvent(), it'll most likely suffice. And I wouldn't even include removeEvent() until you need it, I very rarely use it.

And depending on whether you will use it or not, you might miss custom events as well. This boils down to implementing the Observer pattern in JavaScript. You can build one around the addEvent() you just added, or write seperate functions for it, whatever you like. I slightly prefer to keep those things together, since its almost the same anyway. For a plain observer pattern I'm going to link to Dustin Diaz' Observer, it's a clear and simple implementation.

DOM

Depending on how much you started using the traversing functions from your library (next, prev, parent), you could start working manually with the methods and properties of Node, Element and Document. That should get you everywhere you want. If you'd rather have those shortcut methods back, have another look around on microjs, there's a lot over there.

Sticking to the jQuery example, in the case of manipulation, most methods used will probably be attr, html, val, and maybe some append or prepend. These are easily replaceable by methods of those same Node/Element/Document objects. But! Those DOM objects are really buggy implemented in almost any browser, and that's what your library is fixing, abstracting it away for you. You should try working with the browser objects, and see if you can handle the bugs. If it's not that big a problem for you, stick with it! If it is, maybe you should plug-and-play a micro library in that does the DOM stuff for you.

You might also not be willing to wait for window.onload(), and prefer the faster document.ready() and other equivalents. Again you have several options here, but I'm going to steer you to the fastest and smallest one I know of, Dustin Diaz's ready.js.

HTTP Requests

These are quite similar to events, there's W3C's and Microsoft's object. Luckily, we can forget about the Microsoft one, since from IE7 and up, W3C's XMLHttpRequest object is implemented in IE. This object is really easy to use, so I'd advise to use it directly. If you're really going to use it a lot, you could wrap it with a small function to make it slightly easier to use, but we're talking syntaxical sugar there. You could also go see microjs again if you're lazy.

And make sure to structure your code nicely to keep it all maintainable. It's more important now your code base will be bigger. I think my next article might be about that.

And as a closing note I would love to hear from all the problems everyone bumped into when trying this, and what solutions you picked! Cheerio!