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

344

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.

javascript

share|improve this question

edited Mar 22 '17 at 16:21

Taryn♦

189k46288352

asked Apr 29 '09 at 15:18

FlySwatFlySwat

113k63231300

add a comment | 

344

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.

javascript

share|improve this question

edited Mar 22 '17 at 16:21

Taryn♦

189k46288352

asked Apr 29 '09 at 15:18

FlySwatFlySwat

113k63231300

add a comment | 

344

344

344

106

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.

javascript

share|improve this question

edited Mar 22 '17 at 16:21

Taryn♦

189k46288352

asked Apr 29 '09 at 15:18

FlySwatFlySwat

113k63231300

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.

javascript

javascript

share|improve this question

edited Mar 22 '17 at 16:21

Taryn♦

189k46288352

asked Apr 29 '09 at 15:18

FlySwatFlySwat

113k63231300

share|improve this question

edited Mar 22 '17 at 16:21

Taryn♦

189k46288352

asked Apr 29 '09 at 15:18

FlySwatFlySwat

113k63231300

share|improve this question

share|improve this question

edited Mar 22 '17 at 16:21

Taryn♦

189k46288352

edited Mar 22 '17 at 16:21

Taryn♦

189k46288352

edited Mar 22 '17 at 16:21

Taryn♦

189k46288352

189k46288352

asked Apr 29 '09 at 15:18

FlySwatFlySwat

113k63231300

asked Apr 29 '09 at 15:18

FlySwatFlySwat

113k63231300

asked Apr 29 '09 at 15:18

FlySwatFlySwat

113k63231300

113k63231300

add a comment | 

add a comment | 

16 Answers
16

active

oldest

votes

229

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

share|improve this answer

edited Sep 16 '13 at 17:00

user456814

answered Apr 29 '09 at 15:36

annakataannakata

62.6k15104175

• 
  
  
  

  
  38
  

  
  
  
  
  
  

  
  
  -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 '09 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 '09 at 16:17
  

  
  
  
  


• 
  
  
  

  
  7
  

  
  
  
  
  
  

  
  
  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 '09 at 16:41
  

  
  
  
  


• 
  
  
  

  
  7
  

  
  
  
  
  
  

  
  
  "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 '11 at 12:16
  
  
  

  
  
  
  


• 
  
  
  

  
  7
  

  
  
  
  
  
  

  
  
  @RicardoRivaldo Yes, they do, if document.write is called after the document has finished loading
  
  – Izkata
  Sep 19 '13 at 2:37
  

  
  
  
  

 | 
show 13 more comments

121

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.

share|improve this answer

edited Dec 4 '11 at 0:25

Ry-♦

167k38339359

answered Apr 29 '09 at 15:26

Peter BaileyPeter Bailey

93.5k25165191

• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  
  document.write does really horrible things to the html parsers, and is only "extremely compatible" in simple cases.
  
  – olliej
  Apr 29 '09 at 19:24
  

  
  
  
  


• 
  
  
  

  
  27
  

  
  
  
  
  
  

  
  
  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.
  
  – Peter Bailey
  Apr 29 '09 at 19:28
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Anything that works with the latest versions of Chrome / IE / Safari / Opera / FireFox is considered compatible.
  
  – Pacerier
  Oct 12 '14 at 8:22
  
  
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  Overriding onload events? And what's addEventListener for?
  
  – m93a
  Feb 13 '15 at 19:48
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Chrome will not run document.write invocations that insert a script when certain conditions are met.
  
  – Flimm
  Jul 12 '17 at 15:21
  

  
  
  
  

add a comment | 

42

Another legitimate use of document.write comes from the HTML5 Boilerplate index.html example.

<!-- Grab Google CDN's jQuery, with a protocol relative URL; fall back to local if offline -->

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.6.3/jquery.min.js"></script>

<script>window.jQuery || document.write('<script src="js/libs/jquery-1.6.3.min.js"></script>')</script>

I've also seen the same technique for using the json2.js JSON parse/stringify polyfill (needed by IE7 and below).

<script>window.JSON || document.write('<script src="json2.js"></script>')</script>

share|improve this answer

edited Oct 24 '14 at 20:41

Guilherme Garnier

1,9431919

answered Sep 8 '11 at 20:49

Kevin HakansonKevin Hakanson

30.4k22115141

• 
  
  
  

  
  9
  

  
  
  
  
  
  

  
  
  Not bad use here, but still "better" to use DOM manipulation functions -- even Google does it for Google Analytics. Snippet is here.
  
  – BMiner
  Jan 22 '13 at 14:40
  
  
  

  
  
  
  


• 
  
  
  

  
  7
  

  
  
  
  
  
  

  
  
  @BMiner if you insert a script element via DOM manipulation, is it loaded synchronously? Unless it is, it's not a replacement.
  
  – John Dvorak
  Jun 5 '13 at 10:41
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  
  @JanDvorak - Good point; when using DOM manipulations, browsers will generally load the script asynchronously. You can use the onload DOM event to determine when the asynchronously loaded script is available for use.
  
  – BMiner
  Jun 6 '13 at 18:16
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  @JanDvorak It is loaded synchronously if it isn't external (doesn't have src). Otherwise it will be executed "as soon as possible", asynchronously.
  
  – Oriol
  Aug 14 '16 at 23:51
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  This still can break, as Chrome will deliberately refuse to run document.write calls that insert <script> tags if the user is on a 2G connection. See developers.google.com/web/updates/2016/08/…
  
  – Flimm
  Jul 12 '17 at 15:13
  

  
  
  
  

add a comment | 

36

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.

share|improve this answer

edited Aug 20 '14 at 7:38

T J

32.6k956109

answered Jul 14 '11 at 17:19

Sean McMillanSean McMillan

7,56544762

add a comment | 

28

Pro:

• It's the easiest way to embed inline content from an external (to your host/domain) script.


• You can overwrite the entire content in a frame/iframe. I used to use this technique a lot for menu/navigation pieces before more modern Ajax techniques were widely available (1998-2002).

Con:

• It serializes the rendering engine to pause until said external script is loaded, which could take much longer than an internal script.


• It is usually used in such a way that the script is placed within the content, which is considered bad-form.

share|improve this answer

edited Nov 19 '13 at 20:54

answered Apr 29 '09 at 16:19

Tracker1Tracker1

13.9k86494

• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  
  There are more cons than that. For instance, Google Chrome will refuse to run document.write that creates <script> tag under certain circumstances. developers.google.com/web/updates/2016/08/…
  
  – Flimm
  Jul 12 '17 at 15:14
  

  
  
  
  

add a comment | 

9

Here's my twopence worth, in general you shouldn't use document.write for heavy lifting, but there is one instance where it is definitely useful:

http://www.quirksmode.org/blog/archives/2005/06/three_javascrip_1.html

I discovered this recently trying to create an AJAX slider gallery. I created two nested divs, and applied width/height and overflow: hidden to the outer <div> with JS. This was so that in the event that the browser had JS disabled, the div would float to accommodate the images in the gallery - some nice graceful degradation.

Thing is, as with the article above, this JS hijacking of the CSS didn't kick in until the page had loaded, causing a momentary flash as the div was loaded. So I needed to write a CSS rule, or include a sheet, as the page loaded.

Obviously, this won't work in XHTML, but since XHTML appears to be something of a dead duck (and renders as tag soup in IE) it might be worth re-evaluating your choice of DOCTYPE...

share|improve this answer

edited Dec 4 '11 at 0:31

Ry-♦

167k38339359

answered Oct 13 '09 at 13:23

sunwukungsunwukung

1,70133248

add a comment | 

7

It breaks pages using XML rendering (like XHTML pages).

Best: some browser switch back to HTML rendering and everything works fine.

Probable: some browser disable the document.write() function in XML rendering mode.

Worst: some browser will fire an XML error whenever using the document.write() function.

share|improve this answer

answered Apr 29 '09 at 15:44

Vincent RobertVincent Robert

27.6k1066110

add a comment | 

6

It overwrites content on the page which is the most obvious reason but I wouldn't call it "bad".

It just doesn't have much use unless you're creating an entire document using JavaScript in which case you may start with document.write.

Even so, you aren't really leveraging the DOM when you use document.write--you are just dumping a blob of text into the document so I'd say it's bad form.

share|improve this answer

answered Apr 29 '09 at 15:29

aleembaleemb

22.2k1588106

• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  One clarification: document.write inserts contents on the page, it doesn't overwrite them.
  
  – Peter Dolberg
  Apr 29 '09 at 15:45
  

  
  
  
  


• 
  
  
  

  
  5
  

  
  
  
  
  
  

  
  
  @Peter, it does overwrite the content if you call it after the document is loaded. I'm guessing that's what aleemb means.
  
  – Matthew Crumley
  Apr 29 '09 at 17:09
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  
  Are you suggesting that one should instead manually build the individual DOM nodes in code rather than just doing something like div.innerHTML = "<label for='MySelect'>Choose One</label><select id='MySelect'><option value='foo' selected=''>foo</option><option value='bar'>bar</option></select>";? That seems like it would produce a lot of unnecessary and less readable code. It's also the exact opposite of the approach John Resig and other JS developers advocate.
  
  – Lèse majesté
  Dec 26 '12 at 8:25
  
  
  

  
  
  
  

add a comment | 

5

Off the top of my head:

1. document.write needs to be used in the page load or body load. So if you want to use the script in any other time to update your page content document.write is pretty much useless.




2. Technically document.write will only update HTML pages not XHTML/XML. IE seems to be pretty forgiving of this fact but other browsers will not be.

http://www.w3.org/MarkUp/2004/xhtml-faq#docwrite

share|improve this answer

edited Dec 4 '11 at 0:32

Ry-♦

167k38339359

answered Apr 29 '09 at 15:31

brendanbrendan

22k1661103

• 
  
  
  

  
  8
  

  
  
  
  
  
  

  
  
  IE is forgiving because it doesn't support XHTML. If/when they do, document.write will probably stop working (only in XHTML of course).
  
  – Matthew Crumley
  Apr 29 '09 at 17:12
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  
  XHTML is irrelevant on the web. Even pages with a strict XHTML doctype are not actually treated as XML in that regard, browser developers don't trust page authors that much.
  
  – RobG
  Oct 27 '15 at 0:37
  
  
  

  
  
  
  

add a comment | 

2

Chrome may block document.write that inserts a script in certain cases. When this happens, it will display this warning in the console:

A Parser-blocking, cross-origin script, ..., is invoked via
document.write. This may be blocked by the browser if the device has
poor network connectivity.

References:

• 
  This article on developers.google.com goes into more detail.


• https://www.chromestatus.com/feature/5718547946799104

share|improve this answer

edited Jul 12 '17 at 15:19

Flimm

51.2k23134156

answered Feb 1 '17 at 23:03

TrueWillTrueWill

19.6k674121

add a comment | 

1

One can think of document.write() (and .innerHTML) as evaluating a source code string. This can be very handy for many applications. For example if you get HTML code as a string from some source, it is handy to just "evaluate" it.

In the context of Lisp, DOM manipulation would be like manipulating a list structure, e.g. create the list (orange) by doing:

(cons 'orange '())

And document.write() would be like evaluating a string, e.g. create a list by evaluating a source code string like this:

(eval-string "(cons 'orange '())")

