インラインスクリプトを避けるべき理由

最近、知識のある友人が私が立ち上げたウェブサイトを見て、「非常にクールなサイト、ソースコードのインラインスクリプトについての恥」などのコメントをしました。

私は間違いなく、インラインスクリプトが発生する場所を削除する立場にあります。私はそれが「悪いこと」であることを漠然と認識しています。私の質問は、インラインスクリプトの本当の問題は何ですか？重大なパフォーマンスの問題がありますか、それともほとんど良いスタイルの問題ですか？インラインスクリプティングの前線で即座にアクションを実行することを上司に正当化できますか？Webサイトにアクセスしてソースコードを覗いてみると、どのような要因が「うーん、ここでのプロフェッショナルな仕事」と言ってしまうでしょうか。

さて、その質問は執筆中に複数の質問に変わりました。しかし、基本的に、インラインスクリプティング-契約は何ですか？

インラインスクリプトの実際の問題は何ですか？重大なパフォーマンスの問題がありますか、それともほとんど良いスタイルの問題ですか？

利点はパフォーマンスに基づいているのではなく、ビューとコントローラーの分離に関係しています（マイケルが彼のコメントで指摘したように）。HTML / CSSファイルには、理想的にはプレゼンテーションのみを含める必要があり、スクリプトには別のファイルを使用する必要があります。これにより、あなた（そしてあなたの仲間）は視覚的側面と機能的側面の両方を読み、維持することが容易になります。

インラインスクリプティングの前線で即座にアクションを実行することを上司に正当化できますか？

いいえ、おそらくそうではありません。長い目で見ればお金を節約できると信じているとしても、純粋な保守作業の力を説得するのは非常に困難です。ただし、この場合、すべてを停止してインラインスクリプトを削除することはそれほど重要ではないと思います。代わりに、他の理由でエリアに取り組むときに、エリアを修正するための意識的な努力をするようにしてください。コードのリファクタリングは定期的に行う必要がありますが、一度に少しだけ行う必要があります。

Webサイトにアクセスしてソースコードを覗いてみると、どのような要因が「うーん、ここでのプロフェッショナルな仕事」と言ってしまうでしょうか。

プロではないことを教えてくれる一番の要因は、テーブルやdivの過剰使用です。どちらも使いすぎてはならない理由を説明する記事があります。

私は悪魔の擁護者になるつもりはありませんが、アマチュアの仕事とインラインJavaScriptの間に厳密な関係はありません。いくつかの最も有名なWebサイトのソースコードを見てみましょう。

• Google、
• ウィキペディア、
• マイクロソフト、
• アドビ、
• デル、
• IBM。

すべてのホームページはインラインJavaScriptを使用しています。これらの企業はすべて、アマチュアの人々を雇ってホームページを作成するということですか？

私は、HTML内にJavaScriptコードを配置できない開発者の1人です。私が取り組んでいるプロジェクト内でそれを行うことはありません（<a href="javascript:...">最初から目立たないJavaScriptが必要ではなかったプロジェクトのような呼び出しを除き、他の人のコードをリファクタリングするときは常にインラインJavaScriptを削除します。 ？わからない。

パフォーマンスに関しては、JavaScriptを別のファイルに入れると常にパフォーマンスが向上するとは限りません。通常、インラインJavaScriptはキャッシュできないため、帯域幅を浪費すると考えられます（静的なキャッシュ可能なHTMLを扱う場合を除く）。反対に、extern .jsファイルは一度だけロードされます。

実際には、これはもう1つの時期尚早な最適化に過ぎません。JavaScriptを外部化するとWebサイトが高速になると考えるかもしれませんが、まったく間違っている可能性もあります。

• ほとんどのユーザーが空のキャッシュを使用している場合はどうなりますか？
• extern .jsファイルでは、Webサイトが適切に設定されていない場合（通常は設定されていない場合）、ページリクエストごとにこのファイルにリクエストが行われると考えていますか？
• .jsファイルは本当にキャッシュされていますか（IISでは、それほど簡単ではないかもしれません）。

したがって、時期尚早に最適化する前に、訪問者に関する統計を収集し、インラインJavaScriptを使用した場合と使用しない場合のパフォーマンスを評価します。

次に、最後の議論があります。ソースでJavaScriptとHTMLを混合したので、あなたはうんざりします。しかし、両方を混ぜたと言ったのは誰ですか？ブラウザで使用されるソースコードは、常に作成したソースコードとは限りません。たとえば、ソースコードは圧縮、縮小、または複数のCSSまたはJSファイルが1つのファイルに結合される場合がありますが、これは実際に変数aに名前を付けたりb、c... a1などを指定したことを意味するものではありませんスペースや改行のない巨大なCSSファイル。同様に、コンパイル時または後でテンプレートを使用して、外部JavaScriptソースコードをHTMLに簡単に挿入できます。

結論として、作成するソースコードにJavaScriptとHTMLを混在させる場合は、将来のプロジェクトでJavaScriptとHTMLを使用しないことを検討する必要があります。ただし、ブラウザに送信されたソースコードにインラインJavaScriptが含まれている場合、それが常に悪いというわけではありません。

• 悪いかもしれません。
• 逆に、パフォーマンスを気にし、特定のテストを行い、クライアントがJavaScriptの一部をインライン化する方が高速であると判断した専門家によってWebサイトが作成されたことを示している可能性があります。
• または、まったく意味がない場合もあります。

そのため、「非常にクールなサイト、ソースコードのインラインスクリプティングに恥ずかしい」と言う人は、ブラウザに送信されたソースだけを見て、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の犠牲​​になるリスクを軽減しました。これは、インラインスクリプトの削除に投資するために経営陣に説得するより説得力のある議論かもしれません。

