Le 17/12/2010 12:19, Balázs Galambosi a écrit :
Stoyan in his jsconf talk warns everyone to reconsider "common myths"
of performance optimization. This is exactly the case here. In fact
Webkit based browsers are generally 3x faster with DOM methods than
with innerHTML.
See: http://www.quirksmode.org/dom/innerhtml.html&;
http://jsperf.com/w3c-dom-vs-innerhtml
Thanks for bringing that up; however, innerHTML being faster is not such
a myth; it depends on a lot of things.
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.
Second, the relative perf of DOM building vs. innerHTML writing greatly
depends on a lot of factors: markup size, potential markup
errors/lapses, nature of the tags involved (tables are notoriously more
difficult to handle, esp. for IE), etc.
Because building up markup is often simpler and more readable than going
through the DOM interface (it's also simpler when you're using
templating), I usually go with innerHTML.
You have to keep things in perspective: even on WebKit-based browsers,
where the DOM way can, in some cases, be up to 3x faster, innerHTML can
still push HUNDREDS of HTML chunks PER SECOND into the document. So if
that lets you code less, hence maintain and understand less, hence work
faster and perhaps with a higher signal/noise ratio, why on Earth would
you prematurely optimize this?
Of course, you MAY run into very specific situations where, despite your
best-practice use of innerHTML, your UX feels sluggish. Then, and only
then, would I investigate how it behaves the DOM way (across all
browsers I need to support).
'HTH
--
Christophe Porteneuve
[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]