Lisp also has the very useful ability to create code using list manipulation (like using the "DOM style" to create a JS parse tree). This means you can build up a list structure using the "DOM style", rather than the "string style", and then run that code, e.g. like this:

(eval '(cons 'orange '()))

If you implement coding tools, like simple live editors, it is very handy to have the ability to quickly evaluate a string, for example using document.write() or .innerHTML. Lisp is ideal in this sense, but you can do very cool stuff also in JS, and many people are doing that, like http://jsbin.com/

share|improve this answer

answered Feb 12 '13 at 17:48

Mikael KindborgMikael Kindborg

21225

add a comment | 

1

• A simple reason why document.write is a bad practice is that you cannot come up with a scenario where you cannot find a better alternative.


• Another reason is that you are dealing with strings instead of objects (it is very primitive).


• It does only append to documents.


• It has nothing of the beauty of for instance the MVC (Model-View-Controller) pattern.


• It is a lot more powerful to present dynamic content with ajax+jQuery or angularJS.

share|improve this answer

answered Sep 9 '16 at 19:37

Anders LindénAnders Lindén

3,53033069

• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  As for as your first bullet goes, how are you going to solve what @sunwukung describes in his answer above? I agree you could solve it with DOM manipulations, but as DOM manipulations go, it is hard to avoid FUOC at times without document.write.
  
  – bert bruynooghe
  May 19 '17 at 16:29
  
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Is FUOC a problem anymore?
  
  – Anders Lindén
  Aug 18 '18 at 7:56
  

  
  
  
  

add a comment | 

1

The disadvantages of document.write mainly depends on these 3 factors:

a) Implementation

The document.write() is mostly used to write content to the screen as soon as that content is needed. This means it happens anywhere, either in a JavaScript file or inside a script tag within an HTML file. With the script tag being placed anywhere within such an HTML file, it is a bad idea to have document.write() statements inside script blocks that are intertwined with HTML inside a web page.

b) Rendering

Well designed code in general will take any dynamically generated content, store it in memory, keep manipulating it as it passes through the code before it finally gets spit out to the screen. So to reiterate the last point in the preceding section, rendering content in-place may render faster than other content that may be relied upon, but it may not be available to the other code that in turn requires the content to be rendered for processing. To solve this dilemma we need to get rid of the document.write() and implement it the right way.

c) Impossible Manipulation

Once it's written it's done and over with. We cannot go back to manipulate it without tapping into the DOM.

share|improve this answer

answered Dec 9 '16 at 5:13

user3167857user3167857

259

add a comment | 

1

Based on analysis done by Google-Chrome Dev Tools' Lighthouse Audit

share|improve this answer

answered Feb 22 '18 at 8:58

Sudip BhandariSudip Bhandari

7661117

add a comment | 

0

Browser Violation

.write is considered a browser violation as it halts the parser from rendering the page. The parser receives the message that the document is being modified; hence, it gets blocked until JS has completed its process. Only at this time will the parser resume.

Performance

The biggest consequence of employing such a method is lowered performance. The browser will take longer to load page content. The adverse reaction on load time depends on what is being written to the document. You won't see much of a difference if you are adding a <p> tag to the DOM as opposed to passing an array of 50-some references to JavaScript libraries (something which I have seen in working code and resulted in an 11 second delay - of course, this also depends on your hardware).

All in all, it's best to steer clear of this method if you can help it.

For more info see Intervening against document.write()

share|improve this answer

edited Nov 20 '18 at 1:50

answered Nov 20 '18 at 1:19

Arielle AdamsArielle Adams

587

add a comment | 

-3

I think the biggest problem is that any elements written via document.write are added to the end of the page's elements. That's rarely the desired effect with modern page layouts and AJAX. (you have to keep in mind that the elements in the DOM are temporal, and when the script runs may affect its behavior).

It's much better to set a placeholder element on the page, and then manipulate it's innerHTML.

share|improve this answer

answered Apr 29 '09 at 15:31

BnWastelandBnWasteland

1,40811514

• 
  
  
  

  
  14
  

  
  
  
  
  
  

  
  
  This is not true. document.write does not add the content to the end of the page like it's an append. They are written in place.
  
  – Peter Bailey
  Apr 29 '09 at 15:35
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  @Peter Bailey, I know this is an old thread, but really this shouldn't be downvoted. whether it appends or not depends on whether document.write() runs inline while the page is loading. If it is called from a function after the page loads then the first document.write() will replace the entire body and subsequent calls will append to it.
  
  – Octopus
  Dec 17 '14 at 5:53
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  
  @Octopus Yes, but that's circumstantial. It appends in that scenario only because there's a fresh document. It's still not accurate to say "document.write() appends." Yes, it's an old answer and an old downvote, but I still stand by it.
  
  – Peter Bailey
  Dec 18 '14 at 14:03
  
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Its fine. I spoke imprecisely. I would've edited it long ago, but there is a much better answer above. I would point out though that "written in place" is equally imprecise.
  
  – BnWasteland
  Dec 18 '14 at 20:40
  

  
  
  
  

add a comment | 

protected by Travis J Jan 2 '14 at 3:13

Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).



Would you like to answer one of these unanswered questions instead?

16 Answers
16

active

oldest

votes

16 Answers
16

active

oldest

votes

active

oldest

votes

active

oldest

votes

229

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

share|improve this answer

edited Sep 16 '13 at 17:00

user456814

answered Apr 29 '09 at 15:36

annakataannakata

62.6k15104175

• 
  
  
  

  
  38
  

  
  
  
  
  
  

  
  
  -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 '09 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 '09 at 16:17
  

  
  
  
  


• 
  
  
  

  
  7
  

  
  
  
  
  
  

  
  
  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 '09 at 16:41
  

  
  
  
  


• 
  
  
  

  
  7
  

  
  
  
  
  
  

  
  
  "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 '11 at 12:16
  
  
  

  
  
  
  


• 
  
  
  

  
  7
  

  
  
  
  
  
  

  
  
  @RicardoRivaldo Yes, they do, if document.write is called after the document has finished loading
  
  – Izkata
  Sep 19 '13 at 2:37
  

  
  
  
  

 | 
show 13 more comments

229

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

share|improve this answer

edited Sep 16 '13 at 17:00

user456814

answered Apr 29 '09 at 15:36

annakataannakata

62.6k15104175

• 
  
  
  

  
  38
  

  
  
  
  
  
  

  
  
  -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 '09 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 '09 at 16:17
  

  
  
  
  


• 
  
  
  

  
  7
  

  
  
  
  
  
  

  
  
  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 '09 at 16:41
  

  
  
  
  


• 
  
  
  

  
  7
  

  
  
  
  
  
  

  
  
  "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 '11 at 12:16
  
  
  

  
  
  
  


• 
  
  
  

  
  7
  

  
  
  
  
  
  

  
  
  @RicardoRivaldo Yes, they do, if document.write is called after the document has finished loading
  
  – Izkata
  Sep 19 '13 at 2:37
  

  
  
  
  

 | 
show 13 more comments

229

229

229

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

share|improve this answer

edited Sep 16 '13 at 17:00

user456814

answered Apr 29 '09 at 15:36

annakataannakata

62.6k15104175

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

share|improve this answer

edited Sep 16 '13 at 17:00

user456814

answered Apr 29 '09 at 15:36

annakataannakata

62.6k15104175

share|improve this answer

share|improve this answer

edited Sep 16 '13 at 17:00

user456814

edited Sep 16 '13 at 17:00

user456814

edited Sep 16 '13 at 17:00

user456814

answered Apr 29 '09 at 15:36

annakataannakata

62.6k15104175

answered Apr 29 '09 at 15:36

annakataannakata

62.6k15104175

answered Apr 29 '09 at 15:36

annakataannakata

62.6k15104175

62.6k15104175

• 
  
  
  

  
  38
  

  
  
  
  
  
  

  
  
  -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 '09 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 '09 at 16:17
  

  
  
  
  


• 
  
  
  

  
  7
  

  
  
  
  
  
  

  
  
  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 '09 at 16:41
  

  
  
  
  


• 
  
  
  

  
  7
  

  
  
  
  
  
  

  
  
  "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 '11 at 12:16
  
  
  

  
  
  
  


• 
  
  
  

  
  7
  

  
  
  
  
  
  

  
  
  @RicardoRivaldo Yes, they do, if document.write is called after the document has finished loading
  
  – Izkata
  Sep 19 '13 at 2:37
  

  
  
  
  

 | 
show 13 more comments

• 
  
  
  

  
  38
  

  
  
  
  
  
  

  
  
  -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 '09 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 '09 at 16:17
  

  
  
  
  


• 
  
  
  

  
  7
  

  
  
  
  
  
  

  
  
  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 '09 at 16:41
  

  
  
  
  


• 
  
  
  

  
  7
  

  
  
  
  
  
  

  
  
  "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 '11 at 12:16
  
  
  

  
  
  
  


• 
  
  
  

  
  7
  

  
  
  
  
  
  

  
  
  @RicardoRivaldo Yes, they do, if document.write is called after the document has finished loading
  
  – Izkata
  Sep 19 '13 at 2:37
  

  
  
  
  

38

38

-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 '09 at 15:50

-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 '09 at 15:50

7

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 '09 at 16:17

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 '09 at 16:17

7

7

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 '09 at 16:41

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 '09 at 16:41

7

7

"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 '11 at 12:16

"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 '11 at 12:16

7

7

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

– Izkata
Sep 19 '13 at 2:37

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

– Izkata
Sep 19 '13 at 2:37

 | 
show 13 more comments

121

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.

share|improve this answer

edited Dec 4 '11 at 0:25

Ry-♦

167k38339359

answered Apr 29 '09 at 15:26

Peter BaileyPeter Bailey

93.5k25165191

• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  
  document.write does really horrible things to the html parsers, and is only "extremely compatible" in simple cases.
  
  – olliej
  Apr 29 '09 at 19:24
  

  
  
  
  


• 
  
  
  

  
  27
  

  
  
  
  
  
  

  
  
  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.
  
  – Peter Bailey
  Apr 29 '09 at 19:28
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Anything that works with the latest versions of Chrome / IE / Safari / Opera / FireFox is considered compatible.
  
  – Pacerier
  Oct 12 '14 at 8:22
  
  
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  Overriding onload events? And what's addEventListener for?
  
  – m93a
  Feb 13 '15 at 19:48
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Chrome will not run document.write invocations that insert a script when certain conditions are met.
  
  – Flimm
  Jul 12 '17 at 15:21
  

  
  
  
  

add a comment | 

121

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.

share|improve this answer

edited Dec 4 '11 at 0:25

Ry-♦

167k38339359

answered Apr 29 '09 at 15:26

Peter BaileyPeter Bailey

93.5k25165191

• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  
  document.write does really horrible things to the html parsers, and is only "extremely compatible" in simple cases.
  
  – olliej
  Apr 29 '09 at 19:24
  

  
  
  
  


• 
  
  
  

  
  27
  

  
  
  
  
  
  

  
  
  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.
  
  – Peter Bailey
  Apr 29 '09 at 19:28
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Anything that works with the latest versions of Chrome / IE / Safari / Opera / FireFox is considered compatible.
  
  – Pacerier
  Oct 12 '14 at 8:22
  
  
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  Overriding onload events? And what's addEventListener for?
  
  – m93a
  Feb 13 '15 at 19:48
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Chrome will not run document.write invocations that insert a script when certain conditions are met.
  
  – Flimm
  Jul 12 '17 at 15:21
  

  
  
  
  

