DOM or innerHTML?

59 views
Skip to first unread message

Kelvin Wu

unread,
Dec 21, 2009, 10:02:51 PM12/21/09
to iphone...@googlegroups.com
Hi,
 
A little bit off tipoc, not related to iUI but I am thinking of the question about Javascript performance, especially on mobile phone.
 
To write HTML code in your Javascript, you can write DOM directly such as:
 
var cellTitle = document.createElement("td");
cell.className = "TableCell3";
var labelTitle = document.createElement("lable");
labelTitle.className = "LabelTitle";
labelTitle.innerHTML = title;
cellTitle.appendChild(labelTitle);
rowTitle.appendChild(cellTitle);

Or simply filling in innerHTML:

root.innerHTML += "<td class=TableCell3><lable class=LabelTitle>" + title + "</lable></td>";

The above two work exactly same. The first one looks more "professional" while I personally feel that the second one could be much faster and less CPU usage (less battery consumption), when you have a complicated HTML page, you may need to carefully write hundreds of lines for DOM objects or, just copy and paste HTML code to innerHTML...
 
So my question is, is that true, using innerHTML is generally faster than creating DOM?

--

Sent from my mobile device. Ignore the typos unless they're funny.

Chrilith

unread,
Dec 22, 2009, 4:19:50 AM12/22/09
to iPhoneWebDev
innerHTML was a microsoft extension and is now part of the HTML5
standard.
So, both are now 'professional'.

toriaezunama

unread,
Dec 22, 2009, 5:19:18 AM12/22/09
to iPhoneWebDev
This site has a benchmark comparing the use of innerHTML vs DOM
manipulation
http://andrew.hedges.name/experiments/innerhtml/

I got the following results on an iPodTouch
# of times time ms
innerHTML 10 32
100 2090
1000 Took too long to run
DOM 10 1
100 12
1000 87

Although the test isn't perfect - for example: every created div is
the same. Not a very real world situation - the results do prove
interesting.

Hope this helps

Kelvin Wu

unread,
Dec 22, 2009, 11:07:37 AM12/22/09
to iphone...@googlegroups.com
thanks for the link, i tested it too, on nokia e71, which is webkit engine too, the innerhtml crashed nokia's browser... that completely overturned my previous thought.
 


 
--

You received this message because you are subscribed to the Google Groups "iPhoneWebDev" group.
To post to this group, send email to iphone...@googlegroups.com.
To unsubscribe from this group, send email to iphonewebdev...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/iphonewebdev?hl=en.


Kelvin Wu

unread,
Dec 22, 2009, 11:20:53 AM12/22/09
to iphone...@googlegroups.com
Sorry I must correct myself, I just took a look at its test code, the innerhtml test code is in a unusual or extreme way, it pushes strings into array, then join array. In fact, in the real world, innerHTML is moe often used to concatenate a string by something like innerHTML += "xxx"; re-write the test code by this way, the result is much much faster than DOM.

toriaezunama

unread,
Dec 23, 2009, 5:22:14 AM12/23/09
to iPhoneWebDev
Having just read this
http://www.quirksmode.org/blog/archives/2009/08/when_to_read_ou.html
article and taking a look at the code from the original article I have
feeling that the results are incorrect.

I had noticed when running the tests that although the DOM test with
1000 runs reported 87ms, the time from pressing the button to start
the test and the results being shown was more in the order of 4
seconds. I think this article explains why.

Right now i don't have access to my iphone or mac so cannot verify any
of this but thought this might be of interest
Cheers


On Dec 22, 4:20 pm, Kelvin Wu <kelvin...@gmail.com> wrote:
> Sorry I must correct myself, I just took a look at its test code, the
> innerhtml test code is in a unusual or extreme way, it pushes strings into
> array, then join array. In fact, in the real world, innerHTML is moe often
> used to concatenate a string by something like innerHTML += "xxx"; re-write
> the test code by this way, the result is much much faster than DOM.
>

> On 2009-12-23, Kelvin Wu <kelvin...@gmail.com> wrote:
>
>
>
>
>
> > thanks for the link, i tested it too, on nokia e71, which is webkit engine
> > too, the innerhtml crashed nokia's browser... that completely overturned my
> > previous thought.
>

