XMLHttpRequest object and which order you have to use to compatibly look for them. No longer do you have to hack around Safari’s chipmunks-on-crack animation speed. Someone else has already run into that, figured it out and made the code available; hallelujah!
The field of battle
- Some programmers are control freaks and would rather have their Internet connections amputated than use a line of code they didn’t write themselves.
- Using a library will unnecessarily “bloat” your code, either by increasing the amount of JS users have to download, or by slowing down your code with the overhead of using the library.
Let’s look at each one of these in turn.
NCBM (Not Coded By Me)
The control-freak problem is tough for me to understand, because I don’t suffer from it. I’m a self-taught programmer, and I learned very early on that good libraries are a programmer’s best friend; they save you having to solve a problem that’s already solved, and reading the code can often be a useful learning experience for non-experts. The control-freak viewpoint of “I don’t trust anyone else’s code” runs directly counter to that, and makes me feel a bit uneasy. Pretty much every programmer has to trust somebody else’s code at some point:
- C and C++ programmers have to trust the people who provide their compiler and their libc and/or STL.
- Java programmers have to trust the people who provide their JVM and class library, and C# programmers have to trust the people who provide their CLR and .NET libraries.
- Programmers who write Python, Ruby, Perl, PHP or other interpreted languages have to trust the people who provide the inerpreter.
- Everybody listed above has to trust an operating system vendor.
The library that ate Chicago
Library “bloat” is a tricky criticism to deal with, because it’s really about two separate issues: one is the amount of code your users end up downloading, and the other is the amount of time it will take for that code to execute in a web browser.
When it comes to the number of bytes sent down the wire, using a library does introduce some measure of “bloat”; you’re probably not using everything the library defines, so no matter what you’re including more code than you would have otherwise.
“Bloat” in the sense of code that’s slow because of overhead introduced by the library is another matter, and is usually more of a tradeoff than anything else. For example, lots of libraries provide methods for using CSS selectors or XPath queries to specify a set of elements to retrieve from a document, and these methods have, historically, been relatively slow (though they’ve improved a bit with time). Whether to use these methods, then, comes down to weighing two options against each other:
If you don’t use them, you’re stuck with the DOM API, which is cumbersome and ugly to use; you end up with code that looks like a train wreck, mashing together repeated calls to
getElementsByTagName, iterations over
childNodesand endless regular-expression tests against
className. It’s not uncommon to need a way to fetch, say, all the
lielements with a given class name inside a
ulwhich is the third child of the fourth
divinside a container with a particular
id, and the DOM API is horrifically bad at expressing that sort of thing, so you end up writing lots of one-off slabs of code which fetch elements according to specific parameters.
- If you do use them, you get the benefits of clean, concise syntax — CSS selectors and XPath queries are designed from the ground up for quickly expressing conditions which describe an element or set of elements — and of generality: when the HTML changes, you just change the selector or query, instead of rewriting a huge mishmash of DOM method calls. But now you’re incurring the overhead of a system which can parse CSS selectors or XPath queries, and which can’t optimize the eventual lookups as much as a specific, one-off hack.
Given that computers are continually growing faster and that there are reliable ways to make expensive bits of code execute immediately while a user is still scanning the page (before they can interact with it, they have to see what options they have for interaction), it’s not hard to see why a lot of people choose to use the fancy methods with the clean syntax. But at the same time, nobody’s forcing anyone to use them, and performance-critical bits of code can always be rewritten using specific one-off collections of DOM methods.
The knowledge gap
- You might not be able to figure out how to use a particular library.
- If you can figure out how to use a library, you still might not be getting the most out of it because you don’t know what options it really gives you.
- The library you end up using might have bugs which you don’t understand and can’t fix.
- You might inadvertently use it in an unsafe way and end up with cross-site scripting bugs or other security problems.
Let’s break for the day