add a comment | 

121

121

121

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.

share|improve this answer

edited Dec 4 '11 at 0:25

Ry-♦

167k38339359

answered Apr 29 '09 at 15:26

Peter BaileyPeter Bailey

93.5k25165191

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.

share|improve this answer

edited Dec 4 '11 at 0:25

Ry-♦

167k38339359

answered Apr 29 '09 at 15:26

Peter BaileyPeter Bailey

93.5k25165191

share|improve this answer

share|improve this answer

edited Dec 4 '11 at 0:25

Ry-♦

167k38339359

edited Dec 4 '11 at 0:25

Ry-♦

167k38339359

edited Dec 4 '11 at 0:25

Ry-♦

167k38339359

167k38339359

answered Apr 29 '09 at 15:26

Peter BaileyPeter Bailey

93.5k25165191

answered Apr 29 '09 at 15:26

Peter BaileyPeter Bailey

93.5k25165191

answered Apr 29 '09 at 15:26

Peter BaileyPeter Bailey

93.5k25165191

93.5k25165191

• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  
  document.write does really horrible things to the html parsers, and is only "extremely compatible" in simple cases.
  
  – olliej
  Apr 29 '09 at 19:24
  

  
  
  
  


• 
  
  
  

  
  27
  

  
  
  
  
  
  

  
  
  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.
  
  – Peter Bailey
  Apr 29 '09 at 19:28
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Anything that works with the latest versions of Chrome / IE / Safari / Opera / FireFox is considered compatible.
  
  – Pacerier
  Oct 12 '14 at 8:22
  
  
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  Overriding onload events? And what's addEventListener for?
  
  – m93a
  Feb 13 '15 at 19:48
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Chrome will not run document.write invocations that insert a script when certain conditions are met.
  
  – Flimm
  Jul 12 '17 at 15:21
  

  
  
  
  

add a comment | 

• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  
  document.write does really horrible things to the html parsers, and is only "extremely compatible" in simple cases.
  
  – olliej
  Apr 29 '09 at 19:24
  

  
  
  
  


• 
  
  
  

  
  27
  

  
  
  
  
  
  

  
  
  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.
  
  – Peter Bailey
  Apr 29 '09 at 19:28
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Anything that works with the latest versions of Chrome / IE / Safari / Opera / FireFox is considered compatible.
  
  – Pacerier
  Oct 12 '14 at 8:22
  
  
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  Overriding onload events? And what's addEventListener for?
  
  – m93a
  Feb 13 '15 at 19:48
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Chrome will not run document.write invocations that insert a script when certain conditions are met.
  
  – Flimm
  Jul 12 '17 at 15:21
  

  
  
  
  

3

3

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

– olliej
Apr 29 '09 at 19:24

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

– olliej
Apr 29 '09 at 19:24

27

27

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.

– Peter Bailey
Apr 29 '09 at 19: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.

– Peter Bailey
Apr 29 '09 at 19:28

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

– Pacerier
Oct 12 '14 at 8:22

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

– Pacerier
Oct 12 '14 at 8:22

1

1

Overriding onload events? And what's addEventListener for?

– m93a
Feb 13 '15 at 19:48

Overriding onload events? And what's addEventListener for?

– m93a
Feb 13 '15 at 19:48

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

– Flimm
Jul 12 '17 at 15:21

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

– Flimm
Jul 12 '17 at 15:21

add a comment | 

42

Another legitimate use of document.write comes from the HTML5 Boilerplate index.html example.

<!-- Grab Google CDN's jQuery, with a protocol relative URL; fall back to local if offline -->

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.6.3/jquery.min.js"></script>

<script>window.jQuery || document.write('<script src="js/libs/jquery-1.6.3.min.js"></script>')</script>

I've also seen the same technique for using the json2.js JSON parse/stringify polyfill (needed by IE7 and below).

<script>window.JSON || document.write('<script src="json2.js"></script>')</script>

share|improve this answer

edited Oct 24 '14 at 20:41

Guilherme Garnier

1,9431919

answered Sep 8 '11 at 20:49

Kevin HakansonKevin Hakanson

30.4k22115141

• 
  
  
  

  
  9
  

  
  
  
  
  
  

  
  
  Not bad use here, but still "better" to use DOM manipulation functions -- even Google does it for Google Analytics. Snippet is here.
  
  – BMiner
  Jan 22 '13 at 14:40
  
  
  

  
  
  
  


• 
  
  
  

  
  7
  

  
  
  
  
  
  

  
  
  @BMiner if you insert a script element via DOM manipulation, is it loaded synchronously? Unless it is, it's not a replacement.
  
  – John Dvorak
  Jun 5 '13 at 10:41
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  
  @JanDvorak - Good point; when using DOM manipulations, browsers will generally load the script asynchronously. You can use the onload DOM event to determine when the asynchronously loaded script is available for use.
  
  – BMiner
  Jun 6 '13 at 18:16
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  @JanDvorak It is loaded synchronously if it isn't external (doesn't have src). Otherwise it will be executed "as soon as possible", asynchronously.
  
  – Oriol
  Aug 14 '16 at 23:51
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  This still can break, as Chrome will deliberately refuse to run document.write calls that insert <script> tags if the user is on a 2G connection. See developers.google.com/web/updates/2016/08/…
  
  – Flimm
  Jul 12 '17 at 15:13
  

  
  
  
  

add a comment | 

42

Another legitimate use of document.write comes from the HTML5 Boilerplate index.html example.

<!-- Grab Google CDN's jQuery, with a protocol relative URL; fall back to local if offline -->

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.6.3/jquery.min.js"></script>

<script>window.jQuery || document.write('<script src="js/libs/jquery-1.6.3.min.js"></script>')</script>

I've also seen the same technique for using the json2.js JSON parse/stringify polyfill (needed by IE7 and below).

<script>window.JSON || document.write('<script src="json2.js"></script>')</script>

share|improve this answer

edited Oct 24 '14 at 20:41

Guilherme Garnier

1,9431919

answered Sep 8 '11 at 20:49

Kevin HakansonKevin Hakanson

30.4k22115141

• 
  
  
  

  
  9
  

  
  
  
  
  
  

  
  
  Not bad use here, but still "better" to use DOM manipulation functions -- even Google does it for Google Analytics. Snippet is here.
  
  – BMiner
  Jan 22 '13 at 14:40
  
  
  

  
  
  
  


• 
  
  
  

  
  7
  

  
  
  
  
  
  

  
  
  @BMiner if you insert a script element via DOM manipulation, is it loaded synchronously? Unless it is, it's not a replacement.
  
  – John Dvorak
  Jun 5 '13 at 10:41
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  
  @JanDvorak - Good point; when using DOM manipulations, browsers will generally load the script asynchronously. You can use the onload DOM event to determine when the asynchronously loaded script is available for use.
  
  – BMiner
  Jun 6 '13 at 18:16
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  @JanDvorak It is loaded synchronously if it isn't external (doesn't have src). Otherwise it will be executed "as soon as possible", asynchronously.
  
  – Oriol
  Aug 14 '16 at 23:51
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  This still can break, as Chrome will deliberately refuse to run document.write calls that insert <script> tags if the user is on a 2G connection. See developers.google.com/web/updates/2016/08/…
  
  – Flimm
  Jul 12 '17 at 15:13
  

  
  
  
  

add a comment | 

42

42

42

Another legitimate use of document.write comes from the HTML5 Boilerplate index.html example.

<!-- Grab Google CDN's jQuery, with a protocol relative URL; fall back to local if offline -->

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.6.3/jquery.min.js"></script>

<script>window.jQuery || document.write('<script src="js/libs/jquery-1.6.3.min.js"></script>')</script>

I've also seen the same technique for using the json2.js JSON parse/stringify polyfill (needed by IE7 and below).

<script>window.JSON || document.write('<script src="json2.js"></script>')</script>

share|improve this answer

edited Oct 24 '14 at 20:41

Guilherme Garnier

1,9431919

answered Sep 8 '11 at 20:49

Kevin HakansonKevin Hakanson

30.4k22115141

Another legitimate use of document.write comes from the HTML5 Boilerplate index.html example.

<!-- Grab Google CDN's jQuery, with a protocol relative URL; fall back to local if offline -->

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.6.3/jquery.min.js"></script>

<script>window.jQuery || document.write('<script src="js/libs/jquery-1.6.3.min.js"></script>')</script>

I've also seen the same technique for using the json2.js JSON parse/stringify polyfill (needed by IE7 and below).

<script>window.JSON || document.write('<script src="json2.js"></script>')</script>

share|improve this answer

edited Oct 24 '14 at 20:41

Guilherme Garnier

1,9431919

answered Sep 8 '11 at 20:49

Kevin HakansonKevin Hakanson

30.4k22115141

share|improve this answer

share|improve this answer

edited Oct 24 '14 at 20:41

Guilherme Garnier

1,9431919

edited Oct 24 '14 at 20:41

Guilherme Garnier

1,9431919

edited Oct 24 '14 at 20:41

Guilherme Garnier

1,9431919

1,9431919

answered Sep 8 '11 at 20:49

Kevin HakansonKevin Hakanson

30.4k22115141

answered Sep 8 '11 at 20:49

Kevin HakansonKevin Hakanson

30.4k22115141

answered Sep 8 '11 at 20:49

Kevin HakansonKevin Hakanson

30.4k22115141

30.4k22115141

• 
  
  
  

  
  9
  

  
  
  
  
  
  

  
  
  Not bad use here, but still "better" to use DOM manipulation functions -- even Google does it for Google Analytics. Snippet is here.
  
  – BMiner
  Jan 22 '13 at 14:40
  
  
  

  
  
  
  


• 
  
  
  

  
  7
  

  
  
  
  
  
  

  
  
  @BMiner if you insert a script element via DOM manipulation, is it loaded synchronously? Unless it is, it's not a replacement.
  
  – John Dvorak
  Jun 5 '13 at 10:41
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  
  @JanDvorak - Good point; when using DOM manipulations, browsers will generally load the script asynchronously. You can use the onload DOM event to determine when the asynchronously loaded script is available for use.
  
  – BMiner
  Jun 6 '13 at 18:16
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  @JanDvorak It is loaded synchronously if it isn't external (doesn't have src). Otherwise it will be executed "as soon as possible", asynchronously.
  
  – Oriol
  Aug 14 '16 at 23:51
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  This still can break, as Chrome will deliberately refuse to run document.write calls that insert <script> tags if the user is on a 2G connection. See developers.google.com/web/updates/2016/08/…
  
  – Flimm
  Jul 12 '17 at 15:13
  

  
  
  
  

add a comment | 

• 
  
  
  

  
  9
  

  
  
  
  
  
  

  
  
  Not bad use here, but still "better" to use DOM manipulation functions -- even Google does it for Google Analytics. Snippet is here.
  
  – BMiner
  Jan 22 '13 at 14:40
  
  
  

  
  
  
  


