jQuery, the Rosetta DOM

I've recently been rolling a node project essentially from scratch, largely so that I can actually learn Node, but also largely due to my aversion of introducing unnecessary libraries. Ever since the first ADO wizards for VB6, all too often libraries do the first 80% of what you need in record time, but getting the last 20% (which can be features, but is often also optimization and bug squashing/code-arounds) done takes more than twice the time you initially "saved". And except for what was just short of a two-day rabbit hole into returning gzipped files (I decided I should gzip on the fly, which is cool, but not mvp), it's gone almost painlessly.

Over the years, I've found that you usually have to be proficient enough to write your own library to use an external one mindfully, and that time, imo, is often better spent writing code that targets exactly your own use case instead. Nobody knows your pain points better than you do, and nobody should know how to take them away better either.

Well, I've often admitted one exception to my library aversion in client-side Javascript ^[1]: jQuery. Even I (circa 2008-2013) thought you'd have to be an idiot not to include jQuery by default.

Recently, though, even my jQuery love has waned. See http://www.sitepoint.com/jquery-vs-raw-javascript-1-dom-forms/ for some context:

The debate is still raging [he does have 74 comments currently -mfn] on my recent Do You Really Need jQuery? article but, in summary, there are two reasons why using jQuery is a good idea:

• you need to support IE6/7/8 (remember you can't migrate to jQuery 2.0), or
• without jQuery, you'd spend longer writing a jQuery-like library than developing your application.

Or, as Rob Niedermayer (I'm assuming) says on knockoutjs' website...

Everyone loves jQuery! It's an outstanding replacement for the clunky, inconsistent DOM API we had to put up with in the past. jQuery is an excellent low-level way to manipulate elements and event handlers in a web page.

And here's a quote from the "Do You Really Need jQuery?" article:

jQuery is an Abstraction

If you think web development is tough now, try developing JavaScript code in a browser from five or ten years ago. The typical problems:

• DOM navigation and manipulation differ. For example, Firefox (correctly) included whitespace in the DOM, IE6 didn't. Therefore, you couldn't depend on node.firstChild returning the same thing.
• Ajax was natively supported in most browsers, but an ActiveX control in IE (even though Microsoft invented XMLHttpRequest).
• IE had a different event model but even the other browsers had their share of inconsistencies.
• CSS2.1 support varied immensely.
• Animation could be difficult especially when coping with box model differences, form controls and iframes (IE6 placed select boxes and iframes above everything else on the page).
• Developer tools were rudimentary. Prior to Firebug, Firefox's error console and IE's clunky modal error box were the only built-in browser tools.

Developers had to write abstraction functions to get around these issues. jQuery, Prototype and MooTools evolved from the primordial chaos; the libraries smoothed over the cracks and provided useful missing features such as DOM selection from CSS selectors.

The title to that section really is the take-home. jQuery is an abstraction layer to make fairly different browser object models look the same when you're coding. jQuery was a Rosetta DOM for browsers in the 1990s and 2000s.

But if you've spent much time on the Mozilla Developer Network, you'll notice that the browser compatibility sections are starting to look a lot less nasty. Non-IE browsers have had good standards support for a few years now, and if you can limit IE to 10+, well, I'm not sure you do need a Rosetta DOM jQuery any more.^[2] I mean, when we get to the point that someone gains tons of traction for posting that Safari is the new IE, we know we're getting somewhere.

Now look, jQuery rocks. It's, to use "rocks" as many times as possible, rock solid in its rockery. I really like using it, and, during a job interview a few years ago, when asked about Javascript libraries, I said jQuery has a special place in my toolbox where I consider it as good as a first-party lib. It's that solid, in my experience (vs., say, ExtJS 2 or ArcObjects in the 'aughts. Man, those were the bad old days.).

jQuery, the gateway drug

So I'm not opposed to jQuery's use, except that I've slowly come to see that jQuery is a gateway drug. I've talked about overuse of client-side templating here before (the only one I can find right now is this one; surely I've spilt more pixels than that), and I'd argue that the situation my team found itself in there -- where, as a company, we had a system that nobody bothered to test at scale on IE8, our minimum sys requirement, and our KnockoutJS-based system was completely dead on that platform a few weeks before release -- was enabled by our overly comfortable approach to library use.

Heck, I'd consider recommending not using jQuery simply because so many libraries depend on it. Without jQuery, you can't easily slap in everything and the kitchen sink.

Unfortunately (he said only half-jokingly), Angular and other templating libraries have their own mini-libs that will gracefully step in if jQuery isn't used, so you can still get into trouble if you're not careful. Here's my quick 2¢ on templating: If you have data-stores and business logic on the client, you're doing it wrong. It would be interesting to figure out how often Google's folks use jQuery with Angular, and how often they limit themselves to jqLite. In a sense, creating jqLite for Angular is exactly what I'm proposing here.

But if you require folks know how to write standards-compliant Javascript, it quickly becomes clear that your company's culture prefers writing code tailored specifically to your set of problems rather than grabbing something off the rack you're going to be hemming and patching for life.^[3] Over the long term, especially if you don't have legacy code and legacy browser users, you might find you save a lot of time and money.

Aside: Which brings me to another disappointment that I'll compulsively mention briefly -- if you do use an open source library, for heaven's sake contribute back to it. You will find problems. It's useful to make defensive patches to it that don't touch the original if you think your "issue" is too specific to your use case, but it's also important not to let the concept of a third-party lib hamstring your development as if the code was untouchable.

We used NHibernate at a previous job, and had so much invested in a certain release that we were scared -- rightfully, I'd argue -- to upgrade. But why we wouldn't branch that old version and start releasing fixes we knew were needed, I have no earthly idea. Though I think I argued successfully with the folks whose opinions mattered [to me] that we should branch and extend, I still consider it a huge failing that I couldn't reach critical mass there where we actually made stories and improved the library.

Update: Looks like I'm not alone thinking the library soup needs to end. Interesting post from Allen Pike, which also touches on Angular breaking backwards compatibility with version 2. It's bad enough how quickly these things go by the wayside from neglect. Do popular ones have to die too? Of course, the bottom line is that if you'd stuck to vanilla, standard-compliant browser-based JavaScript (or minimalist libs), you'd be completely (to very) insulated from moves like this. And, as I mentioned in the aside, if anyone Does the Right Thing, Angular 1.0 will continue to live well past the team's leaving it, if that's what they plan to do. That's the proverbial beauty of open source.

[1] There are certainly other libraries I don't mind using, and some that get close to this "good as a first party" status, but they're few. I really like MailKit so far on .NET, for instance. And of course I like "real" dbms systems. But I'm library adverse to the point I always have to double check that I'm not exhibiting NIH syndrome.

[2] I realize this is easier said than done. But places that have to target IE9- are being driven by corporate clients whose workplaces are stuck on Windows XP, I'd wager. The usage numbers suggest that IE10+ is well over half of all IE use, and that leaves less than 7% of users worldwide that need to learn how to install Chrome to their Documents folder.

[3] Yes, I realize you'll be hemming and patching the bespoke stuff too. Hopefully you'll still suffer the analogy.

Labels: coding, javascript, jquery, long, style