インラインスクリプティングを避ける必要があるのはなぜですか？
知識豊富な友人が最近立ち上げを手伝ったWebサイトを見て、「とてもクールなサイト、ソースコード内のインラインスクリプトについて恥ずかしい」などとコメントしました。
私は間違いなく、インラインスクリプトが発生する箇所を削除する立場にあります。 「悪いこと」だと漠然と気づいています。私の質問は、インラインスクリプトの実際の問題は何ですか？重大なパフォーマンスの問題はありますか、それとも主にスタイルの問題だけですか？サイトにもっと明らかな影響を与える可能性のある他に取り組むべきことがあるときに、インラインスクリプティングフロントですぐにアクションを上司に正当化できますか？あなたがウェブサイトにアクセスしてソースコードをのぞいてみた場合、どのような要因で「うーん、プロの仕事はここにある」と言われるでしょうか。
さて、その質問は書面で複数の質問に変わりました。しかし、基本的に、インラインスクリプト-何が問題なのでしょうか。
インラインスクリプトの実際の問題は何ですか？重大なパフォーマンスの問題はありますか、それとも主にスタイルの問題だけですか？
利点はパフォーマンスに基づくものではなく、（Michaelがコメントで指摘したように）ビューとコントローラーの分離に関係しています。 HTML/CSSファイルには、理想的にはプレゼンテーションのみを含め、スクリプトには別のファイルを使用する必要があります。これにより、あなた（およびあなたの同僚）は、視覚的側面と機能的側面の両方を読み、維持することが容易になります。
サイトにもっと明らかな影響を与える可能性のある他に取り組むべきことがあるときに、インラインスクリプティングフロントですぐにアクションを上司に正当化できますか？
いいえ、おそらく違います。たとえ長期的に見ればコストを節約できると信じていても、純粋なメンテナンス作業であるパワーを納得させるのは非常に困難です。ただし、この場合、すべてを停止してインラインスクリプトを削除する必要があるほど重要ではないと思います。代わりに、他の理由で作業する場合は、領域を修正するための意識的な努力を払うようにしてください。コードのリファクタリングは、定期的に行うべきですが、一度に行うのはほんの少しです。
あなたがウェブサイトにアクセスしてソースコードをのぞいてみた場合、どのような要因で「うーん、プロの仕事はここにある」と言われるでしょうか。
それが専門家ではないことを教えてくれる最大の要因は、テーブルやdivの多用です。これが 記事 で、どちらも使いすぎてはならない理由を説明しています。
私は悪魔の支持者になるつもりはありませんが、素人の仕事とインラインJavaScriptの間に厳密な関係はありません。最も有名ないくつかのウェブサイトのソースコードを見てみましょう：
- Google、
- ウィキペディア、
- マイクロソフト、
- アドビ、
- デル、
- IBM。
ホームページはすべてインラインJavaScriptを使用しています。 それらすべての会社がホームページを作成するために素人っぽい人を雇うということですか？
私はJavaScriptコードをHTML内に配置できない開発者の1人です。自分が取り組んでいるプロジェクトの中でそれを行うことはありません（おそらく、最初から目立たないJavaScriptが要件ではなかったプロジェクトの<a href="javascript:...">のようないくつかの呼び出しを除き、誰かのコードをリファクタリングするときは常にインラインJavaScriptを削除します。しかし、努力する価値はありますか？.
パフォーマンスに関しては、JavaScriptを別のファイルに配置すると、必ずしもパフォーマンスが向上するとは限りません。 通常、インラインJavaScriptはキャッシュできないため、インラインJavaScriptが帯域幅を浪費することを考えたくなります（静的なキャッシュ可能なHTMLを扱う場合を除く）。反対に、extern .jsファイルは一度だけロードされます。
実際には、これは別の時期尚早の最適化です。JavaScriptの外部化によってWebサイトが高速化されると考えているかもしれませんが、まったく間違っている可能性もあります。
- ほとんどのユーザーが空のキャッシュを持っている場合はどうなりますか？
- Extern .jsファイルを使用して、Webサイトが適切に構成されていない場合（通常、構成されていない場合）、ページリクエストごとにこのファイルに対してリクエストが行われると考えましたか？
- .jsファイルは本当にキャッシュされていますか（IISでは、それほど簡単ではない場合があります）？
そのため、時期尚早に最適化する前に、訪問者に関する統計を収集し、インラインJavaScriptを使用した場合と使用しない場合のパフォーマンスを評価してください。
次に、最後の引数が出てきます。ソースにJavaScriptとHTMLを混在させているので、やっかいです。しかし、両方を混ぜたと誰が言ったのですか？ ブラウザで使用されるソースコードは、必ずしもユーザーが記述したソースコードであるとは限りません。たとえば、ソースコードは圧縮、縮小、または複数のCSSまたはJSファイルは1つのファイルに結合できますが、これは実際に変数にa、b、c ... a1、という名前を付けたという意味ではありませんなど、またはスペースや改行なしで巨大なCSSファイルを書いたこと。同様に、コンパイル時に、または後でテンプレートを使用して、外部JavaScriptソースコードをHTMLに簡単に挿入できます。
結論として、作成するソースコードにJavaScriptとHTMLを混在させる場合は、将来のプロジェクトでそれを行わないことを検討する必要があります。しかし、ブラウザーに送信されたソースコードにインラインJavaScriptが含まれている場合、それが常に悪いことを意味するわけではありません。
- 悪いかもしれません。
- 反対に、このWebサイトは、パフォーマンスを重視し、特定のテストを行い、JavaScriptの一部をインライン化する方がクライアントにとって高速であると判断した専門家によって作成されたという兆候かもしれません。
- またはそれはまったく何も意味しないかもしれません。
そのため、Webサイトの作成方法について何も知らずに、ブラウザに送信されたソースだけを見て、「非常にクールなサイト、ソースコード内のインラインスクリプトについて恥ずかしい」と言った人をむしろ恥じてください。
一般に、HTMLとJSを分離しておくことをお勧めします。 HTMLはビュー用、JSはアプリケーションロジック用です。しかし、私の経験では、htmlとjavascriptを（純粋さのために）極端に分離しても、保守性は向上しません。実際には、保守性が低下する可能性があります。
たとえば、次のパターン（ASP.netから借用）をイベントハンドラーの設定に使用することがあります。
<input type="button" id="yourId" onclick="clickYourId()" />
または
<input type="button" id="yourId" onclick="clickYourId(this)" />
イベントが発生する原因は何も謎ではありません。その理由は、6か月後、要素を（たとえば、Chromeで）検査し、トリガーされたjavascriptイベントをすぐに確認できるためです。
一方、他人のコード（10万行）を読んでいて、JavaScriptイベントを発生させる魔法の要素に遭遇したとします。
<input id="yourId" />
これが呼び出しているjavascriptメソッドを簡単に教えてください。 Chromeでこれが簡単になりましたが、イベントがIDにバインドされているか、コンテナの最初の子にバインドされている可能性があります。イベントが親オブジェクトにアタッチされている可能性があります。誰が知っていますか？それを見つける幸運:)
また、JavaScriptをデザイナーから完全に隠すと、実際に更新時にJavaScriptが破壊される可能性が高くなる可能性があると私は主張します。誰かが魔法のようにアクティブな要素のコードを編集する場合、これがページ上のアクティブな要素であることを彼らに知らせる、コード内のどのような指示がありますか？
要するに、ベストプラクティスはHTMLとJavaScriptを分離することです。しかし、経験則を極端に実行すると逆効果になることもあります。私は中道アプローチを主張します。大量のインラインjsを避けます。インラインを使用する場合、関数のシグネチャは次のように非常にシンプルでなければなりません。
1. emptyFunction()
2. doCallWithThis(this)
3. atTheExtremOnlyPassOneNumber(2)
ここで欠けている引数の1つは、 クロスサイトスクリプティング 攻撃に対する保護が強化される可能性です。
コンテンツセキュリティポリシー を使用して、最新のブラウザーでインラインJavaScriptの実行を無効にすることができます。これにより、サイトがXSSの犠牲になるリスクが軽減されました。これは、インラインスクリプトの削除に投資することを経営陣に与えるより説得力のある議論かもしれません。
ここにいくつかの理由があります。
インラインスクリプトを縮小することはできません（シンボル削減により、より短いバージョンに変換されます）。ブロードバンドの問題ではありませんが、低帯域幅のモバイルデバイス、またはグローバルデータローミングを使用しているユーザーを考慮してください。すべてのバイトがカウントされる場合があります。
インラインスクリプトは、ページ自体がキャッシュ可能でない場合（非常に鈍いページになる）でない限り、ブラウザーでキャッシュできません。ページコンテンツが毎回変更される場合でも、外部Javascriptファイルを取得する必要があるのは1回だけです。低帯域幅接続のパフォーマンスに深刻な影響を与える可能性があります。
エラーに関連付けられている行番号は意味がないため、インラインスクリプトのデバッグは困難です。
インラインスクリプトは、アクセシビリティ（508/WAI）の考慮事項を妨げると評判ですが、すべてのインラインスクリプトが問題を引き起こすわけではありません。スクリーンリーダーがスクリプトの内容を発表することになった場合、問題があります！ （これが起こったことを見たことはありません）。
インラインスクリプトは、そのページから独立してテストすることはできません。外部Javascriptファイルは、自動テストを含む独立したテストを通じて実行できます。
インラインスクリプトは、懸念事項の分離が不十分になる可能性があります（他の多くの回答で説明されているとおり）。
スクリプトをインラインに含めないことを正当化する理由はいくつかあります。
まず第一に、明白な答えです。これにより、コードがより簡潔で簡潔になり、理解と読み取りが容易になります。
より実用的な観点から、スクリプト/ CSS /その他を再利用したい場合がよくあります。 Webサイト全体で、これらの部分をインライン化することは、小さな変更を行うたびにすべてのページを編集する必要があることを意味します。
プロジェクトにSCMを使用する場合、さまざまなコンポーネントを適切に分離すると、関係者全員が変更とコミットを追跡しやすくなります。
私の知る限り、パフォーマンスは問題になりません。それはあなたのウェブサイトの性質、サーバーのスペックなどに関連する多くの事柄に依存します。例えば、あなたのウェブページが多くのJavaScriptを使用している場合、あなたのブラウザはスクリプトをキャッシュするかもしれません。コードは複数のファイルに分かれています。一方、一部のサーバーは単一の大きなファイルを複数の小さなファイルよりも高速に処理する可能性があると言いたくなります。この場合、コードを分離しない方がパフォーマンスが向上すると主張できます。
この分野の正式なテストについては知りませんが、誰かがそれを行った可能性は非常に高いです。
結局のところ、それは何よりも優れた慣行の問題であり、可読性と構成（特にw.r.t.ポイント2）の点での利点により、個別のファイルでのコードの分離がはるかに優れたオプションになると言えます。
答えは、インラインコード（JavaScriptを想定）の使用方法によって異なります。
インラインコード、SSI（サーバー側インクルード）、jsファイル、cssファイルの組み合わせを使用して、必要な効果を作成し、onClickイベントのサーバーリターントリップを削減しました。
そのため、「インラインコード」の使用方法が完全に理解されていない場合、その使用が悪いことを誰かが全面的に表明することは誤解を招く可能性があります。
そうは言っても、jsファイルを使用する代わりに、各ページに同じコピーと貼り付けられたJavaScriptコードがある場合、私はそれが悪いと言います。
各ページに独自のコピーがあり、CSSファイルを使用する代わりにCCSセクションを貼り付けている場合、それは悪いことです。
特にそのページで関数が使用されていない場合は、すべてのページにjsライブラリ全体を含めることもオーバーヘッドが大きくなります。
ここではインラインJavaScriptを想定します。
コードを見ないと、確信が持てません。私は彼が次の2つのうちのどちらかについて言及していると思います。
- ページ全体に
<script>s散在しています - JSはすべて外部ファイルではなく、ページのヘッダーにあります
1つ目は設計上の決定の誤りです。スクリプトをソースファイル全体に分散させると、特定のスクリプトを検索する必要があるため、ページmuchの管理が難しくなります。すべてのコードを1か所に保持する方がはるかに優れています（ソースファイルの先頭を優先します）。
2番目については、それは必ずしも悪いことではありません。ページ固有のコードをそのページに含める必要があります。ページ間でコードが重複している場合は、<script src>を使用してコードを外部化する必要があります。そうすれば、新しいページを作成するときに、そのファイルを含めるだけで済みます。そこで修正したバグを再検討する必要はありません。
InLine Javascriptを使用しない理由の1つ（ボタンのonclick = "DoThis（this）"も使用しない）は、WebアプリケーションをChrome Appにする場合）です。したがって、 WebアプリをネイティブChromeアプリに移植するには、まずインラインJavaScriptを含めないでください。これは、次の場合にWebアプリから（強制的に）変更する必要があるものの最初に説明されていますあなたはそれを「Chrome-etize」するつもりです。
インラインスクリプトの実際の問題は何ですか？
インラインスクリプトは不適切であり、コードを読みにくくするため、避ける必要があります。
読みにくいコードは保守が困難です。簡単に読んで何が起こっているのかを理解できない場合、バグを簡単に見つけることができません。メンテナンスが難しい場合は、後で問題が発生したときに時間を無駄にしてしまいます。
通常、困難なのは、ネストされたエンコーディングです。コードの次の行に問題があります。それを見つけられますか？
<a onclick='alert("What\'s going wrong here?")'>Alert!</a>
理想的には、コードは、間違いがあったときに簡単に見つけられるように書かれています。 Joel Spolskyは、2005年にこの点を強調する優れた記事を書きました 。コードの例では、年齢が9歳であることを示しているため、大幅な改善が見られますが、根本的な概念は依然として強力です。つまり、バグを簡単に見つけられるようにコードを記述します。
重大なパフォーマンスの問題はありますか、それとも主にスタイルの問題だけですか？
インラインスクリプトは繰り返しにつながります。 1行のコードを変更して100ページに影響を与える代わりに、100ページを個別に変更する必要がある場合があります。これと読みやすさの悪さはパフォーマンスに重大な影響を及ぼしますメンテナの。プログラミング時間は、ほとんどのコード最適化から数ミリ秒よりも速くビジネスの収益に影響する実際のコストを伴います。確かにボトルネックを最適化することは重要ですが、この場合、コードのパフォーマンスの違いは無視できます。
サイトにもっと明らかな影響を与える可能性のある他に取り組むべきことがあるときに、インラインスクリプティングフロントですぐにアクションを上司に正当化できますか？
いいえ。それが愚かで機能する場合、それは愚かではありません。
これに対するプログラミングの帰結は次のとおりです。それが愚かなコードであり、それが機能する場合、それは愚かなコードではありません。壊れていないものを修正しようとする前に、実際の問題に焦点を当てます。インラインコードが最終的に更新を必要とするとき、それが6時間、6か月、または6年であるかどうかに関係なく、将来のメンテナンスが容易になるようにコードを修正します。
「うーん、プロの仕事はここだ」と言う要因は何ですか？
私は、「職業的」とは、給与の支払いにおいて重要な能力を持っていると想定するのではなく、仕事を遂行するために給料を支払われる人と定義する方がよい傾向があります。多くの専門家は確かに良い仕事をすることができますが、多くの場合、アマチュアが思いついたものではなく、他の専門家が行った恐ろしい仕事に恐怖で反動します。これまでの私の仕事の多くは、初期の開発者によって台無しにされた難破船のプロジェクトを救済することを含んでいるため、マイレージは異なる場合があります。