On Fri, 2010-12-17 at 16:29 +0100, Christophe Porteneuve wrote:
> First, if you need to support IE6, innerHTML with proper HTML building
> (as in, use a friggin' array, don't keep appending to string, man!) will
> beat the crap out of DOM building every time.
It completely depends on what you're doing, even in IE6.
If you are moving a lot of nodes (eg adding a thousand child elements to
a parent div one-by-one in a loop), *that's* when DOM is slow. It
involves lots of node list manipulations which in some browsers get
slower as the list increases in size, so you can end up with O(n²)-style
horrible performance.
On the other hand if you're moving a single node, even if it contains a
large amount of descendant content, that's fast. Trying to do that with
innerHTML would involve much more parsing of the content, which would be
slower.
There are ways that you can shift multiple nodes at once with DOM, which
is best of all, but it means using DocumentFragments and Ranges, which
have some compatibility problems (in particular no usable Range in IE<9)
and are not widely known yet.
I would recommend using DOM (or DOM-style methods in a framework) by
default, until such time as you have a high-load case where it you
really need `innerHTML`. Typically this is when you need to generate a
very long table.
The advantage of DOM methods for the inexperienced author, and why I
promote them as the default best approach, is that you don't have to
worry about HTML-escaping. When you do have to use `innerHTML`, you need
to be very careful to escape any dynamic content being inserted into the
string, otherwise you will be giving yourself a cross-site scripting
vulnerability.
Because neither JS nor the BOM gives you a standard HTML encoder, you
have to write one of your own. It's not hard, just a couple of string
replaces, but 99% of the code out there doesn't do so: it just uses
something like (in jQuery) `html('<p>'+somedata+'</p>')`. Consequently
most client-side innerHTML-hacking code is vulnerable, which is a shame
when we're just starting to make any progress of reducing XSS in
server-side code.
(This goes double for inserting JavaScript. Inserting
`onclick="doSomething()"` into an HTML string is super-ugly and requires
two levels of escaping for dynamic value insertion, JS literal escaping
*and* HTML escaping. No-one gets this right. With the DOM way of working
it's easy to add a listener/handler function to an element without any
string serialisation.)
--
And Clover
mailto:[email protected] http://www.doxdesk.com
skype:uknrbobince gtalk:[email protected]
--
To view archived discussions from the original JSMentors Mailman list:
http://www.mail-archive.com/[email protected]/
To search via a non-Google archive, visit here:
http://www.mail-archive.com/[email protected]/
To unsubscribe from this group, send email to
[email protected]