> >> iphonewebdev...@googlegroups.com<iphonewebdev%2Bunsu...@googlegroups.com>

Andrew Hedges

unread,
Dec 24, 2009, 1:08:44 PM12/24/09
to iPhoneWebDev
Hi Kevin,

Yes, there are problems with my innerHTML versus DOM test. However,
using Array join() to concat the strings is actually much faster than
using += over and over again, so that's not one of them. The test
isn't perfect, but it has been my experience that creating a DOM
fragment and attaching nodes to it, then attaching the whole lot to
the DOM tree is, for all practical purposes, as fast as innerHTML.
Personally, I almost always use innerHTML these days for the sake of
convenience.

Regards,
-Andrew

> > >> iphonewebdev...@googlegroups.com<iphonewebdev%2Bunsubscribe@google groups.com>

Andrew Hedges

unread,
Dec 24, 2009, 4:59:09 PM12/24/09
to iPhoneWebDev
By the way, I've updated the innerHTML versus DOM APIs speed test
using PPK's method. See the new version at the same old URL:

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

toriaezunama

unread,
Dec 25, 2009, 2:57:38 AM12/25/09
to iPhoneWebDev
Thanks for updating the speed test Andrew, the test is a really useful
resource.
The addition of iphone results were or particular interest.

With innerHTML being quicker/more intuitive/less prone to error we
seem to have that rarest of occasions a win/win situation.

RobG

unread,
Jan 12, 2010, 6:19:12 AM1/12/10
to iPhoneWebDev

On Dec 25 2009, 7:59 am, Andrew Hedges <segd...@gmail.com> wrote:
> By the way, I've updated the innerHTML versus DOM APIs speed test
> using PPK's method. See the new version at the same old URL:
>
> http://andrew.hedges.name/e/innerhtml/

This issue requires more analysis than a simplistic comparison of how
fast innerHTML and DOM methods can add a large number of identical
elements to a simple page. Some things I have noticed about the test:

1. According to the numbers on the web site, using DOM was 10% slower
than innerHTML on iPhone 3G. My own iPhone showed similar results

2. For the tested browsers other than IE, the speed difference is
negligible

Other factors to consider:

1. The logic to generate the elements or HTML on the client may well
be far more complex and require more processing time than adding the
elements to the document using either innerHTML or DOM

2. Adding to the innerHTML of an element that already has a large
number of child nodes can be very much slower than appending the same
number of nodes using DOM

3. There are much more efficient algorithms for generating large
numbers of nodes than simply iterating n times for n nodes, making the
time to generate a large number of identical nodes much shorter (but
likely rendering will take the same time).

4. It is very rare that you want to just generate 1,000 or so
identical nodes. Usually much more processing is required.

5. IE still can't modify the innerHTML of some elements (tr,
tablebody) so additional processing is required for general innerHTML
functions to cater for that.

6. Reading the innerHTML of an element can produce very different
results in different browsers, great care must be taken if it is to be
used for processing whereas requirements for DOM element attributes
and properties are clearly specified (there are still some quirks in
some browsers, but they probably are fewer and easier to deal with
than those related to innerHTML).

7. DOM manipulation using innerHTML can be very much more complex than
using DOM.

8. Servers can probably generate HTML just as quickly as they can
generate say JSON that can be converted to DOM elements or HTML on the
client, so sending prepared HTML to the client and using innerHTML
might result in significantly faster overall times than JSON converted
to DOM elements or HTML on the client.

8. The two methods can be combined - say using innerHTML to generate
content of a temporary element, then use DOM to append it to the
document.

9. Document parts can be progressively rendered (say 30 rows of a
table at a time) making the speed difference irrelevant for the user.

An example of 8 and 9 might be if you need to generate say 1000 rows
for a table, you create the HTML for the first 30 rows, wrap it in
table tags, then use DOM to create a div, insert the table as its
innerHTML, then use DOM to append the table body to the table in the
document. Repeat for all remaining rows. The user sees the first 30
rows pretty quickly, then at similar short intervals the other 970
rows appear, 30 rows (or maybe 50 or 100) at a time.

So you need to carefully evaluate your requirements and use the most
suitable method, it's not a simple case of one always being faster
than the other and therefore should be used in all cases.

--
Rob

Reply all
Reply to author
Forward
0 new messages