• 
  
  
  

  
  7
  

  
  
  
  
  
  

  
  
  @BMiner if you insert a script element via DOM manipulation, is it loaded synchronously? Unless it is, it's not a replacement.
  
  – John Dvorak
  Jun 5 '13 at 10:41
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  
  @JanDvorak - Good point; when using DOM manipulations, browsers will generally load the script asynchronously. You can use the onload DOM event to determine when the asynchronously loaded script is available for use.
  
  – BMiner
  Jun 6 '13 at 18:16
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  @JanDvorak It is loaded synchronously if it isn't external (doesn't have src). Otherwise it will be executed "as soon as possible", asynchronously.
  
  – Oriol
  Aug 14 '16 at 23:51
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  This still can break, as Chrome will deliberately refuse to run document.write calls that insert <script> tags if the user is on a 2G connection. See developers.google.com/web/updates/2016/08/…
  
  – Flimm
  Jul 12 '17 at 15:13
  

  
  
  
  

9

9

Not bad use here, but still "better" to use DOM manipulation functions -- even Google does it for Google Analytics. Snippet is here.

– BMiner
Jan 22 '13 at 14:40

Not bad use here, but still "better" to use DOM manipulation functions -- even Google does it for Google Analytics. Snippet is here.

– BMiner
Jan 22 '13 at 14:40

7

7

@BMiner if you insert a script element via DOM manipulation, is it loaded synchronously? Unless it is, it's not a replacement.

– John Dvorak
Jun 5 '13 at 10:41

@BMiner if you insert a script element via DOM manipulation, is it loaded synchronously? Unless it is, it's not a replacement.

– John Dvorak
Jun 5 '13 at 10:41

2

2

@JanDvorak - Good point; when using DOM manipulations, browsers will generally load the script asynchronously. You can use the onload DOM event to determine when the asynchronously loaded script is available for use.

– BMiner
Jun 6 '13 at 18:16

@JanDvorak - Good point; when using DOM manipulations, browsers will generally load the script asynchronously. You can use the onload DOM event to determine when the asynchronously loaded script is available for use.

– BMiner
Jun 6 '13 at 18:16

1

1

@JanDvorak It is loaded synchronously if it isn't external (doesn't have src). Otherwise it will be executed "as soon as possible", asynchronously.

– Oriol
Aug 14 '16 at 23:51

@JanDvorak It is loaded synchronously if it isn't external (doesn't have src). Otherwise it will be executed "as soon as possible", asynchronously.

– Oriol
Aug 14 '16 at 23:51

This still can break, as Chrome will deliberately refuse to run document.write calls that insert <script> tags if the user is on a 2G connection. See developers.google.com/web/updates/2016/08/…

– Flimm
Jul 12 '17 at 15:13

This still can break, as Chrome will deliberately refuse to run document.write calls that insert <script> tags if the user is on a 2G connection. See developers.google.com/web/updates/2016/08/…

– Flimm
Jul 12 '17 at 15:13

add a comment | 

36

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.

share|improve this answer

edited Aug 20 '14 at 7:38

T J

32.6k956109

answered Jul 14 '11 at 17:19

Sean McMillanSean McMillan

7,56544762

add a comment | 

36

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.

share|improve this answer

edited Aug 20 '14 at 7:38

T J

32.6k956109

answered Jul 14 '11 at 17:19

Sean McMillanSean McMillan

7,56544762

add a comment | 

36

36

36

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.

share|improve this answer

edited Aug 20 '14 at 7:38

T J

32.6k956109

answered Jul 14 '11 at 17:19

Sean McMillanSean McMillan

7,56544762

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.

share|improve this answer

edited Aug 20 '14 at 7:38

T J

32.6k956109

answered Jul 14 '11 at 17:19

Sean McMillanSean McMillan

7,56544762

share|improve this answer

share|improve this answer

edited Aug 20 '14 at 7:38

T J

32.6k956109

edited Aug 20 '14 at 7:38

T J

32.6k956109

edited Aug 20 '14 at 7:38

T J

32.6k956109

32.6k956109

answered Jul 14 '11 at 17:19

Sean McMillanSean McMillan

7,56544762

answered Jul 14 '11 at 17:19

Sean McMillanSean McMillan

7,56544762

answered Jul 14 '11 at 17:19

Sean McMillanSean McMillan

7,56544762

7,56544762

add a comment | 

add a comment | 

28

Pro:

• It's the easiest way to embed inline content from an external (to your host/domain) script.


• You can overwrite the entire content in a frame/iframe. I used to use this technique a lot for menu/navigation pieces before more modern Ajax techniques were widely available (1998-2002).

Con:

• It serializes the rendering engine to pause until said external script is loaded, which could take much longer than an internal script.


• It is usually used in such a way that the script is placed within the content, which is considered bad-form.

share|improve this answer

edited Nov 19 '13 at 20:54

answered Apr 29 '09 at 16:19

Tracker1Tracker1

13.9k86494

• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  
  There are more cons than that. For instance, Google Chrome will refuse to run document.write that creates <script> tag under certain circumstances. developers.google.com/web/updates/2016/08/…
  
  – Flimm
  Jul 12 '17 at 15:14
  

  
  
  
  

add a comment | 

28

Pro:

• It's the easiest way to embed inline content from an external (to your host/domain) script.


• You can overwrite the entire content in a frame/iframe. I used to use this technique a lot for menu/navigation pieces before more modern Ajax techniques were widely available (1998-2002).

Con:

• It serializes the rendering engine to pause until said external script is loaded, which could take much longer than an internal script.


• It is usually used in such a way that the script is placed within the content, which is considered bad-form.

share|improve this answer

edited Nov 19 '13 at 20:54

answered Apr 29 '09 at 16:19

Tracker1Tracker1

13.9k86494

• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  
  There are more cons than that. For instance, Google Chrome will refuse to run document.write that creates <script> tag under certain circumstances. developers.google.com/web/updates/2016/08/…
  
  – Flimm
  Jul 12 '17 at 15:14
  

  
  
  
  

add a comment | 

28

28

28

Pro:

• It's the easiest way to embed inline content from an external (to your host/domain) script.


• You can overwrite the entire content in a frame/iframe. I used to use this technique a lot for menu/navigation pieces before more modern Ajax techniques were widely available (1998-2002).

Con:

• It serializes the rendering engine to pause until said external script is loaded, which could take much longer than an internal script.


• It is usually used in such a way that the script is placed within the content, which is considered bad-form.

share|improve this answer

edited Nov 19 '13 at 20:54

answered Apr 29 '09 at 16:19

Tracker1Tracker1

13.9k86494

Pro:

• It's the easiest way to embed inline content from an external (to your host/domain) script.


• You can overwrite the entire content in a frame/iframe. I used to use this technique a lot for menu/navigation pieces before more modern Ajax techniques were widely available (1998-2002).

Con:

• It serializes the rendering engine to pause until said external script is loaded, which could take much longer than an internal script.


• It is usually used in such a way that the script is placed within the content, which is considered bad-form.

share|improve this answer

edited Nov 19 '13 at 20:54

answered Apr 29 '09 at 16:19

Tracker1Tracker1

13.9k86494

share|improve this answer

share|improve this answer

edited Nov 19 '13 at 20:54

edited Nov 19 '13 at 20:54

edited Nov 19 '13 at 20:54

answered Apr 29 '09 at 16:19

Tracker1Tracker1

13.9k86494

answered Apr 29 '09 at 16:19

Tracker1Tracker1

13.9k86494

answered Apr 29 '09 at 16:19

Tracker1Tracker1

13.9k86494

13.9k86494

• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  
  There are more cons than that. For instance, Google Chrome will refuse to run document.write that creates <script> tag under certain circumstances. developers.google.com/web/updates/2016/08/…
  
  – Flimm
  Jul 12 '17 at 15:14
  

  
  
  
  

add a comment | 

• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  
  There are more cons than that. For instance, Google Chrome will refuse to run document.write that creates <script> tag under certain circumstances. developers.google.com/web/updates/2016/08/…
  
  – Flimm
  Jul 12 '17 at 15:14
  

  
  
  
  

2

2

There are more cons than that. For instance, Google Chrome will refuse to run document.write that creates <script> tag under certain circumstances. developers.google.com/web/updates/2016/08/…

– Flimm
Jul 12 '17 at 15:14

There are more cons than that. For instance, Google Chrome will refuse to run document.write that creates <script> tag under certain circumstances. developers.google.com/web/updates/2016/08/…

– Flimm
Jul 12 '17 at 15:14

add a comment | 

9

Here's my twopence worth, in general you shouldn't use document.write for heavy lifting, but there is one instance where it is definitely useful:

http://www.quirksmode.org/blog/archives/2005/06/three_javascrip_1.html

I discovered this recently trying to create an AJAX slider gallery. I created two nested divs, and applied width/height and overflow: hidden to the outer <div> with JS. This was so that in the event that the browser had JS disabled, the div would float to accommodate the images in the gallery - some nice graceful degradation.

Thing is, as with the article above, this JS hijacking of the CSS didn't kick in until the page had loaded, causing a momentary flash as the div was loaded. So I needed to write a CSS rule, or include a sheet, as the page loaded.

Obviously, this won't work in XHTML, but since XHTML appears to be something of a dead duck (and renders as tag soup in IE) it might be worth re-evaluating your choice of DOCTYPE...

share|improve this answer

edited Dec 4 '11 at 0:31

Ry-♦

167k38339359

answered Oct 13 '09 at 13:23

sunwukungsunwukung

1,70133248

add a comment | 

9

Here's my twopence worth, in general you shouldn't use document.write for heavy lifting, but there is one instance where it is definitely useful:

http://www.quirksmode.org/blog/archives/2005/06/three_javascrip_1.html

I discovered this recently trying to create an AJAX slider gallery. I created two nested divs, and applied width/height and overflow: hidden to the outer <div> with JS. This was so that in the event that the browser had JS disabled, the div would float to accommodate the images in the gallery - some nice graceful degradation.

Thing is, as with the article above, this JS hijacking of the CSS didn't kick in until the page had loaded, causing a momentary flash as the div was loaded. So I needed to write a CSS rule, or include a sheet, as the page loaded.

Obviously, this won't work in XHTML, but since XHTML appears to be something of a dead duck (and renders as tag soup in IE) it might be worth re-evaluating your choice of DOCTYPE...

share|improve this answer

edited Dec 4 '11 at 0:31

Ry-♦

167k38339359

answered Oct 13 '09 at 13:23

sunwukungsunwukung

1,70133248

add a comment | 

9

9

9

Here's my twopence worth, in general you shouldn't use document.write for heavy lifting, but there is one instance where it is definitely useful:

http://www.quirksmode.org/blog/archives/2005/06/three_javascrip_1.html

I discovered this recently trying to create an AJAX slider gallery. I created two nested divs, and applied width/height and overflow: hidden to the outer <div> with JS. This was so that in the event that the browser had JS disabled, the div would float to accommodate the images in the gallery - some nice graceful degradation.

Thing is, as with the article above, this JS hijacking of the CSS didn't kick in until the page had loaded, causing a momentary flash as the div was loaded. So I needed to write a CSS rule, or include a sheet, as the page loaded.

Obviously, this won't work in XHTML, but since XHTML appears to be something of a dead duck (and renders as tag soup in IE) it might be worth re-evaluating your choice of DOCTYPE...

share|improve this answer

edited Dec 4 '11 at 0:31

Ry-♦

167k38339359

answered Oct 13 '09 at 13:23

sunwukungsunwukung

1,70133248

Here's my twopence worth, in general you shouldn't use document.write for heavy lifting, but there is one instance where it is definitely useful:

http://www.quirksmode.org/blog/archives/2005/06/three_javascrip_1.html

I discovered this recently trying to create an AJAX slider gallery. I created two nested divs, and applied width/height and overflow: hidden to the outer <div> with JS. This was so that in the event that the browser had JS disabled, the div would float to accommodate the images in the gallery - some nice graceful degradation.

Thing is, as with the article above, this JS hijacking of the CSS didn't kick in until the page had loaded, causing a momentary flash as the div was loaded. So I needed to write a CSS rule, or include a sheet, as the page loaded.

Obviously, this won't work in XHTML, but since XHTML appears to be something of a dead duck (and renders as tag soup in IE) it might be worth re-evaluating your choice of DOCTYPE...

share|improve this answer

edited Dec 4 '11 at 0:31

Ry-♦

167k38339359

answered Oct 13 '09 at 13:23

sunwukungsunwukung

1,70133248

share|improve this answer

share|improve this answer

edited Dec 4 '11 at 0:31

Ry-♦

167k38339359

edited Dec 4 '11 at 0:31

Ry-♦

167k38339359

edited Dec 4 '11 at 0:31

Ry-♦

167k38339359

167k38339359

answered Oct 13 '09 at 13:23

sunwukungsunwukung

1,70133248

answered Oct 13 '09 at 13:23

sunwukungsunwukung

1,70133248

answered Oct 13 '09 at 13:23

sunwukungsunwukung

1,70133248

1,70133248

add a comment | 

add a comment | 

7

It breaks pages using XML rendering (like XHTML pages).

Best: some browser switch back to HTML rendering and everything works fine.

Probable: some browser disable the document.write() function in XML rendering mode.

Worst: some browser will fire an XML error whenever using the document.write() function.

share|improve this answer

answered Apr 29 '09 at 15:44

Vincent RobertVincent Robert

27.6k1066110

add a comment | 

7

It breaks pages using XML rendering (like XHTML pages).

Best: some browser switch back to HTML rendering and everything works fine.

Probable: some browser disable the document.write() function in XML rendering mode.

Worst: some browser will fire an XML error whenever using the document.write() function.

share|improve this answer

answered Apr 29 '09 at 15:44

Vincent RobertVincent Robert

27.6k1066110

add a comment | 

7

7

7

It breaks pages using XML rendering (like XHTML pages).

Best: some browser switch back to HTML rendering and everything works fine.

Probable: some browser disable the document.write() function in XML rendering mode.

Worst: some browser will fire an XML error whenever using the document.write() function.

share|improve this answer

answered Apr 29 '09 at 15:44

Vincent RobertVincent Robert

27.6k1066110

It breaks pages using XML rendering (like XHTML pages).

Best: some browser switch back to HTML rendering and everything works fine.

Probable: some browser disable the document.write() function in XML rendering mode.

Worst: some browser will fire an XML error whenever using the document.write() function.

share|improve this answer

answered Apr 29 '09 at 15:44

Vincent RobertVincent Robert

27.6k1066110

share|improve this answer

share|improve this answer

answered Apr 29 '09 at 15:44

Vincent RobertVincent Robert

27.6k1066110

answered Apr 29 '09 at 15:44

Vincent RobertVincent Robert

27.6k1066110

answered Apr 29 '09 at 15:44

Vincent RobertVincent Robert

27.6k1066110

27.6k1066110

add a comment | 

add a comment | 

6

It overwrites content on the page which is the most obvious reason but I wouldn't call it "bad".

It just doesn't have much use unless you're creating an entire document using JavaScript in which case you may start with document.write.

Even so, you aren't really leveraging the DOM when you use document.write--you are just dumping a blob of text into the document so I'd say it's bad form.

share|improve this answer

answered Apr 29 '09 at 15:29

aleembaleemb

22.2k1588106

• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  One clarification: document.write inserts contents on the page, it doesn't overwrite them.
  
  – Peter Dolberg
  Apr 29 '09 at 15:45
  

  
  
  
  


• 
  
  
  

  
  5
  

  
  
  
  
  
  

  
  
  @Peter, it does overwrite the content if you call it after the document is loaded. I'm guessing that's what aleemb means.
  
  – Matthew Crumley
  Apr 29 '09 at 17:09
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  
  Are you suggesting that one should instead manually build the individual DOM nodes in code rather than just doing something like div.innerHTML = "<label for='MySelect'>Choose One</label><select id='MySelect'><option value='foo' selected=''>foo</option><option value='bar'>bar</option></select>";? That seems like it would produce a lot of unnecessary and less readable code. It's also the exact opposite of the approach John Resig and other JS developers advocate.
  
  – Lèse majesté
  Dec 26 '12 at 8:25
  
  
  

  
  
  
  

add a comment | 

6

It overwrites content on the page which is the most obvious reason but I wouldn't call it "bad".

It just doesn't have much use unless you're creating an entire document using JavaScript in which case you may start with document.write.

Even so, you aren't really leveraging the DOM when you use document.write--you are just dumping a blob of text into the document so I'd say it's bad form.

share|improve this answer

answered Apr 29 '09 at 15:29

aleembaleemb

22.2k1588106

• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  One clarification: document.write inserts contents on the page, it doesn't overwrite them.
  
  – Peter Dolberg
  Apr 29 '09 at 15:45
  

  
  
  
  


• 
  
  
  

  
  5
  

  
  
  
  
  
  

  
  
  @Peter, it does overwrite the content if you call it after the document is loaded. I'm guessing that's what aleemb means.
  
  – Matthew Crumley
  Apr 29 '09 at 17:09
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  
  Are you suggesting that one should instead manually build the individual DOM nodes in code rather than just doing something like div.innerHTML = "<label for='MySelect'>Choose One</label><select id='MySelect'><option value='foo' selected=''>foo</option><option value='bar'>bar</option></select>";? That seems like it would produce a lot of unnecessary and less readable code. It's also the exact opposite of the approach John Resig and other JS developers advocate.
  
  – Lèse majesté
  Dec 26 '12 at 8:25
  
  
  

  
  
  
  

add a comment | 

6

6

6

It overwrites content on the page which is the most obvious reason but I wouldn't call it "bad".

It just doesn't have much use unless you're creating an entire document using JavaScript in which case you may start with document.write.

Even so, you aren't really leveraging the DOM when you use document.write--you are just dumping a blob of text into the document so I'd say it's bad form.

share|improve this answer

answered Apr 29 '09 at 15:29

aleembaleemb

22.2k1588106

It overwrites content on the page which is the most obvious reason but I wouldn't call it "bad".

It just doesn't have much use unless you're creating an entire document using JavaScript in which case you may start with document.write.

Even so, you aren't really leveraging the DOM when you use document.write--you are just dumping a blob of text into the document so I'd say it's bad form.

share|improve this answer

answered Apr 29 '09 at 15:29

aleembaleemb

22.2k1588106

share|improve this answer

share|improve this answer

answered Apr 29 '09 at 15:29

aleembaleemb

22.2k1588106

answered Apr 29 '09 at 15:29

aleembaleemb

22.2k1588106

answered Apr 29 '09 at 15:29

aleembaleemb

22.2k1588106

22.2k1588106

• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  One clarification: document.write inserts contents on the page, it doesn't overwrite them.
  
  – Peter Dolberg
  Apr 29 '09 at 15:45
  

  
  
  
  


• 
  
  
  

  
  5
  

  
  
  
  
  
  

  
  
  @Peter, it does overwrite the content if you call it after the document is loaded. I'm guessing that's what aleemb means.
  
  – Matthew Crumley
  Apr 29 '09 at 17:09
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  
  Are you suggesting that one should instead manually build the individual DOM nodes in code rather than just doing something like div.innerHTML = "<label for='MySelect'>Choose One</label><select id='MySelect'><option value='foo' selected=''>foo</option><option value='bar'>bar</option></select>";? That seems like it would produce a lot of unnecessary and less readable code. It's also the exact opposite of the approach John Resig and other JS developers advocate.
  
  – Lèse majesté
  Dec 26 '12 at 8:25
  
  
  

  
  
  
  

add a comment | 

• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  One clarification: document.write inserts contents on the page, it doesn't overwrite them.
  
  – Peter Dolberg
  Apr 29 '09 at 15:45
  

  
  
  
  


• 
  
  
  

  
  5
  

  
  
  
  
  
  

  
  
  @Peter, it does overwrite the content if you call it after the document is loaded. I'm guessing that's what aleemb means.
  
  – Matthew Crumley
  Apr 29 '09 at 17:09
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  
  Are you suggesting that one should instead manually build the individual DOM nodes in code rather than just doing something like div.innerHTML = "<label for='MySelect'>Choose One</label><select id='MySelect'><option value='foo' selected=''>foo</option><option value='bar'>bar</option></select>";? That seems like it would produce a lot of unnecessary and less readable code. It's also the exact opposite of the approach John Resig and other JS developers advocate.
  
  – Lèse majesté
  Dec 26 '12 at 8:25
  
  
  

  
  
  
  

1

1

One clarification: document.write inserts contents on the page, it doesn't overwrite them.

– Peter Dolberg
Apr 29 '09 at 15:45

One clarification: document.write inserts contents on the page, it doesn't overwrite them.

– Peter Dolberg
Apr 29 '09 at 15:45

5

5

@Peter, it does overwrite the content if you call it after the document is loaded. I'm guessing that's what aleemb means.

– Matthew Crumley
Apr 29 '09 at 17:09

@Peter, it does overwrite the content if you call it after the document is loaded. I'm guessing that's what aleemb means.

– Matthew Crumley
Apr 29 '09 at 17:09

2

2

Are you suggesting that one should instead manually build the individual DOM nodes in code rather than just doing something like div.innerHTML = "<label for='MySelect'>Choose One</label><select id='MySelect'><option value='foo' selected=''>foo</option><option value='bar'>bar</option></select>";? That seems like it would produce a lot of unnecessary and less readable code. It's also the exact opposite of the approach John Resig and other JS developers advocate.

– Lèse majesté
Dec 26 '12 at 8:25

Are you suggesting that one should instead manually build the individual DOM nodes in code rather than just doing something like div.innerHTML = "<label for='MySelect'>Choose One</label><select id='MySelect'><option value='foo' selected=''>foo</option><option value='bar'>bar</option></select>";? That seems like it would produce a lot of unnecessary and less readable code. It's also the exact opposite of the approach John Resig and other JS developers advocate.

– Lèse majesté
Dec 26 '12 at 8:25

add a comment | 

5

Off the top of my head:

1. document.write needs to be used in the page load or body load. So if you want to use the script in any other time to update your page content document.write is pretty much useless.




2. Technically document.write will only update HTML pages not XHTML/XML. IE seems to be pretty forgiving of this fact but other browsers will not be.

http://www.w3.org/MarkUp/2004/xhtml-faq#docwrite

share|improve this answer

edited Dec 4 '11 at 0:32

Ry-♦

167k38339359

answered Apr 29 '09 at 15:31

brendanbrendan

22k1661103

• 
  
  
  

  
  8
  

  
  
  
  
  
  

  
  
  IE is forgiving because it doesn't support XHTML. If/when they do, document.write will probably stop working (only in XHTML of course).
  
  – Matthew Crumley
  Apr 29 '09 at 17:12
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  
  XHTML is irrelevant on the web. Even pages with a strict XHTML doctype are not actually treated as XML in that regard, browser developers don't trust page authors that much.
  
  – RobG
  Oct 27 '15 at 0:37
  
  
  

  
  
  
  

add a comment | 

5

Off the top of my head:

1. document.write needs to be used in the page load or body load. So if you want to use the script in any other time to update your page content document.write is pretty much useless.




2. Technically document.write will only update HTML pages not XHTML/XML. IE seems to be pretty forgiving of this fact but other browsers will not be.

http://www.w3.org/MarkUp/2004/xhtml-faq#docwrite

share|improve this answer

edited Dec 4 '11 at 0:32

Ry-♦

167k38339359

answered Apr 29 '09 at 15:31

brendanbrendan

22k1661103

• 
  
  
  

  
  8
  

  
  
  
  
  
  

  
  
  IE is forgiving because it doesn't support XHTML. If/when they do, document.write will probably stop working (only in XHTML of course).
  
  – Matthew Crumley
  Apr 29 '09 at 17:12
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  
  XHTML is irrelevant on the web. Even pages with a strict XHTML doctype are not actually treated as XML in that regard, browser developers don't trust page authors that much.
  
  – RobG
  Oct 27 '15 at 0:37
  
  
  

  
  
  
  

add a comment | 

5

5

5

Off the top of my head:

1. document.write needs to be used in the page load or body load. So if you want to use the script in any other time to update your page content document.write is pretty much useless.




2. Technically document.write will only update HTML pages not XHTML/XML. IE seems to be pretty forgiving of this fact but other browsers will not be.

http://www.w3.org/MarkUp/2004/xhtml-faq#docwrite

share|improve this answer

edited Dec 4 '11 at 0:32

Ry-♦

167k38339359

answered Apr 29 '09 at 15:31

brendanbrendan

22k1661103

Off the top of my head:

1. document.write needs to be used in the page load or body load. So if you want to use the script in any other time to update your page content document.write is pretty much useless.




2. Technically document.write will only update HTML pages not XHTML/XML. IE seems to be pretty forgiving of this fact but other browsers will not be.

http://www.w3.org/MarkUp/2004/xhtml-faq#docwrite

share|improve this answer

edited Dec 4 '11 at 0:32

Ry-♦

167k38339359

answered Apr 29 '09 at 15:31

brendanbrendan

22k1661103

share|improve this answer

share|improve this answer

edited Dec 4 '11 at 0:32

Ry-♦

167k38339359

edited Dec 4 '11 at 0:32

Ry-♦

167k38339359

edited Dec 4 '11 at 0:32

Ry-♦

167k38339359

167k38339359

answered Apr 29 '09 at 15:31

brendanbrendan

22k1661103

answered Apr 29 '09 at 15:31

brendanbrendan

22k1661103

answered Apr 29 '09 at 15:31

brendanbrendan

22k1661103

22k1661103

• 
  
  
  

  
  8
  

  
  
  
  
  
  

  
  
  IE is forgiving because it doesn't support XHTML. If/when they do, document.write will probably stop working (only in XHTML of course).
  
  – Matthew Crumley
  Apr 29 '09 at 17:12
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  
  XHTML is irrelevant on the web. Even pages with a strict XHTML doctype are not actually treated as XML in that regard, browser developers don't trust page authors that much.
  
  – RobG
  Oct 27 '15 at 0:37
  
  
  

  
  
  
  

add a comment | 

• 
  
  
  

  
  8
  

  
  
  
  
  
  

  
  
  IE is forgiving because it doesn't support XHTML. If/when they do, document.write will probably stop working (only in XHTML of course).
  
  – Matthew Crumley
  Apr 29 '09 at 17:12
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  
  XHTML is irrelevant on the web. Even pages with a strict XHTML doctype are not actually treated as XML in that regard, browser developers don't trust page authors that much.
  
  – RobG
  Oct 27 '15 at 0:37
  
  
  

  
  
  
  

8

8

IE is forgiving because it doesn't support XHTML. If/when they do, document.write will probably stop working (only in XHTML of course).

– Matthew Crumley
Apr 29 '09 at 17:12

IE is forgiving because it doesn't support XHTML. If/when they do, document.write will probably stop working (only in XHTML of course).

– Matthew Crumley
Apr 29 '09 at 17:12

2

2

XHTML is irrelevant on the web. Even pages with a strict XHTML doctype are not actually treated as XML in that regard, browser developers don't trust page authors that much.

– RobG
Oct 27 '15 at 0:37

XHTML is irrelevant on the web. Even pages with a strict XHTML doctype are not actually treated as XML in that regard, browser developers don't trust page authors that much.

– RobG
Oct 27 '15 at 0:37

add a comment | 

2

Chrome may block document.write that inserts a script in certain cases. When this happens, it will display this warning in the console:

A Parser-blocking, cross-origin script, ..., is invoked via
document.write. This may be blocked by the browser if the device has
poor network connectivity.

References:

• 
  This article on developers.google.com goes into more detail.


• https://www.chromestatus.com/feature/5718547946799104

share|improve this answer

edited Jul 12 '17 at 15:19

Flimm

51.2k23134156

answered Feb 1 '17 at 23:03

TrueWillTrueWill

19.6k674121

add a comment | 

2

Chrome may block document.write that inserts a script in certain cases. When this happens, it will display this warning in the console:

A Parser-blocking, cross-origin script, ..., is invoked via
document.write. This may be blocked by the browser if the device has
poor network connectivity.

References:

• 
  This article on developers.google.com goes into more detail.


• https://www.chromestatus.com/feature/5718547946799104

share|improve this answer

edited Jul 12 '17 at 15:19

Flimm

51.2k23134156

answered Feb 1 '17 at 23:03

TrueWillTrueWill

19.6k674121

add a comment | 

2

2

2

Chrome may block document.write that inserts a script in certain cases. When this happens, it will display this warning in the console:

A Parser-blocking, cross-origin script, ..., is invoked via
document.write. This may be blocked by the browser if the device has
poor network connectivity.

References:

• 
  This article on developers.google.com goes into more detail.


• https://www.chromestatus.com/feature/5718547946799104

share|improve this answer

edited Jul 12 '17 at 15:19

Flimm

51.2k23134156

answered Feb 1 '17 at 23:03

TrueWillTrueWill

19.6k674121

Chrome may block document.write that inserts a script in certain cases. When this happens, it will display this warning in the console:

A Parser-blocking, cross-origin script, ..., is invoked via
document.write. This may be blocked by the browser if the device has
poor network connectivity.

References:

• 
  This article on developers.google.com goes into more detail.


• https://www.chromestatus.com/feature/5718547946799104

share|improve this answer

edited Jul 12 '17 at 15:19

Flimm

51.2k23134156

answered Feb 1 '17 at 23:03

TrueWillTrueWill

19.6k674121

share|improve this answer

share|improve this answer

edited Jul 12 '17 at 15:19

Flimm

51.2k23134156

edited Jul 12 '17 at 15:19

Flimm

51.2k23134156

edited Jul 12 '17 at 15:19

Flimm

51.2k23134156

51.2k23134156

answered Feb 1 '17 at 23:03

TrueWillTrueWill

19.6k674121

answered Feb 1 '17 at 23:03

TrueWillTrueWill

19.6k674121

answered Feb 1 '17 at 23:03

TrueWillTrueWill

19.6k674121

19.6k674121

add a comment | 

add a comment | 

1

One can think of document.write() (and .innerHTML) as evaluating a source code string. This can be very handy for many applications. For example if you get HTML code as a string from some source, it is handy to just "evaluate" it.

In the context of Lisp, DOM manipulation would be like manipulating a list structure, e.g. create the list (orange) by doing:

(cons 'orange '())

And document.write() would be like evaluating a string, e.g. create a list by evaluating a source code string like this:

(eval-string "(cons 'orange '())")

Lisp also has the very useful ability to create code using list manipulation (like using the "DOM style" to create a JS parse tree). This means you can build up a list structure using the "DOM style", rather than the "string style", and then run that code, e.g. like this:

(eval '(cons 'orange '()))

If you implement coding tools, like simple live editors, it is very handy to have the ability to quickly evaluate a string, for example using document.write() or .innerHTML. Lisp is ideal in this sense, but you can do very cool stuff also in JS, and many people are doing that, like http://jsbin.com/

share|improve this answer

answered Feb 12 '13 at 17:48

Mikael KindborgMikael Kindborg

21225

add a comment | 

1

One can think of document.write() (and .innerHTML) as evaluating a source code string. This can be very handy for many applications. For example if you get HTML code as a string from some source, it is handy to just "evaluate" it.

In the context of Lisp, DOM manipulation would be like manipulating a list structure, e.g. create the list (orange) by doing:

(cons 'orange '())

And document.write() would be like evaluating a string, e.g. create a list by evaluating a source code string like this:

(eval-string "(cons 'orange '())")

Lisp also has the very useful ability to create code using list manipulation (like using the "DOM style" to create a JS parse tree). This means you can build up a list structure using the "DOM style", rather than the "string style", and then run that code, e.g. like this:

(eval '(cons 'orange '()))

If you implement coding tools, like simple live editors, it is very handy to have the ability to quickly evaluate a string, for example using document.write() or .innerHTML. Lisp is ideal in this sense, but you can do very cool stuff also in JS, and many people are doing that, like http://jsbin.com/

share|improve this answer

answered Feb 12 '13 at 17:48

Mikael KindborgMikael Kindborg

21225

add a comment | 

1

1

1

One can think of document.write() (and .innerHTML) as evaluating a source code string. This can be very handy for many applications. For example if you get HTML code as a string from some source, it is handy to just "evaluate" it.

In the context of Lisp, DOM manipulation would be like manipulating a list structure, e.g. create the list (orange) by doing:

(cons 'orange '())

And document.write() would be like evaluating a string, e.g. create a list by evaluating a source code string like this:

(eval-string "(cons 'orange '())")

Lisp also has the very useful ability to create code using list manipulation (like using the "DOM style" to create a JS parse tree). This means you can build up a list structure using the "DOM style", rather than the "string style", and then run that code, e.g. like this:

(eval '(cons 'orange '()))

If you implement coding tools, like simple live editors, it is very handy to have the ability to quickly evaluate a string, for example using document.write() or .innerHTML. Lisp is ideal in this sense, but you can do very cool stuff also in JS, and many people are doing that, like http://jsbin.com/

share|improve this answer

answered Feb 12 '13 at 17:48

Mikael KindborgMikael Kindborg

21225

One can think of document.write() (and .innerHTML) as evaluating a source code string. This can be very handy for many applications. For example if you get HTML code as a string from some source, it is handy to just "evaluate" it.

In the context of Lisp, DOM manipulation would be like manipulating a list structure, e.g. create the list (orange) by doing:

(cons 'orange '())

And document.write() would be like evaluating a string, e.g. create a list by evaluating a source code string like this:

(eval-string "(cons 'orange '())")

Lisp also has the very useful ability to create code using list manipulation (like using the "DOM style" to create a JS parse tree). This means you can build up a list structure using the "DOM style", rather than the "string style", and then run that code, e.g. like this:

(eval '(cons 'orange '()))

If you implement coding tools, like simple live editors, it is very handy to have the ability to quickly evaluate a string, for example using document.write() or .innerHTML. Lisp is ideal in this sense, but you can do very cool stuff also in JS, and many people are doing that, like http://jsbin.com/

share|improve this answer

answered Feb 12 '13 at 17:48

Mikael KindborgMikael Kindborg

21225

share|improve this answer

share|improve this answer

answered Feb 12 '13 at 17:48

Mikael KindborgMikael Kindborg

21225

answered Feb 12 '13 at 17:48

Mikael KindborgMikael Kindborg

21225

answered Feb 12 '13 at 17:48

Mikael KindborgMikael Kindborg

21225

21225

add a comment | 

add a comment | 

1

• A simple reason why document.write is a bad practice is that you cannot come up with a scenario where you cannot find a better alternative.


• Another reason is that you are dealing with strings instead of objects (it is very primitive).


• It does only append to documents.


• It has nothing of the beauty of for instance the MVC (Model-View-Controller) pattern.


• It is a lot more powerful to present dynamic content with ajax+jQuery or angularJS.

share|improve this answer

answered Sep 9 '16 at 19:37

Anders LindénAnders Lindén

3,53033069

• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  As for as your first bullet goes, how are you going to solve what @sunwukung describes in his answer above? I agree you could solve it with DOM manipulations, but as DOM manipulations go, it is hard to avoid FUOC at times without document.write.
  
  – bert bruynooghe
  May 19 '17 at 16:29
  
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Is FUOC a problem anymore?
  
  – Anders Lindén
  Aug 18 '18 at 7:56
  

  
  
  
  

add a comment | 

1

• A simple reason why document.write is a bad practice is that you cannot come up with a scenario where you cannot find a better alternative.


• Another reason is that you are dealing with strings instead of objects (it is very primitive).


• It does only append to documents.


• It has nothing of the beauty of for instance the MVC (Model-View-Controller) pattern.


• It is a lot more powerful to present dynamic content with ajax+jQuery or angularJS.

share|improve this answer

answered Sep 9 '16 at 19:37

Anders LindénAnders Lindén

3,53033069

• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  As for as your first bullet goes, how are you going to solve what @sunwukung describes in his answer above? I agree you could solve it with DOM manipulations, but as DOM manipulations go, it is hard to avoid FUOC at times without document.write.
  
  – bert bruynooghe
  May 19 '17 at 16:29
  
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Is FUOC a problem anymore?
  
  – Anders Lindén
  Aug 18 '18 at 7:56
  

  
  
  
  

add a comment | 

1

1

1

• A simple reason why document.write is a bad practice is that you cannot come up with a scenario where you cannot find a better alternative.


• Another reason is that you are dealing with strings instead of objects (it is very primitive).


• It does only append to documents.


• It has nothing of the beauty of for instance the MVC (Model-View-Controller) pattern.


• It is a lot more powerful to present dynamic content with ajax+jQuery or angularJS.

share|improve this answer

answered Sep 9 '16 at 19:37

Anders LindénAnders Lindén

3,53033069

• A simple reason why document.write is a bad practice is that you cannot come up with a scenario where you cannot find a better alternative.


• Another reason is that you are dealing with strings instead of objects (it is very primitive).


• It does only append to documents.


• It has nothing of the beauty of for instance the MVC (Model-View-Controller) pattern.


• It is a lot more powerful to present dynamic content with ajax+jQuery or angularJS.

share|improve this answer

answered Sep 9 '16 at 19:37

Anders LindénAnders Lindén

3,53033069

share|improve this answer

share|improve this answer

answered Sep 9 '16 at 19:37

Anders LindénAnders Lindén

3,53033069

answered Sep 9 '16 at 19:37

Anders LindénAnders Lindén

3,53033069

answered Sep 9 '16 at 19:37

Anders LindénAnders Lindén

3,53033069

3,53033069

• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  As for as your first bullet goes, how are you going to solve what @sunwukung describes in his answer above? I agree you could solve it with DOM manipulations, but as DOM manipulations go, it is hard to avoid FUOC at times without document.write.
  
  – bert bruynooghe
  May 19 '17 at 16:29
  
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Is FUOC a problem anymore?
  
  – Anders Lindén
  Aug 18 '18 at 7:56
  

  
  
  
  

add a comment | 

• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  As for as your first bullet goes, how are you going to solve what @sunwukung describes in his answer above? I agree you could solve it with DOM manipulations, but as DOM manipulations go, it is hard to avoid FUOC at times without document.write.
  
  – bert bruynooghe
  May 19 '17 at 16:29
  
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Is FUOC a problem anymore?
  
  – Anders Lindén
  Aug 18 '18 at 7:56
  

  
  
  
  

As for as your first bullet goes, how are you going to solve what @sunwukung describes in his answer above? I agree you could solve it with DOM manipulations, but as DOM manipulations go, it is hard to avoid FUOC at times without document.write.

– bert bruynooghe
May 19 '17 at 16:29

As for as your first bullet goes, how are you going to solve what @sunwukung describes in his answer above? I agree you could solve it with DOM manipulations, but as DOM manipulations go, it is hard to avoid FUOC at times without document.write.

– bert bruynooghe
May 19 '17 at 16:29

Is FUOC a problem anymore?

– Anders Lindén
Aug 18 '18 at 7:56

Is FUOC a problem anymore?

– Anders Lindén
Aug 18 '18 at 7:56

add a comment | 

1

The disadvantages of document.write mainly depends on these 3 factors:

a) Implementation

The document.write() is mostly used to write content to the screen as soon as that content is needed. This means it happens anywhere, either in a JavaScript file or inside a script tag within an HTML file. With the script tag being placed anywhere within such an HTML file, it is a bad idea to have document.write() statements inside script blocks that are intertwined with HTML inside a web page.

b) Rendering

Well designed code in general will take any dynamically generated content, store it in memory, keep manipulating it as it passes through the code before it finally gets spit out to the screen. So to reiterate the last point in the preceding section, rendering content in-place may render faster than other content that may be relied upon, but it may not be available to the other code that in turn requires the content to be rendered for processing. To solve this dilemma we need to get rid of the document.write() and implement it the right way.

c) Impossible Manipulation

Once it's written it's done and over with. We cannot go back to manipulate it without tapping into the DOM.

share|improve this answer

answered Dec 9 '16 at 5:13

user3167857user3167857

259

add a comment | 

1

The disadvantages of document.write mainly depends on these 3 factors:

a) Implementation

The document.write() is mostly used to write content to the screen as soon as that content is needed. This means it happens anywhere, either in a JavaScript file or inside a script tag within an HTML file. With the script tag being placed anywhere within such an HTML file, it is a bad idea to have document.write() statements inside script blocks that are intertwined with HTML inside a web page.

b) Rendering

Well designed code in general will take any dynamically generated content, store it in memory, keep manipulating it as it passes through the code before it finally gets spit out to the screen. So to reiterate the last point in the preceding section, rendering content in-place may render faster than other content that may be relied upon, but it may not be available to the other code that in turn requires the content to be rendered for processing. To solve this dilemma we need to get rid of the document.write() and implement it the right way.

c) Impossible Manipulation

Once it's written it's done and over with. We cannot go back to manipulate it without tapping into the DOM.

share|improve this answer

answered Dec 9 '16 at 5:13

user3167857user3167857

259

add a comment | 

1

1

1

The disadvantages of document.write mainly depends on these 3 factors:

a) Implementation

The document.write() is mostly used to write content to the screen as soon as that content is needed. This means it happens anywhere, either in a JavaScript file or inside a script tag within an HTML file. With the script tag being placed anywhere within such an HTML file, it is a bad idea to have document.write() statements inside script blocks that are intertwined with HTML inside a web page.

b) Rendering

Well designed code in general will take any dynamically generated content, store it in memory, keep manipulating it as it passes through the code before it finally gets spit out to the screen. So to reiterate the last point in the preceding section, rendering content in-place may render faster than other content that may be relied upon, but it may not be available to the other code that in turn requires the content to be rendered for processing. To solve this dilemma we need to get rid of the document.write() and implement it the right way.

c) Impossible Manipulation

Once it's written it's done and over with. We cannot go back to manipulate it without tapping into the DOM.

share|improve this answer

answered Dec 9 '16 at 5:13

user3167857user3167857

259

The disadvantages of document.write mainly depends on these 3 factors:

a) Implementation

The document.write() is mostly used to write content to the screen as soon as that content is needed. This means it happens anywhere, either in a JavaScript file or inside a script tag within an HTML file. With the script tag being placed anywhere within such an HTML file, it is a bad idea to have document.write() statements inside script blocks that are intertwined with HTML inside a web page.

b) Rendering

Well designed code in general will take any dynamically generated content, store it in memory, keep manipulating it as it passes through the code before it finally gets spit out to the screen. So to reiterate the last point in the preceding section, rendering content in-place may render faster than other content that may be relied upon, but it may not be available to the other code that in turn requires the content to be rendered for processing. To solve this dilemma we need to get rid of the document.write() and implement it the right way.

c) Impossible Manipulation

Once it's written it's done and over with. We cannot go back to manipulate it without tapping into the DOM.

share|improve this answer

answered Dec 9 '16 at 5:13

user3167857user3167857

259

share|improve this answer

share|improve this answer

answered Dec 9 '16 at 5:13

user3167857user3167857

259

answered Dec 9 '16 at 5:13

user3167857user3167857

259

answered Dec 9 '16 at 5:13

user3167857user3167857

259

259

add a comment | 

add a comment | 

1

Based on analysis done by Google-Chrome Dev Tools' Lighthouse Audit

share|improve this answer

answered Feb 22 '18 at 8:58

Sudip BhandariSudip Bhandari

7661117

add a comment | 

1

Based on analysis done by Google-Chrome Dev Tools' Lighthouse Audit

share|improve this answer

answered Feb 22 '18 at 8:58

Sudip BhandariSudip Bhandari

7661117

add a comment | 

1

1

1

Based on analysis done by Google-Chrome Dev Tools' Lighthouse Audit

share|improve this answer

answered Feb 22 '18 at 8:58

Sudip BhandariSudip Bhandari

7661117

Based on analysis done by Google-Chrome Dev Tools' Lighthouse Audit

share|improve this answer

answered Feb 22 '18 at 8:58

Sudip BhandariSudip Bhandari

7661117

share|improve this answer

share|improve this answer

answered Feb 22 '18 at 8:58

Sudip BhandariSudip Bhandari

7661117

answered Feb 22 '18 at 8:58

Sudip BhandariSudip Bhandari

7661117

answered Feb 22 '18 at 8:58

Sudip BhandariSudip Bhandari

7661117

7661117

add a comment | 

add a comment | 

0

Browser Violation

.write is considered a browser violation as it halts the parser from rendering the page. The parser receives the message that the document is being modified; hence, it gets blocked until JS has completed its process. Only at this time will the parser resume.

Performance

The biggest consequence of employing such a method is lowered performance. The browser will take longer to load page content. The adverse reaction on load time depends on what is being written to the document. You won't see much of a difference if you are adding a <p> tag to the DOM as opposed to passing an array of 50-some references to JavaScript libraries (something which I have seen in working code and resulted in an 11 second delay - of course, this also depends on your hardware).

All in all, it's best to steer clear of this method if you can help it.

For more info see Intervening against document.write()

share|improve this answer

edited Nov 20 '18 at 1:50

answered Nov 20 '18 at 1:19

Arielle AdamsArielle Adams

587

add a comment | 

0

Browser Violation

.write is considered a browser violation as it halts the parser from rendering the page. The parser receives the message that the document is being modified; hence, it gets blocked until JS has completed its process. Only at this time will the parser resume.

Performance

The biggest consequence of employing such a method is lowered performance. The browser will take longer to load page content. The adverse reaction on load time depends on what is being written to the document. You won't see much of a difference if you are adding a <p> tag to the DOM as opposed to passing an array of 50-some references to JavaScript libraries (something which I have seen in working code and resulted in an 11 second delay - of course, this also depends on your hardware).

All in all, it's best to steer clear of this method if you can help it.

For more info see Intervening against document.write()

share|improve this answer

edited Nov 20 '18 at 1:50

answered Nov 20 '18 at 1:19

Arielle AdamsArielle Adams

587

add a comment | 

0

0

0

Browser Violation

.write is considered a browser violation as it halts the parser from rendering the page. The parser receives the message that the document is being modified; hence, it gets blocked until JS has completed its process. Only at this time will the parser resume.

Performance

The biggest consequence of employing such a method is lowered performance. The browser will take longer to load page content. The adverse reaction on load time depends on what is being written to the document. You won't see much of a difference if you are adding a <p> tag to the DOM as opposed to passing an array of 50-some references to JavaScript libraries (something which I have seen in working code and resulted in an 11 second delay - of course, this also depends on your hardware).

All in all, it's best to steer clear of this method if you can help it.

For more info see Intervening against document.write()

share|improve this answer

edited Nov 20 '18 at 1:50

answered Nov 20 '18 at 1:19

Arielle AdamsArielle Adams

587

Browser Violation

.write is considered a browser violation as it halts the parser from rendering the page. The parser receives the message that the document is being modified; hence, it gets blocked until JS has completed its process. Only at this time will the parser resume.

Performance

The biggest consequence of employing such a method is lowered performance. The browser will take longer to load page content. The adverse reaction on load time depends on what is being written to the document. You won't see much of a difference if you are adding a <p> tag to the DOM as opposed to passing an array of 50-some references to JavaScript libraries (something which I have seen in working code and resulted in an 11 second delay - of course, this also depends on your hardware).

All in all, it's best to steer clear of this method if you can help it.

For more info see Intervening against document.write()

share|improve this answer

edited Nov 20 '18 at 1:50

answered Nov 20 '18 at 1:19

Arielle AdamsArielle Adams

587

share|improve this answer

share|improve this answer

edited Nov 20 '18 at 1:50

edited Nov 20 '18 at 1:50

edited Nov 20 '18 at 1:50

answered Nov 20 '18 at 1:19

Arielle AdamsArielle Adams

587

answered Nov 20 '18 at 1:19

Arielle AdamsArielle Adams

587

answered Nov 20 '18 at 1:19

Arielle AdamsArielle Adams

587

587

add a comment | 

add a comment | 

-3

I think the biggest problem is that any elements written via document.write are added to the end of the page's elements. That's rarely the desired effect with modern page layouts and AJAX. (you have to keep in mind that the elements in the DOM are temporal, and when the script runs may affect its behavior).

It's much better to set a placeholder element on the page, and then manipulate it's innerHTML.

share|improve this answer

answered Apr 29 '09 at 15:31

BnWastelandBnWasteland

1,40811514

• 
  
  
  

  
  14
  

  
  
  
  
  
  

  
  
  This is not true. document.write does not add the content to the end of the page like it's an append. They are written in place.
  
  – Peter Bailey
  Apr 29 '09 at 15:35
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  @Peter Bailey, I know this is an old thread, but really this shouldn't be downvoted. whether it appends or not depends on whether document.write() runs inline while the page is loading. If it is called from a function after the page loads then the first document.write() will replace the entire body and subsequent calls will append to it.
  
  – Octopus
  Dec 17 '14 at 5:53
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  
  @Octopus Yes, but that's circumstantial. It appends in that scenario only because there's a fresh document. It's still not accurate to say "document.write() appends." Yes, it's an old answer and an old downvote, but I still stand by it.
  
  – Peter Bailey
  Dec 18 '14 at 14:03
  
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Its fine. I spoke imprecisely. I would've edited it long ago, but there is a much better answer above. I would point out though that "written in place" is equally imprecise.
  
  – BnWasteland
  Dec 18 '14 at 20:40
  

  
  
  
  

add a comment | 

-3

I think the biggest problem is that any elements written via document.write are added to the end of the page's elements. That's rarely the desired effect with modern page layouts and AJAX. (you have to keep in mind that the elements in the DOM are temporal, and when the script runs may affect its behavior).

It's much better to set a placeholder element on the page, and then manipulate it's innerHTML.

share|improve this answer

answered Apr 29 '09 at 15:31

BnWastelandBnWasteland

1,40811514

• 
  
  
  

  
  14
  

  
  
  
  
  
  

  
  
  This is not true. document.write does not add the content to the end of the page like it's an append. They are written in place.
  
  – Peter Bailey
  Apr 29 '09 at 15:35
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  @Peter Bailey, I know this is an old thread, but really this shouldn't be downvoted. whether it appends or not depends on whether document.write() runs inline while the page is loading. If it is called from a function after the page loads then the first document.write() will replace the entire body and subsequent calls will append to it.
  
  – Octopus
  Dec 17 '14 at 5:53
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  
  @Octopus Yes, but that's circumstantial. It appends in that scenario only because there's a fresh document. It's still not accurate to say "document.write() appends." Yes, it's an old answer and an old downvote, but I still stand by it.
  
  – Peter Bailey
  Dec 18 '14 at 14:03
  
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Its fine. I spoke imprecisely. I would've edited it long ago, but there is a much better answer above. I would point out though that "written in place" is equally imprecise.
  
  – BnWasteland
  Dec 18 '14 at 20:40
  

  
  
  
  

add a comment | 

-3

-3

-3

I think the biggest problem is that any elements written via document.write are added to the end of the page's elements. That's rarely the desired effect with modern page layouts and AJAX. (you have to keep in mind that the elements in the DOM are temporal, and when the script runs may affect its behavior).

It's much better to set a placeholder element on the page, and then manipulate it's innerHTML.

share|improve this answer

answered Apr 29 '09 at 15:31

BnWastelandBnWasteland

1,40811514

I think the biggest problem is that any elements written via document.write are added to the end of the page's elements. That's rarely the desired effect with modern page layouts and AJAX. (you have to keep in mind that the elements in the DOM are temporal, and when the script runs may affect its behavior).

It's much better to set a placeholder element on the page, and then manipulate it's innerHTML.

share|improve this answer

answered Apr 29 '09 at 15:31

BnWastelandBnWasteland

1,40811514

share|improve this answer

share|improve this answer

answered Apr 29 '09 at 15:31

BnWastelandBnWasteland

1,40811514

answered Apr 29 '09 at 15:31

BnWastelandBnWasteland

1,40811514

answered Apr 29 '09 at 15:31

BnWastelandBnWasteland

1,40811514

1,40811514

• 
  
  
  

  
  14
  

  
  
  
  
  
  

  
  
  This is not true. document.write does not add the content to the end of the page like it's an append. They are written in place.
  
  – Peter Bailey
  Apr 29 '09 at 15:35
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  @Peter Bailey, I know this is an old thread, but really this shouldn't be downvoted. whether it appends or not depends on whether document.write() runs inline while the page is loading. If it is called from a function after the page loads then the first document.write() will replace the entire body and subsequent calls will append to it.
  
  – Octopus
  Dec 17 '14 at 5:53
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  
  @Octopus Yes, but that's circumstantial. It appends in that scenario only because there's a fresh document. It's still not accurate to say "document.write() appends." Yes, it's an old answer and an old downvote, but I still stand by it.
  
  – Peter Bailey
  Dec 18 '14 at 14:03
  
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Its fine. I spoke imprecisely. I would've edited it long ago, but there is a much better answer above. I would point out though that "written in place" is equally imprecise.
  
  – BnWasteland
  Dec 18 '14 at 20:40
  

  
  
  
  

add a comment | 

• 
  
  
  

  
  14
  

  
  
  
  
  
  

  
  
  This is not true. document.write does not add the content to the end of the page like it's an append. They are written in place.
  
  – Peter Bailey
  Apr 29 '09 at 15:35
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  @Peter Bailey, I know this is an old thread, but really this shouldn't be downvoted. whether it appends or not depends on whether document.write() runs inline while the page is loading. If it is called from a function after the page loads then the first document.write() will replace the entire body and subsequent calls will append to it.
  
  – Octopus
  Dec 17 '14 at 5:53
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  
  @Octopus Yes, but that's circumstantial. It appends in that scenario only because there's a fresh document. It's still not accurate to say "document.write() appends." Yes, it's an old answer and an old downvote, but I still stand by it.
  
  – Peter Bailey
  Dec 18 '14 at 14:03
  
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Its fine. I spoke imprecisely. I would've edited it long ago, but there is a much better answer above. I would point out though that "written in place" is equally imprecise.
  
  – BnWasteland
  Dec 18 '14 at 20:40
  

  
  
  
  

14

14

This is not true. document.write does not add the content to the end of the page like it's an append. They are written in place.

– Peter Bailey
Apr 29 '09 at 15:35

This is not true. document.write does not add the content to the end of the page like it's an append. They are written in place.

– Peter Bailey
Apr 29 '09 at 15:35

1

1

@Peter Bailey, I know this is an old thread, but really this shouldn't be downvoted. whether it appends or not depends on whether document.write() runs inline while the page is loading. If it is called from a function after the page loads then the first document.write() will replace the entire body and subsequent calls will append to it.

– Octopus
Dec 17 '14 at 5:53

@Peter Bailey, I know this is an old thread, but really this shouldn't be downvoted. whether it appends or not depends on whether document.write() runs inline while the page is loading. If it is called from a function after the page loads then the first document.write() will replace the entire body and subsequent calls will append to it.

– Octopus
Dec 17 '14 at 5:53

2

2

@Octopus Yes, but that's circumstantial. It appends in that scenario only because there's a fresh document. It's still not accurate to say "document.write() appends." Yes, it's an old answer and an old downvote, but I still stand by it.

– Peter Bailey
Dec 18 '14 at 14:03

@Octopus Yes, but that's circumstantial. It appends in that scenario only because there's a fresh document. It's still not accurate to say "document.write() appends." Yes, it's an old answer and an old downvote, but I still stand by it.

– Peter Bailey
Dec 18 '14 at 14:03

Its fine. I spoke imprecisely. I would've edited it long ago, but there is a much better answer above. I would point out though that "written in place" is equally imprecise.

– BnWasteland
Dec 18 '14 at 20:40

Its fine. I spoke imprecisely. I would've edited it long ago, but there is a much better answer above. I would point out though that "written in place" is equally imprecise.

– BnWasteland
Dec 18 '14 at 20:40

add a comment | 

protected by Travis J Jan 2 '14 at 3:13

Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).



Would you like to answer one of these unanswered questions instead?

This page is only for reference, If you need detailed information, please check here