The DOM is still a mess
James Halliday, or better known as Substack, wrote up a good piece entitled “weaning yourself off jquery”. He makes a decent argument that we don’t need DOM libraries anymore, but the fact of the matter is, we do. Unless you only care about one browser–or this is not a production app–sure, not using jQuery is fine. As someone who’s been doing JS a long time writing vanilla, jQuery, and MooTools to work with the DOM, it’s nowhere near stable and telling new JS people it is will scare them away from JS on the web. I’ll briefly give some examples of how his simple examples are not realistic in a real world application:
attachEvent vs addEventListener
He gives the perception that these two eventing methods are the same aside from the name. They’re not. There’s many differences on how and what they return in the event object. A simple, and very well known issue for anyone who’s had to code for IE<9, is the “Object required” error when asking for e in attachEvent(’onclick’, function (e) {});. There’s a variety of reasons for this and it’s something I’ve tripped over myself. Most commonly it’s because IE8 doesn’t have e.target. The other issue I personally have had issues with is the event object being null when working with iframes.
Lastly, remember that now you have 2 event handlers everywhere you need to attach an event. If you don’t like that and want to consolidate that you end up writing some function like jQuery’s which will end up looking like this mess: https://gist.github.com/OscarGodson/e2b8b917e947765b543f.
If that wasn’t painful enough there’s the issue that events always bubble. You can’t capture them. Then the other issue is that this is referencing window rendering it basically useless.
http://stackoverflow.com/a/1250015/144833
http://stackoverflow.com/questions/11920063/addevent-giving-null-event-object
innerHTML
innerHTML is actually extremely buggy in IE. It doesn’t work correctly with <select> elements, completely craps out with tables–yes, tables are still used for tabular data–and handles whitespace differently in <textarea>s and <pre>s. There’s more, but these were the ones I could think of and have dealt with personally.
http://support.microsoft.com/kb/276228
http://stackoverflow.com/questions/1066443/ie-innerhtml-error
http://web.student.tuwien.ac.at/~e0226430/innerHtmlQuirk.html
Styles
This is one you’d think was simple. It actually amazes me just how different browsers are when handling styles. A good example is trying to just do element.style.float will fail in half the browsers. Not just IE. To do a cross browser float style you’d have to do:
element.style[’float’] = ‘left’;
element.style[’cssFloat’] = ‘left’; // Firefox
element.style[’styleFloat’] = ‘left’; //IE
Or, z-index:
element.style[’z-index’] = ‘left’;
element.style[’zIndex’] = ‘left’; // Firefox
Nope, not even styling works the same across “good” browsers as you can see. Try doing much styling and you'll find that these are only a few examples of cross browser styling inconsistencies.
Attributes
As with styles, something that seems straight forward like changing or updating an attribute is not. In IE, for example, you can’t change some attributes such as style. You also can’t change the type attribute after an element is in the DOM. Those are just two examples. setAttribute has a bunch of problems in IE and it’s rather incomplete.
Aside from not being able to set them at all, even more frustrating is when different browsers have different ways of setting them. A common example is getAttribute(’classname’) for IE and getAttribute(’class’) for others. An even stranger one IE does is you need to do getAttribute(’htmlFor’) to get/set a for attribute whereas other browsers let you just do getAttribute(’for’).
http://stackoverflow.com/questions/2119300/setattribute-is-not-working-for-style-attribute-on-ie
http://stackoverflow.com/questions/3793598/input-setattributetype-checkbox-ie-bug
I could go on, but…
It’s not really worth it. You can simply put in any of the methods mentioned in the original blog post by Substack and add “[browser name]” and find some sort of bug or difference between it and another browser.
I’ve worked with many DOM libraries as part of the jobs I’ve had over the years. I worked with vanilla JS for years and still do for my open source projects, jQuery for years, and currently working with MooTools. I can’t imagine, ever, trying to build a production quality application with vanilla JS. For the past month I’ve been back porting an entire app to work in IE9-10. I can tell you, writing cross browser support without an abstraction layer isn’t feasible.
DOM libraries keep your code more readable. Having to sift through three if/else’s just to add a style or every block of code checking for feature support of common things like dataset or similar is silly. If you tried to take all these common issues and move it into your own like “dom.js”, you’re just rewriting DOM libraries, and to what benefit? Would you really rather re-solve these problems others have already solved and debugged or would you like to write apps?
To new JS developers, it’s not worth it. We use JS libraries for all kinds of things. Unless you’re actually interested in the DOM and cross browser issues, don’t waste your time on this stuff and use a DOM library. Spend your time making cool shit that hasn’t already been solved or could be solved better.
