Monday, July 29, 2013

Time To Go Native With HTML(.js)

In the last few months, i have been drifting away from jQuery, slowly, quietly. Removing dependencies on it in my "wheels", getting my brain down a level and into the native DOM. A few weeks ago, there came a watershed moment; i learned of Voyeur.js and inspiration struck. I realized that jQuery might just be in my way...

jQuery is a wrapper, a completely alternate API to the native DOM. It's a great API, no question, but it has begun to feel a bit unnecessary. The native DOM, after all, is far richer and less troublesome than it ever was back when i first fell in love with jQuery. Voyeur, by contrast, wraps nothing. It simply enhanced the DOM, a little here, a little there. It gave a tasteful sprinkling of ES5 sugar to a C++-style interface that happens to be exposed to a JavaScript environment. Sure, the dot-traversal of nodes by tag names using lazy getters was a delightful hack, but that wasn't what grabbed me. The inspiration was the idea that a few little additions to the DOM might be all it would take to make it feel comfortable to "go native".

But, Voyeur seemed centered on the dot-traversal of the document body. The API it gave offered no way to work on the document head, and the .create and use() features felt a bit unrefined, even awkward. Hardest of all for me to accept was that the code was not ripe for hacking, for extending, for enriching. So, i reinvented it and turned it into a JavaScript library called HTML.

I know what you're thinking. "HTML"? Seriously? The name is taken; it's un-Google-able; it lacks the flavor and pizazz of "Voyeur".  But it has two things i love; two things i cherish:
  1. It reads right in my code. The library starts on the root element <html> instead of <body> (like Voyeur). It is the root element. And it is all about HTMLElements. There is no name more readable and self-descriptive that i could give it.
  2. It constrains my code. If i named it something fancy like "Pizazz", it could become anything. I don't want that. A functional name centers and focuses development on a single purpose.
But enough about that; you get used to the name quickly. The code and what it enables are what excite me. Check out the demo and the API to get some hints at what you can accomplish. Pay close attention to what the each() function can do. It's the heart of the whole "befriend the DOM" motto for the project, as it makes it oh-so-easy to get/set/call DOM properties and functions on one or more elements. Unless you get crazy with the field aliases, the property syntax is composed of native DOM API, so their documentation is HTML's documentation.  It keeps things lightweight, consistent and future-friendly, as browser makers push new features.

Considering the ease of working with HTML thus far, i think my days of using jQuery are numbered. Right now, HTML works in all browsers IE9 and better.  Even the quickly diminishing group of IE8 users can be supported by conditionally including things like es5-shim/es5-sham and this lovely polyfill. I should, of course, point out that the dot-traversal portion of HTML is not polyfillable at the present, but everything can be made to work.  I think for new developers who are not required to prioritize antiquated versions of IE, including jQuery's large alternative API will very soon no longer be worth the KB.  And i am hoping that this little (2KB) HTML(.js) will help make that transition easy.

Yes, my fellow developers, the native DOM can be your friend!