By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
457,887 Members | 1,150 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 457,887 IT Pros & Developers. It's quick & easy.

The need for speed: innerHTML versus DOM manipulation

P: n/a
Wherein I attempt to debunk some myths about the relative merits of
the two methods for programmatically adding content to a web page:

http://www.newfangledtelegraph.com/b...-manipulation/

Cheers,
-Andrew
-----
an****@hedges.name / http://andrew.hedges.name/

Jul 4 '07 #1
Share this Question
Share on Google+
5 Replies


P: n/a
"Andrew Hedges" <se*****@gmail.comwrote...
: Wherein I attempt to debunk some myths about the relative merits
: of the two methods for programmatically adding content to a web
: page:
: http://www.newfangledtelegraph.com/b...-manipulation/

Interesting reading. But it's lacking some things.

(1) What the heck is it talking about? Where are the links to the
source code? <g>

(2) It's okay to assume that everyone knows nothing. I found it
interesting, but lacking. Needs some more work. Perhaps links
to some source code demonstrating what it wants to explain?

: http://andrew.hedges.name/

Very nice pictures.

--
Jim Carlock

Jul 4 '07 #2

P: n/a
On Jul 5, 8:54 am, "Jim Carlock" <anonym...@127.0.0.1wrote:
Interesting reading. But it's lacking some things.

(1) What the heck is it talking about? Where are the links to the
source code? <g>
Hi Jim,

I did link in a couple of places to the code I used to run my tests.
I probably should have been more explicit about that. Here's the
link:

http://andrew.hedges.name/experiments/innerhtml/

Cheers,
-Andrew

Jul 4 '07 #3

P: n/a
"Andrew Hedges" wrote...
: http://www.newfangledtelegraph.com/b...-manipulation/
:
: I did link in a couple of places to the code I used to run my tests.
: I probably should have been more explicit about that. Here's the
: link:
:
: http://andrew.hedges.name/experiments/innerhtml/

Oh, I was thinking it was the original link you posted. I clicked upon
quite a few links there and when I looked at the source code for the
first link above, nothing seemed to make much sense.

The other problem I see with the information is that it does not list...

(1) The type of computer used to create the times.

(2) The type of server hosting the pages.

I'm pretty sure an IIS6 (aspx) server runs slower and delivers the
content slower than an IIS5 (asp) server or an Apache server.

(3) The server side software used in the deployment of the pages.
Again that tends to deal with the IIS6/IIS5/Apache thing, but when
running Apache, the server-side mechanism may be PHP or Perl
or other. That may apply I think.

Then there's the hardware used in the server.

(4) The amount of memory.
(5) The microprocessor.
(6) The networking delivery (1GB network or wireless or 10/100MB).
There may be other types (like T1) but that seems kind of silly right
at this moment. I think that applies as well, though.

I don't have an app at the moment to measure the times and compare
the times. So, if YOU have that already, it might be helpful to provide
a link to it. If you have the source code for the timer, that would be
even better.

The goal in any written content, involves:

(1) Make it easy to read and understand.
(2) Make it enjoyable.
(3) Provide as much as you can to try to get some proper feedback.

I found the reading enjoyable, and I felt like I could almost understand
everything. I just didn't know where the source code was to test things
and I spent too much time clicking upon links trying to find it.

The page needs to identify that source code more appropriately. I'm
thinking something along the lines of...

<ol>
<li><a href="#link_to_innerhtml_page">Test the innerhtml page here</a>.</li>
<li><a href="#link_to_dom_page">Test the DOM page here</a>.</li>
</ol>

Then you need to provides something along the lines of...

<p>To test the times and get your own times, please use the
<a href="#link_to_timer">timer</a>, here. To compile this small
application, you will need a proper <a href="#link_to_compiler>
compiler</a>.</p>

Those are just some quick things I threw together on the spur of
the moment. They could be reworded a little better, but that
conveys some concepts that'll help out.

More detail is needed. Assume the people you want to deliver
your concepts to need as much help as you can provide and
that they like simple details. I think you explained it succinctly,
and it ends up as very easy to read, very pleasurable to read,
but misses out on pointing out exactly where you want the reader
to go to next. Next/Previous buttons/links help in this regards
sometimes, but I think an enumerated list works just as well too.

The nice thing about the enumerated lists is that if the topics are
short and concise, the links could be place in a server-side
include and placed on every page...

<p class="center_these"><a href="DOM_page.asp">DOM Test</a|
<a href="innerHTML.asp">InnerHTML Test</a| <a href="timer.asp">A
Free Timer</a></p>

<shrugYou could use fragment-uri's (anchors) in place of separate
pages. But clearly identify each section and place the menu's under the
<h2>topics</h2>.

Oh, and when I said source-code, I was thinking that you need to
place links to another page or a fragment-uri (anchor) which provides
the source inside some <preblocks, and then comments in the source
code explain what's going on.

Hope this helps.

--
Jim Carlock
Jul 5 '07 #4

P: n/a
Hi again, Jim,

On this page (the one to which I linked in the article and above):

http://andrew.hedges.name/experiments/innerhtml/

....I do, in fact, list the type of computer, processor, etc.: "I ran
the two methods outlined below on my Apple MacBook (2.0GHz Core 2 duo
processor, 2GB of RAM) in several browsers. I ran each test on each
browser 5 times set to loop 1000 times." The web server and network
speeds are irrelevant since the processing is all done client-side.

On that page, I also list the most relevant parts of the code, but
being client-side, all the code is there for the viewing (including
the functions that do the timing). That page allows you to run the
test yourself and encourages you to comment with your own results.

In any case, I appreciate the thoughtfulness of your comments.

Cheers,
-Andrew

Jul 5 '07 #5

P: n/a
Andrew Hedges wrote:
Hi again, Jim,

On this page (the one to which I linked in the article and above):

http://andrew.hedges.name/experiments/innerhtml/

...I do, in fact, list the type of computer, processor, etc.: "I ran
the two methods outlined below on my Apple MacBook (2.0GHz Core 2 duo
processor, 2GB of RAM) in several browsers. I ran each test on each
browser 5 times set to loop 1000 times." The web server and network
speeds are irrelevant since the processing is all done client-side.

On that page, I also list the most relevant parts of the code, but
being client-side, all the code is there for the viewing (including
the functions that do the timing). That page allows you to run the
test yourself and encourages you to comment with your own results.

In any case, I appreciate the thoughtfulness of your comments.

Cheers,
-Andrew
Well I ran the tests on my PC - 433 celeron, Win98, and got identical
speeds for firefox, but the older IE6 was twice as fast on inner HTML as
DOM whatever that means ;-)

It wouldn't let me post results tho.
Jul 5 '07 #6

This discussion thread is closed

Replies have been disabled for this discussion.