if document.write is bad and innerHTML is evil, then what to use?

Bobafart · 12-26-2008, 03:17 AM

I believe document.write() is bad because it causes the browser to have a performance decrease (correct me if I am wrong).

I believe innerHTML is going to be phased out soon so I should no longer user that.

If that is the case, then what should be used when sending data to the browser?

example code would be helpful too.

thanks

itsallkizza · 12-26-2008, 04:54 AM

I haven't heard anything about document.write() decreasing browser performance (could be wrong) but that's irrelevant because you are right in avoiding it's use because it is most definitely "bad form." It only works with webpages if you use it on the page load; if you use it during runtime, it will replace your entire document with the input. And if you're going for strict xhtml structure it isn't valid code.

I also haven't heard anything about phasing out element.innerHTML. It is crucial to the majority of current scripts that deal with html content manipulation. However, again, if you're adhering to strict xhtml standards, then it would be better to create elements using document.createElement and element.appendChild (and other native DOM node manipulation functions). For inserting text into an existing element, it's definitely still acceptable code (and completely cross-browser), but keeping with our xhtml motif, it would be even better to use document.createTextNode - especially when working with Mozilla Selections and Ranges.

I'll write up some sample code that's 100% xhtml compliant in a bit.

Code:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<title>Example</title>
<style type="text/css">
</style>
<script type="text/javascript">
// <![CDATA[

function addSomeContent()
	{
	var doc_body = document.getElementsByTagName("body")[0];

	var article_header = document.createElement("h1");
	article_header.appendChild(document.createTextNode("Article Title"));
	var article_body = document.createElement("p");
	article_body.appendChild(document.createTextNode("I have so much to tell you about this topic I don\'t know where to begin..."));

	doc_body.appendChild(article_header);
	doc_body.appendChild(article_body);
	}

function addEventHandler(to_element,event,handler)
	{
	to_element.addEventListener ? to_element.addEventListener(event,handler,false) : to_element.attachEvent("on"+event,handler);
	}

addEventHandler(window,"load",addSomeContent);

// ]]>
</script>
</head>
<body>

</body>
</html>

rnd me · 12-26-2008, 05:16 AM

i think the momentum is shifting back away from XML.

i see giving up such fast and efficient code a step backwards.

furthermore, browsers will likely never lose the capacity to correctly display HTML4.01 or XHTML1.0Trans.
until something drastically better comes along (xhtml is not it), why use anything else?

you can go an "all dom" route, but it requires a lot of extra code, is slower, and harder to maintain than simpler methods. it's a bit of a pain to "spread out" attributes over many statements. the alternative is extra kilobytes of code to make dom easier.

for instance, look at the discrepancy of coding ease between

Code:

window.onload=function(){
  document.body.innerHTML= "<h1>Article Title</h1>  \
    <p>I have so much to tell you about this topic I don\'t know where to begin...</p>";
}

and the posted dom example that essentially does the same thing. one also save a ton on bandwidth...

if you don't use strict, you can use a simple hybrid approach that uses the dom to modify the document, and .innerHTML to prepare tags for appending.
that works very fast and well in my experience.

you might look into some libraries like jQuery, and others that can greatly simplify dom access as well.

itsallkizza · 12-26-2008, 05:52 AM

Just wanted to second rnd_me:
Though the code I posted is strictly speaking XHTML compliant, when running large loops, it is enormously slower (especially on IE).

Personally I only use createElement and appendChild for table creation. For obvious reasons, a table created dynamically should be created/edited in such a way as to maintain strict XML standards, if only for data capture/migration. And I never use createTextNode (there really is no reason not to just use innerHTML instead).

In all other cases (non-tables) I will always have the general element structure already created server-side (for example, I'd already have the h1 and p tags organized/styled) and use innerHTML to change the content. There really are few cases where it's best to use client-side script to add (as opposed to manipulate) major content - it's impossible to SEO and not part of your initial DOM.

EDIT: I may have to take back what I said about speed. I ran some numbers and this is what I found.
For these two functions in question:

Code:

function func1()
	{
	var doc_body = document.getElementById("place");
	var article_header = document.createElement("h1");
	article_header.appendChild(document.createTextNode("Article Title"));
	var article_body = document.createElement("p");
	article_body.appendChild(document.createTextNode("I have so much to tell you about this topic I don\'t know where to begin..."));
	doc_body.appendChild(article_header);
	doc_body.appendChild(article_body);
	}

function func2()
	{
	var doc_body = document.getElementById("place");
	doc_body.innerHTML = "<h1>Article Title</h1><p>I have so much to tell you about this topic I don\'t know where to begin...</p>";
	}

They performed at identical speeds up until iteration 500. It wasn't until around 650 iterations that func2 began to perform noticeably better, and even then it was a small difference.

Now, when you change "innerHTML =" to "innerHTML +=", func2 is always slower (for obvious reasons). Now most of the time, a smart programmer won't mess with innerHTML until he has compiled his entire insertion into a single string. Still, this goes to show that DOM methods aren't always that much slower - something I wasn't aware of before tonight.