いくつかの理由があります。

1. インラインスクリプトを縮小することはできません（シンボルの縮小により短いバージョンに変換されます）。ブロードバンドでは問題ありませんが、低帯域幅のモバイルデバイス、またはグローバルデータローミングを使用しているユーザーを考慮してください。すべてのバイトがカウントされる場合があります。

2. インラインスクリプトは、ページ自体がキャッシュ可能でない限り、ブラウザでキャッシュできません（非常に鈍いページになります）。外部Javascriptファイルは、ページのコンテンツが毎回変更される場合でも、一度だけ取得する必要があります。低帯域幅接続のパフォーマンスに深刻な影響を与える可能性があります。

3. インラインスクリプトは、エラーに関連付けられた行番号に意味がないため、デバッグが困難です。

4. インラインスクリプトはアクセシビリティ（508 / WAI）の考慮事項を妨げると言われていますが、すべてのインラインスクリプトが問題を引き起こすわけではありません。スクリーンリーダーがスクリプトコンテンツを発表することになった場合、問題が発生します！（これは決して見られません）。

5. インラインスクリプトは、ページとは独立してテストできません。外部Javascriptファイルは、自動テストなどの独立したテストを実行できます。

6. インラインスクリプトは、懸念の分離が不十分になる可能性があります（他の多くの回答で説明されているように）。

スクリプトをインラインに含めないことを正当化する理由はいくつかあります。

• まず第一に、明白な答え-それはコードをよりクリーンで簡潔にし、理解しやすく、読みやすくします。

• より実用的な観点から、スクリプト/ CSS /などを再利用したいことがよくあります。ウェブサイト全体でこれらの部分をインライン化すると、小さな変更を行うたびにすべてのページを編集する必要があります。

• プロジェクトにSCMを使用する場合、さまざまなコンポーネントを適切に分離することで、関係するすべての人が変更とコミットを簡単に追跡できるようになります。

私の知る限り、パフォーマンスは問題になりません。Webサイトの性質、サーバーの仕様などに関連する多くの事項に依存します。たとえば、Webページが多くのjavascriptを使用している場合、ブラウザはスクリプトをキャッシュする可能性があります。コードは複数のファイルに分けられます。一方、いくつかのサーバーは、複数の小さなファイルよりも高速に単一の大きなファイルを処理する可能性があると言いたくなるでしょう。この場合、コードを分離しない方がパフォーマンスの面で優れていると言えます。

この領域での正式なテストについては知りませんが、誰かがそれらを行った可能性が非常に高いです。

最後に、私はそれが何よりも良い習慣の問題であり、読みやすさと組織の面での利点（具体的にはwrtポイント2）により、コードを個別のファイルに分離することがはるかに優れたオプションになると言います。

答えは、インラインコード（javascriptを想定）の使用方法によって異なります。

インラインコード、SSI（サーバー側インクルード）、jsファイル、cssファイルの組み合わせを使用して、必要な効果を作成し、onClickイベントのサーバーリターントリップを削減しました。

そのため、誰かが「インラインコード」の使用方法が完全に理解されていない場合、その使用方法が悪いと一言で言うと、誤解を招く恐れがあります。

そうは言っても、各ページにjsファイルを使用する代わりに同じコピーと貼り付けられたjavascriptコードがある場合、それは悪いことです。

各ページに独自のコピーがあり、CSSファイルを使用する代わりにCCSセクションを貼り付けている場合、それは悪いことです。

また、すべてのページにjsライブラリ全体を含めることは、特にそのページで関数が使用されていない場合には多くのオーバーヘッドになります。

ここではインラインJavaScriptを想定します。

コードを見ずに、それを確認するのは難しいです。彼は次の2つのことのいずれかを参照していたと思われます。

1. あなたは<script>ページ全体に散らばっています
2. JSはすべて外部ファイルではなく、ページのヘッダーにあります

1つ目は、設計上の不適切な決定です。スクリプトをソースファイル全体に分散させると、特定のスクリプトを検索する必要があるため、ページのメンテナンスが非常に難しくなります。すべてのコードを1か所に保管する方がはるかに良いです（ソースファイルの先頭に配置することをお勧めします）。

2番目については、必ずしも悪いことではありません。ページ固有のコードはそのページにある必要があります。ページ間でコードが重複している場合は、を使用してコードを外部化する必要があります<script src>。その後、新しいページを作成するときに、そのファイルを含めるだけで済み、そこで修正したバグを再検討する必要はありません。

Inline Javascriptを使用しない理由の1つ（ボタンのonclick = "DoThis（this）"でさえない）は、WebアプリケーションをChromeアプリにする場合です。そのため、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年のいずれであっても、将来の保守が容易になるようにコードを修正します。

「うーん、ここでのプロフェッショナルな仕事」と言わざるを得ない要因は何ですか？また、明らかにアマチュアっぽい仕事から何が反発するのでしょうか？

私は、「プロ」とは、仕事をするために大きな能力を持っていると考えるよりも、単に仕事をするためにお金を払う人として定義することを好む傾向があります。多くの専門家は確かに良い仕事をする能力がありますが、私は多くの場合、アマチュアが思いついたものではなく、他の専門家が行った恐ろしい仕事に恐怖に巻き込まれています。これまでの私の仕事の多くは、最初の開発者によって失敗した列車事故プロジェクトの救助に関係していたため、あなたの走行距離は異なる場合があります。

とはいえ、一般的にエンタープライズ品質のプログラミングを選ぶのは簡単です