innerHTML vs. DOM = pot noodles vs. real cooking
Following four days of AFN (Away From Network - I did use a keyboard though), I realised that digg.com dugg me and AJAXian once again linked me. Well, not me but the From DHTML to DOM Scripting article.
Notice the title: from DHTML to DOM. Not “why innerHTML is rubbish and you should not use it, never, really, don’t, never ever!”
I also realised that AJAXian had the unfortunate wording in their post that I might have meant that with the article and the comments on the AJAXian post were an interesting read indeed.
However, digging deeper (oh dear), I found that this is an no-barriers-handbags-out-geek-fight topic at the moment as many AJAX enthusiasts and heavy load web application developers (the applications are heavy load, not the developers) rightfully like innerHTML and consider it a necessary and good solution for a re-occuring problem.
Jeremy Keith started it, daring to call innerHTML proprietary in the painless code creation with DOM builder post at the DOM scripting task force blog.
Jonathan Snook responded quickly and wondered what’s wrong with innerHTML.
We all know that Jeremy had been in a painful love/hate relationship with innerHTML for a long time, as he outed himself in December talking about his innerHTML dilemma.
He is not the only one with this problem, as Ryan Campbell of Particletree also considered different methods than innerHTML in April calling it Changing the DOM.
This is all well and good, but is it really that much of a problem?
My “I like to chime in but I really just want to keep the fight going and not get involved myself as I forgot my handbag” award goes to Dustin Diaz who kept the comments closed on his blog entry on the subject called innerHTML and DOM Methods. So why post at all then? Why not just comment on Jeremy’s blog?
I liked the quote:
Well, for what it’s worth. It’s about the user. innerHTML is plain and simply faster. Yes, it’s non-standard, but so is xmlHttpRequest. Sure, I know the W3 is developing a working draft on xmlHttpRequest… I say, let’s standardize innerHTML. Not to mention, it would be easy. Everyone already knows how it works, it’s simple to use. It’s fast. It’s already supported across major browsers. Hey, just so we feel better, why not call it innerXML. That way it’s future compatible when xml becomes more of a standard and better supported.
This is exactly the problem with innerHTML - it is not innerXML. It is a browser/web/html only property, and the DOM is not only for browsers, web and HTML. You can use JavaScript and the DOM to convert XML, you can even script applications with it (check the Adobe site for great Illustrator and Adobe Bridge examples), and the idea is not to keep DOM scripting to the browser or even to HTML as a means of structure. I especially chuckled at the notion that XML will be supported in the future. I know the idea was supporting XML in browsers, but talking about web standards and considering XML a technology of the future is simply missing the mark.
So, here are my ideas about this subject:
innerHTML is pot noodles - Anyone can use it quickly, you put the kettle on and after the water boiled and you let it rest for a minute or so and then it is feeding time. It is:
- very fast and convenient
- cheap and easy to prepare
- well known and available in a lot of stores
The problems are:
- You have no clue what is in the pot noodles
- You have no way of telling someone how to make own pot noodles when there is no shop around their area that stores them.
DOM scripting and using the DOM methods to create a real XML construct instead of a string of HTML is cooking your own pasta sauce:
- You know the ingredients and you measure them properly before applying them
- It is harder and takes longer to prepare, but the outcome is normally del.ici.o.us
- While you cook you learn about different spices, tricks to prepare the ingredients and mix and match them to make the perfect sauce
- You follow a recipe or invent your own - but you do follow a structured method of creating it
- You can explain how to create the sauce to someone on the phone step by step
So by all means: Use innerHTML when speed or ease of use is an issue, but don’t forget that the DOM offers a lot more than just changing HTML documents in a browser.
April 19th, 2006 at 12:48 pm
I enjoyed reading your point of view on the whole innerHTML vs DOM discussion. Personally I prefer DOM for the same reasons but so far I didn’t work on large projects which required speed optimizations so I wasn’t tempted to try innerHTML for this purpose.
April 19th, 2006 at 4:41 pm
I am very slowly (began last fall!) but steadily fleshing out a new version of my XMLHTTPRequest / AJAX “framework” called WarpXML, and I had to scrap the most perfect DOM implemenations and I am currently using innerHTML as it simply caused me a lot less troubles however I do realize that I might have to return and look at it really hard once more before I release it, because I would much rather have a working DOM implementation.
NOTE: I use the innerHTML in the process of dumping the retrieved xml nodes into the xhtml tree, all the rest is using DOM or my own tree models. I have used JS professionally since 1995, so it’s not like I’m trying to take the easy road here…
My current conclusion is that we are still in too much of a transitional phase to be all religious about these things.. sometimes it’s just the only way to get things done, before next summer.. ;)
April 19th, 2006 at 10:45 pm
I can only chuckle at the fact that you took my post seriously ;) Hence my comments were disabled.
April 21st, 2006 at 2:06 pm
This is an interesting topic :)
As a way to teach myself, I tried and created a simple “WYSIWYG” textarea editor (bold, italic…) in Javascript, and I worked hard to:
- only use the DOM,
- only use the resources of the current document (no external CSS, no external HTML page, and so on).
Conclusions:
- Even though it is possible not to use external resources, an IFrame sadly has to be created.
- To initialize the editor contents with the textarea contents, or put it back into the textarea,
<b>innerHtml</b>anddocument.<b>write()</b>have to be used.Those technologies are just too young in this area, and to date, building a whole stylesheet and content from the ground up, is impossible using only the DOM.
This apart, I’m rather satisfied with what I did: all else is 100% DOM.
Yves.
April 27th, 2006 at 3:05 am
Chris,
greetings. I was looking at your fabulous library of scripts, and I was wondering if it were ok to use one of yours for one of my clients. She’s planning to sell stuff on her site, and I thought that your “YADM - Yet Another Dynamic Menu” would make for a nice navigation. As your copyright states, you would like to be asked when using your scripts for a commercial website.
As a webdesigner, I am always trying to showcase nice work where appropriate, so if it is ok by you, I would highlight your menu work on my website (iserlohdesign.com), so that other designers become aware of your work. Again, I am looking to use your script on a single site for a single client. thanks.
Uli
October 12th, 2006 at 4:50 pm
I’ve been working on a big Javascript app for a major software company for about a year and a half. I found DOM methods to be slow and make my code less readable.
I really say this is yet another case where people should just use the right tool for the right job, but instead start talking about which is “right” and which is “wrong”.
March 6th, 2007 at 8:20 am
innerHTML is like paying for a hooker and DOM is like taking out a chick and trying to score.
December 19th, 2007 at 6:41 pm
You might be interested in a technique I’ve devised as an alternative to innerHTML. It still allows you to pass an HTML string, but your code is validated and inserted into the DOM using safe W3C methods. It uses XML and only requires 50 lines of code.
For details, please visit:
http://www.optimalworks.net/blog/2007/web-development/javascript/innerhtml-alternative