Categories
javascript

Why is document.write considered a “bad practice”?

386

I know document.write is considered bad practice; and I’m hoping to compile a list of reasons to submit to a 3rd party vendor as to why they shouldn’t use document.write in implementations of their analytics code.

Please include your reason for claiming document.write as a bad practice below.

0

    255

    A few of the more serious problems:

    • document.write (henceforth DW) does not work in XHTML

    • DW does not directly modify the DOM, preventing further manipulation (trying to find evidence of this, but it’s at best situational)

    • DW executed after the page has finished loading will overwrite the page, or write a new page, or not work

    • DW executes where encountered: it cannot inject at a given node point

    • DW is effectively writing serialised text which is not the way the DOM works conceptually, and is an easy way to create bugs (.innerHTML has the same problem)

    Far better to use the safe and DOM friendly DOM manipulation methods

    18

    • 44

      -1, it absolutely modifies the DOM. Everything else is fine. While I understand the urge to depend on structure and methods which can keep you from harm, this may be a case of throwing out the baby with the bathwater.

      – cgp

      Apr 29, 2009 at 15:50

    • 7

      FireBug is not a true representation of the DOM. It is mozilla’s attempt to parse HTML into a DOM. You can have totally broken HTML look proper in the Firebug DOM view.

      – FlySwat

      Apr 29, 2009 at 16:17

    • 9

      The DOM is the data structure used to render the page and as such is the alpha and the omega of what the user sees on the page. You are correct that HTML != DOM, but it’s immaterial to the question of whether or NOT the DOM is modified by DW. If DW didn’t modify the DOM, you don’t see the screen – that’s true of all browsers and always will be as long as the DOM is what’s used to render the page.

      – cgp

      Apr 29, 2009 at 16:41

    • 9

      “DW executes where encountered” – not always a disadvantage, indeed it could be considered an advantage for certain things, e.g., adding script elements (actually about the only thing I’d use DW for, and even then I’d think twice).

      – nnnnnn

      Dec 25, 2011 at 12:16


    • 7

      @RicardoRivaldo Yes, they do, if document.write is called after the document has finished loading

      – Izkata

      Sep 19, 2013 at 2:37

    133

    There’s actually nothing wrong with document.write, per se. The problem is that it’s really easy to misuse it. Grossly, even.

    In terms of vendors supplying analytics code (like Google Analytics) it’s actually the easiest way for them to distribute such snippets

    1. It keeps the scripts small
    2. They don’t have to worry about overriding already established onload events or including the necessary abstraction to add onload events safely
    3. It’s extremely compatible

    As long as you don’t try to use it after the document has loaded, document.write is not inherently evil, in my humble opinion.

    6

    • 5

      document.write does really horrible things to the html parsers, and is only “extremely compatible” in simple cases.

      – olliej

      Apr 29, 2009 at 19:24

    • 28

      Like the insertion of an analytics tag? That is, after all, part of the original question. And by extremely compatible, I mean for just raw browser support for the document.write method.

      Apr 29, 2009 at 19:28

    • Anything that works with the latest versions of Chrome / IE / Safari / Opera / FireFox is considered compatible.

      – Pacerier

      Oct 12, 2014 at 8:22


    • 2

      Overriding onload events? And what’s addEventListener for?

      – m93a

      Feb 13, 2015 at 19:48

    • Chrome will not run document.write invocations that insert a script when certain conditions are met.

      – Flimm

      Jul 12, 2017 at 15:21

    45

    It can block your page

    document.write only works while the page is loading; If you call it after the page is done loading, it will overwrite the whole page.

    This effectively means you have to call it from an inline script block – And that will prevent the browser from processing parts of the page that follow. Scripts and Images will not be downloaded until the writing block is finished.