> ...hence work faster and perhaps with a higher signal/noise ratio, > why on Earth would you prematurely optimize this?
You're speaking against yourself. `innerHTML` is the absolute blind "optimization" here. Also, using strings for generating content is known to be more error prone (quotation, new lines, nested elements, etc.). > Of course, you MAY run into very specific situations where, > despite your best-practice use of innerHTML This thread is a specific case. It would be good if you realized this. Again you're chanting `innerHTML` because you were told to do so, not because you did any testing/planning for the actual case. > So if that lets you [...] understand less [...] I always aim to understand more. - Balázs 2010/12/17 Balázs Galambosi <[email protected]>: > Christophe Porteneuve wrote: >> 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 > > I swear I saw it coming... If only you read the OP's question: > >> I am building hybrid iPhone/iPad apps and have had trouble with using >> Element.innerHTML = "some html tag soup" to convert text into html dom >> fragments. > > This indicates the use of Webkit, and that `innerHTML` won't be faster > for him, (it can be even slower). > > Don't be lazy to read the OP's question. :) > > - Balázs > > 2010/12/17 And Clover <[email protected]>: >> 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] >> > -- 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]
