Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Page 2 of 2 FirstFirst 12
Results 16 to 29 of 29
  1. #16
    Senior Coder rnd me's Avatar
    Join Date
    Jun 2007
    Location
    Urbana
    Posts
    4,444
    Thanks
    11
    Thanked 598 Times in 578 Posts
    Quote Originally Posted by glenngv View Post
    innerHTML vs createElement performance test:

    http://jsperf.com/innerhtml-vs-createelement-test/30
    i've see stuff like that too, but the problem is that the DOM is not actually fully built before the timer stops. it's the same problem as seen using querySelectorAll() right after a bunch of appendChild() calls; it's not all there yet, and so you have to setTimeout your dom call to make sure the DOM part is done before the JS part is wanting to execute.
    my site (updated 2014/10/20)
    BROWSER STATS [% share] (2014/9/03) IE7:0.1, IE8:4.3, IE11:9.2, IE9:2.7, IE10:2.6, FF:16.8, CH:47.5, SF:7.8, NON-MOUSE:37%

  2. #17
    Regular Coder
    Join Date
    Jun 2010
    Posts
    133
    Thanks
    0
    Thanked 3 Times in 3 Posts
    Check out benchmarks.

    jsperf.com/fragment-vs-appendchild-vs-innerhtml/11

    It seems to me, typically appending a child is faster in all browsers but not in IE.
    Check out my blog and portfolio at http://calebprenger.com

  3. #18
    Senior Coder rnd me's Avatar
    Join Date
    Jun 2007
    Location
    Urbana
    Posts
    4,444
    Thanks
    11
    Thanked 598 Times in 578 Posts
    Quote Originally Posted by pdiddles03 View Post
    Check out benchmarks.

    jsperf.com/fragment-vs-appendchild-vs-innerhtml/11

    It seems to me, typically appending a child is faster in all browsers but not in IE.
    fragments are good, and for times when you need to use createElement(), they typically speed things up greatly. If you use fragments, you should see about the same perf as innerHTML.

    I will say that i'm surprised at how well createElement() is faring in later versions of chrome and firefox, looks like they are closing the gap. I can remember there being a much larger advantage for innerHTML when firefox was in the single digits. at this point, i don't think we can pick a winner in the raw execution time performance benchmark. i'll concede my point that innerHTML is much faster, and say from now on that it's about the same.

    you can still see that RAM use is higher under createElement(), but folks don't jump up and down about RAM like they do CPU for some reason...

    to me, the bottom line of all this research demonstrates that innerHTML does indeed work, but is not really faster than createElement() anymore.
    can we agree on that?
    Last edited by rnd me; 09-16-2013 at 08:57 PM.
    my site (updated 2014/10/20)
    BROWSER STATS [% share] (2014/9/03) IE7:0.1, IE8:4.3, IE11:9.2, IE9:2.7, IE10:2.6, FF:16.8, CH:47.5, SF:7.8, NON-MOUSE:37%

  4. #19
    Regular Coder
    Join Date
    Jun 2010
    Posts
    133
    Thanks
    0
    Thanked 3 Times in 3 Posts
    Quote Originally Posted by rnd me View Post
    fragments are good, and for times when you need to use createElement(), they typically speed things up greatly. If you use fragments, you should see about the same perf as innerHTML.

    I will say that i'm surprised at how well createElement() is faring in later versions of chrome and firefox, looks like they are closing the gap. I can remember there being a much larger advantage for innerHTML when firefox was in the single digits. at this point, i don't think we can pick a winner in the raw execution time performance benchmark. i'll concede my point that innerHTML is much faster, and say from now on that it's about the same.

    you can still see that RAM use is higher under createElement(), but folks don't jump up and down about RAM like they do CPU for some reason...

    to me, the bottom line of all this research demonstrates that innerHTML does indeed work, but is not really faster than createElement() anymore.
    can we agree on that?
    Agreed!
    Check out my blog and portfolio at http://calebprenger.com

  5. #20
    The fat guy next door VIPStephan's Avatar
    Join Date
    Jan 2006
    Location
    Halle (Saale), Germany
    Posts
    8,866
    Thanks
    6
    Thanked 1,029 Times in 1,002 Posts
    And I think we can all agree that document.write() should not be used anymore in any case.

  6. #21
    Regular Coder tpeck's Avatar
    Join Date
    Oct 2002
    Location
    Sydney, Australia
    Posts
    884
    Thanks
    53
    Thanked 6 Times in 5 Posts
    Thank you for the in-depth discussion. But the concatenated document.write works on the page, and until it doesn't I see no reason to replace it to save a millisecond of loading time.

    OK. I take the advice. document.write is on its last legs, but in my case the fact that it wipes out the page isn't actually an issue.

    I was really only asking why ie 9 & 10 have a problem with it when other browsers don't.

    Only ie 9 & 10, as far as I have checked, read the first instance of document.write and refuse to read the second line.

    I just wondered why this would be. How do the latest incarnations of ie do these things differently?
    The difference between genius and stupidity is that genius has its limits. (Albert Einstein)

  7. #22
    Supreme Master coder! Philip M's Avatar
    Join Date
    Jun 2002
    Location
    London, England
    Posts
    18,243
    Thanks
    203
    Thanked 2,555 Times in 2,533 Posts
    Quote Originally Posted by tpeck View Post
    Only ie 9 & 10, as far as I have checked, read the first instance of document.write and refuse to read the second line.
    You must have some other more subtle problem which manifests itself only in IE9+.

    Code:
    <script type = "text/javascript">
    
    document.write("One<br>");
    document.write("Two<br>");
    document.write("Three<br>");
    document.write("Four<br>");
    
    </script>
    Works as you would expect in IE10.

    All the code given in this post has been tested and is intended to address the question asked.
    Unless stated otherwise it is not just a demonstration.

  8. #23
    Regular Coder tpeck's Avatar
    Join Date
    Oct 2002
    Location
    Sydney, Australia
    Posts
    884
    Thanks
    53
    Thanked 6 Times in 5 Posts
    Thank you Philip. I suspect you are correct.

    Might I suggest that this wonderful forum is becoming a way to argue rather than solve?
    The difference between genius and stupidity is that genius has its limits. (Albert Einstein)

  9. #24
    The fat guy next door VIPStephan's Avatar
    Join Date
    Jan 2006
    Location
    Halle (Saale), Germany
    Posts
    8,866
    Thanks
    6
    Thanked 1,029 Times in 1,002 Posts
    Quote Originally Posted by tpeck View Post
    Might I suggest that this wonderful forum is becoming a way to argue rather than solve?
    Only sometimes, if you’re bringing up the “wrong” subject.

  10. #25
    Regular Coder tpeck's Avatar
    Join Date
    Oct 2002
    Location
    Sydney, Australia
    Posts
    884
    Thanks
    53
    Thanked 6 Times in 5 Posts
    Hey, stop. Please! I like your input. Always have.

    But I asked a specific question. I still have had no answer...

    (perhaps there is none... I'm not expecting one)
    The difference between genius and stupidity is that genius has its limits. (Albert Einstein)

  11. #26
    Regular Coder
    Join Date
    Jun 2010
    Posts
    133
    Thanks
    0
    Thanked 3 Times in 3 Posts
    Quote Originally Posted by tpeck View Post
    Hey, stop. Please! I like your input. Always have.

    But I asked a specific question. I still have had no answer...

    (perhaps there is none... I'm not expecting one)

    And my answer to you is stick with standards and that is what i have been trying to say.

    FYI: there is a reason why people hate IE, it causes a lot of problems and they are not standards compliant. Especially the older versions.
    Check out my blog and portfolio at http://calebprenger.com

  12. #27
    Senior Coder rnd me's Avatar
    Join Date
    Jun 2007
    Location
    Urbana
    Posts
    4,444
    Thanks
    11
    Thanked 598 Times in 578 Posts
    we do like to have debates on controversial topics, and it's the main benfit for knowlwedgable folks to use the site. If all we did all day was explain how to use $.ready(), we'de go nuts! I don't mind helping along the way, sorry if you got lost in the fog of war. here's your answer:

    the problem is that document.write expects to write HTML. when you write() opening tags without closers, as in your first line, the DOM "quirks up" it's own closing tag out of nowhere. then you write a param tag as a sibling of the empty <object> tag, along with a sibling embed tag. then you write a closing tag to a tag that was self-closed many steps ago.

    the same issue would happen with innerHTML, though it would be impossible to mess up like that with createElement(), which always produces well-formed HTML.


    in short, you have to add whole legit pieces of html when you use write()/innerHTML to prevent the browser from making it well-formed for you.
    my site (updated 2014/10/20)
    BROWSER STATS [% share] (2014/9/03) IE7:0.1, IE8:4.3, IE11:9.2, IE9:2.7, IE10:2.6, FF:16.8, CH:47.5, SF:7.8, NON-MOUSE:37%

  13. #28
    Master Coder felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, Australia
    Posts
    6,642
    Thanks
    0
    Thanked 649 Times in 639 Posts
    The need for document.write in JavaScript disappeared when people stopped using Netscape 4.

    Where document.write is used and you want to put all your JavaScript at the bottom of the page where it belongs then you need to include some fairly complex code in order to be able to get the document.write code to insert into the right place. Postscribe is one such script. Without code like that your document.write will break as soon as you separate the JavaScript out from the HTML.

    The simpler solution when writing modern rather than prehistoric JavaScript is to replace the document.write with an innerHTML call instead.

    There are a few places where innerHTML doesn't work but it works in lots more situations than document.write does.
    Stephen
    Learn Modern JavaScript - http://javascriptexample.net/
    Helping others to solve their computer problem at http://www.felgall.com/

    Don't forget to start your JavaScript code with "use strict"; which makes it easier to find errors in your code.

  14. #29
    Senior Coder Arbitrator's Avatar
    Join Date
    Mar 2006
    Location
    Splendora, Texas, United States of America
    Posts
    3,371
    Thanks
    32
    Thanked 286 Times in 280 Posts
    Quote Originally Posted by tpeck View Post
    But I asked a specific question. I still have had no answer...
    Here's a possibility mentioned in the WHATWG HTML spec (emphasis added):

    Warning! This method has very idiosyncratic behavior. In some cases, this method can affect the state of the HTML parser while the parser is running, resulting in a DOM that does not correspond to the source of the document (e.g. if the string written is the string "<plaintext>" or "<!--"). In other cases, the call can clear the current page first, as if document.open() had been called. In yet more cases, the method is simply ignored, or throws an exception. To make matters worse, the exact behavior of this method can in some cases be dependent on network latency, which can lead to failures that are very hard to debug. For all these reasons, use of this method is strongly discouraged.
    Since you're loading a plug-in, that could be affecting the way the code is being processed while the plug-in is being fetched/loaded.
    For every complex problem, there is an answer that is clear, simple, and wrong.


 
Page 2 of 2 FirstFirst 12

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •