私document.writeは悪い習慣と見なされていることを知っています。また、サードパーティベンダーに提出する理由のリストdocument.writeを、分析コードの実装で使用してはいけない理由についてまとめたいと思っています。

document.write以下に、主張する理由を悪い習慣として記載してください。

より深刻な問題のいくつか：

• document.write（以降DW）がXHTMLで機能しない

• DWはDOMを直接変更せず、それ以上の操作を防止 します（これの証拠を見つけようとしますが、状況に応じて）

• ページの読み込みが完了した後に実行されたDWは、ページを上書きするか、新しいページを書き込むか、機能しません

• DWは遭遇した場所で実行されます：指定されたノードポイントで注入できません

• DWは、DOMが概念的に機能する方法ではなく、バグを作成する簡単な方法であるシリアル化されたテキストを効果的に書き込んでいます（.innerHTMLにも同じ問題があります）

安全でDOMフレンドリーなDOM操作メソッドを使用する方がはるかに良い

実際にはdocument.write、それ自体には何の問題もありません。問題は、悪用しやすいことです。ひどく、さえ。

ベンダーが分析コード（Google Analyticsなど）を提供するという点では、実際にそのようなスニペットを配布するのが最も簡単な方法です。

1. スクリプトを小さく保ちます
2. すでに確立されているonloadイベントをオーバーライドしたり、onloadイベントを安全に追加するために必要な抽象化を含めたりする必要はありません。
3. 非常に互換性があります

ドキュメントが読み込まれた後で使用しない限り、私の考えでdocument.writeは本質的に悪ではありません。

のもう1つの正当な使用法はdocument.write、HTML5ボイラープレートindex.htmlの例から来ています。

<!-- 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>

json2.js JSON解析/文字列化ポリフィルを使用するための同じ手法も見ました（IE7以下で必要）。

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

それはあなたのページをブロックすることができます

document.writeページの読み込み中にのみ機能します。ページの読み込みが完了した後に呼び出すと、ページ全体が上書きされます。

これは事実上、インラインスクリプトブロックから呼び出す必要があることを意味します。これにより、ブラウザーが後続のページの一部を処理できなくなります。スクリプトと画像は、書き込みブロックが完了するまでダウンロードされません。

プロ：

• これは、外部（ホスト/ドメインへの）スクリプトからインラインコンテンツを埋め込む最も簡単な方法です。
• フレーム/ iframe内のコンテンツ全体を上書きできます。より最近のAjax手法が広く利用できるようになるまで（1998-2002）、私はこの手法をメニュー/ナビゲーションの一部によく使用していました。

短所：

• このスクリプトは、上記の外部スクリプトが読み込まれるまで一時停止するようにレンダリングエンジンをシリアル化します。これは、内部スクリプトよりもはるかに時間がかかる可能性があります。
• 通常は、スクリプトがコンテンツ内に配置されるように使用されます。これは、不正な形式と見なされます。

ここに私の2ペンスの価値document.writeがあります。一般的に、重労働には使用しないでください。

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

私は最近、AJAXスライダーギャラリーを作成しようとしていることを発見しました。2つのネストされたdivを作成し、width/ heightおよびoverflow: hidden外部に適用しました<div> JS。これは、ブラウザでJSが無効になっている場合、divがフロートしてギャラリー内の画像に対応するようにするためです-いくつかの素晴らしい優雅な低下。

上記の記事と同様に、CSSのこのJSハイジャックは、ページが読み込まれるまで作動せず、divが読み込まれると瞬間的にフラッシュしました。そのため、ページが読み込まれるときに、CSSルールを記述するか、シートを含める必要がありました。

明らかに、これはXHTMLでは機能しませんが、XHTMLは死んだアヒルのように見える（そしてIEではタグスープとしてレンダリングされる）ため、DOCTYPEの選択を再評価する価値があるかもしれません...

それが最も明白な理由であるページ上のコンテンツを上書きしますが、私はそれを「悪い」とは言いません。

JavaScriptを使用してドキュメント全体を作成する場合を除き、これはあまり役に立ちません。その場合、document.writeで開始できます。

それでも、document.writeを使用するときにDOMを実際に利用しているわけではありません。テキストのblobをドキュメントにダンプしているだけなので、形式が悪いと思います。

（XHTMLページのような）XMLレンダリングを使用してページを分割します。

最適：一部のブラウザはHTMLレンダリングに戻り、すべてが正常に動作します。

可能性：一部のブラウザーは、XMLレンダリングモードでdocument.write（）関数を無効にします。

最悪：一部のブラウザでは、document.write（）関数を使用するたびにXMLエラーが発生します。

私の頭の上から：

1. document.writeページ読み込みまたは本文読み込みで使用する必要があります。したがって、スクリプトを他の時間に使用してページコンテンツを更新する場合、document.writeはほとんど役に立ちません。

2. 技術的にdocument.writeはHTMLページのみを更新し、XHTML / XMLは更新しません。IEはこの事実をかなり許容しているようですが、他のブラウザはそうではありません。

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

document.write場合によっては、Chromeがスクリプトを挿入することをブロックすることがあります。これが発生すると、コンソールに次の警告が表示されます。

パーサーをブロックするクロスオリジンスクリプト...は、document.writeを介して呼び出されます。デバイスのネットワーク接続が不十分な場合、これはブラウザによってブロックされる可能性があります。

参照：

• このdeveloper.google.comの記事では、さらに詳しく説明しています。
• https://www.chromestatus.com/feature/5718547946799104

ブラウザ違反

.writeパーサーがページのレンダリングを停止するため、ブラウザ違反と見なされます。パーサーは、ドキュメントが変更されているというメッセージを受け取ります。したがって、JSがプロセスを完了するまでブロックされます。この時点でのみ、パーサーが再開されます。

パフォーマンス

このような方法を採用する最大の結果は、パフォーマンスの低下です。ブラウザがページコンテンツをロードするのに時間がかかります。ロード時間への悪影響は、ドキュメントに何が書き込まれているかによって異なります。あなたが追加している場合、あなたは違いの多くを見ることはありません<p>JavaScriptライブラリへの50の参照の配列を渡すのとは対照的に、DOMにタグを（私が作業コードで確認した結果、11秒の遅延が発生しました）もちろん、これはハードウェアにも依存します）。

全体として、もしあなたがそれを助けることができるなら、この方法を回避するのが最善です。

詳細については、document.write（）に対する介入を参照してください。

Google-Chrome Dev ToolsのLighthouse Auditによる分析に基づいて、

接続が遅いユーザーの場合、動的に挿入される外部スクリプトdocument.write()により、ページの読み込みが数十秒遅れることがあります。

• document.write悪い習慣である単純な理由は、より良い代替案を見つけることができないシナリオを考え出すことができないことです。
• もう1つの理由は、オブジェクトではなく文字列を扱っているためです（非常に原始的です）。
• 文書に追加するだけです。
• たとえば、MVC（Model-View-Controller）パターンの美しさは何もありません。
• 動的コンテンツをajax + jQueryまたはangularJSで表示する方がはるかに強力です。

document.write（）（および.innerHTML）は、ソースコード文字列を評価するものと考えることができます。これは、多くのアプリケーションで非常に便利です。たとえば、あるソースからHTMLコードを文字列として取得する場合、それを「評価」するだけで便利です。

Lispのコンテキストでは、DOM操作はリスト構造の操作に似ています。たとえば、次のようにしてリスト（オレンジ）を作成します。

(cons 'orange '())

また、document.write（）は文字列を評価するようなものです。たとえば、次のようなソースコード文字列を評価してリストを作成します。

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

Lispには、リスト操作を使用してコードを作成する（「DOMスタイル」を使用してJS解析ツリーを作成するなど）非常に便利な機能もあります。つまり、「文字列スタイル」ではなく「DOMスタイル」を使用してリスト構造を構築し、そのコードを実行できます。たとえば、次のようにします。

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

シンプルなライブエディターなどのコーディングツールを実装する場合、たとえばdocument.write（）や.innerHTMLを使用して、文字列をすばやく評価する機能があると非常に便利です。Lispはこの意味で理想的ですが、JSでも非常に優れた機能を実行でき、多くの人々がhttp://jsbin.com/のようにそれを実行しています。

document.writeの欠点は、主に次の3つの要因に依存します。

a）実装

document.write（）は、コンテンツが必要になったときに画面にコンテンツを書き込むために主に使用されます。つまり、JavaScriptファイル内、またはHTMLファイル内のスクリプトタグ内のどこでも発生します。このようなHTMLファイル内のどこかにスクリプトタグが配置されているため、Webページ内のHTMLと絡み合うスクリプトブロック内にdocument.write（）ステートメントを含めることはお勧めできません。

b）レンダリング

適切に設計されたコードは一般に、動的に生成されたコンテンツを取得してメモリに格納し、最終的に画面に吐き出される前にコードを通過しながら操作を続けます。したがって、前のセクションの最後のポイントを繰り返すと、コンテンツをインプレースでレンダリングすると、依存する可能性のある他のコンテンツよりも速くレンダリングされる可能性がありますが、処理のためにコンテンツをレンダリングする必要がある他のコードでは利用できない場合があります。このジレンマを解決するには、document.write（）を削除して、正しい方法で実装する必要があります。

c）不可能な操作

いったん書かれると、それで終わりです。DOMを利用しないと操作に戻ることはできません。

document.writeの使用は悪い習慣だとはまったく思いません。簡単に言えば、それは経験の浅い人にとっては高電圧のようなものです。使い方を間違えると炊き上がります。この方法や他の危険な方法を少なくとも一度は使用したことがある開発者は多く、実際に失敗を掘り下げることはありません。代わりに、何かがうまくいかない場合、彼らは救済し、より安全なものを使用します。それらは「悪い習慣」と見なされるものについてそのような発言をする人です。

それは、ハードドライブをフォーマットするようなもので、ほんの数個のファイルを削除する必要があるときに、「ドライブのフォーマットは悪い習慣です」と言います。

最大の問題は、document.writeで記述された要素がページの要素の最後に追加されることだと思います。最新のページレイアウトとAJAXでこれが望ましい効果になることはめったにありません。（DOMの要素は一時的なものであり、スクリプトを実行するとその動作に影響を与える可能性があることに注意してください）。

ページにプレースホルダー要素を設定してから、innerHTMLを操作する方がはるかに優れています。