邪魔なJavaScriptは大丈夫ですか？

WebサイトのすべてのユーザーがJavaScriptを有効にする必要がある場合、邪魔なJavaScriptを使用しても問題ないかと考えていました。

私はすべてプログレッシブ拡張に賛成ですが、古いブラウザやJavaScriptが無効になっている場合に、高度なWebアプリケーションがユーザーを戸口で跳ね返すポイントは何ですか？

私たちは非常にスリムなターゲットユーザーを抱えており、必要なブラウザーとプラグイン/機能をターゲットユーザーに伝えることができます。だから私の質問は、その場合JSとHTMLを混ぜても大丈夫ですか？onclick属性の使用と同様です。

これは設計上の決定ではなく、ビジネス上の決定です。

JavaScript（またはFlash、Silverlight）なしで機能するWebサイトのバージョンを提供するには、コストがかかります。事業は、収益/訪問者の損失はそれだけの価値があるかどうかを決定する必要があります。

したがって、このバージョンを作成するのに10,000ドルかかる場合（数値は大きいかもしれませんが、この例にのみあります）、サイトの存続期間全体にかかる費用を回収しますか？そうでない場合は、そのバージョンを提供しないでください。

ただし、このバージョンを作成するのに100ドルしかかからない場合、優雅な低下を提供することは理にかなっています。

JavaScript対応のブラウザーのみをターゲットにして、ユーザーがJavaScriptを有効にすることを期待するというビジネス上の決定を下したので、現在利用可能な機能をアプリケーションで利用することは完全に理にかなっています。（Stack Overflow自体と同じように）必要なのは、ユーザーがサイトを有効にしていないとサイトが正しく機能しないという警告が表示されることだけです。

まだ誰も育てていないもの…

Webサイトの99％は、JavaScriptをほとんどまたはまったく持たない特定の訪問者を歓迎します。その訪問者には、Googlebotという名前があります。

_{誰もが目の不自由な訪問者も気にする必要がある大きな理由…}

あなたが検索エンジンのトラフィックをまったく気にしない非常に少数の1人である場合、まあ、それはあなたの特権です—しかし、それは確かに一般的なルールにはなりません。

特定の内部環境向けに物事を書く人々は、IE6がまだ存在する大きな理由です。

考えてみて

JSのみのサイトを実行している場合（おそらく、この場合の「アプリケーション」がより適切な言葉です）、JSのいわゆる「無邪気さ」は、ケースの場合ほど問題ではありません。 JSバージョン。

ただし、控えめな方法で記述されたJavaScriptは、一般的に記述が簡単で（少なくとも私はこの方法で見つけることができます）、維持することができます。JSを壊さないHTMLレイアウトの変更を導入したり、HTMLを壊すことを心配せずにJSに変更を加えたりする方が簡単です。

あなたがウェブサイトを構築しているなら、私はJavaScriptを邪魔にならないようにします。ただし、何らかの形のアプリケーション（Googleドキュメントなど）を構築している場合、JavaScriptは非常に邪魔になります。

JavaScriptとHTML5は、必要に応じてアプリケーションを構築するのに最適ですが、実際にはビジネス上の選択です。

大多数のユーザー（私のユーザー、私はあなたのユーザーについて知りません）は、JavaScriptを使用可能にして有効にしています。それらのユーザーに優れたユーザーエクスペリエンスを提供しましょう。ただし、JavaScriptがなくても機能するバージョンのサイトを提供する必要があります。2つのバージョンを作成するのは面倒なことですが、それがWeb開発でのやり方です。（実際には、複数のバージョンを作成する必要があるかもしれません。3番目はサイトのモバイルバージョンかもしれません）。

あなたがしたくないのは、最も一般的な分母を設計することです。「まあ、JavaScriptを無効にしているユーザーもいるので、私たちのサイトを設計して、それらがうまく機能するようにします。 」これは、JavaScriptを使用しているユーザーの大多数に不利益をもたらすだけです。

onlick属性の使用について言及しました。ページナビゲーションにJavaScriptイベントハンドラーを使用することを計画していますか？

単一の理由でこれに反対することをお勧めします：それはミドルクリックを壊します。

通常のリンククリックの場合、JavaScriptが有効になっていると仮定すると、これらは機能的に同等です。

<a href="#" onclick="window.location = 'myPage.htm';">Click here</a>
<a href="myPage.htm">Click here</a>

最初の例を中央クリックしようとすると、myPage.htmではなく空白のページが表示されます。

この例とは別に、ビジネスに意味がある場合は、邪魔なJavaScriptを使用しても問題ないと思います。インラインJavaScriptを書くのにかかる時間は少なくなりますが（必ずしも維持する必要はありません）、状況によっては段階的な拡張機能の喪失は重要ではない可能性があります。

邪魔なJavaScript は 10年前は大丈夫でした。あなたがアマチュアである場合、または使い捨てのプロトタイプを構築している場合、またはそれを必要とする状況（たとえば、レガシーコードまたはデータ駆動型コードへの依存など）があり、それがコストを節約する方法である場合も問題ありません。アルを修正するには多すぎる

ゼロから何かを構築する場合は、標準に従って、適切でクリーンで保守可能なコードを記述します。あなたが誇りに思う何かを書いてください、そしてあなたがしたハックジョブを理解していないので、貧しいシュマックがあなたに助けを求めたとき、あなたが1年後に病気になることはありません。Webデザイナーが面倒なHTMLやJavaScriptを使わずにCSSを簡単に入れ替えられるようにするものを書きます。

成長する余地があるようにアプリケーションをビルドし、開発者が参加して保守できるようにします。現在投資されている時間は、将来の時間を節約します。あなたの時間ではないにしても、誰かの時間を節約できます。

JavaScriptが別のコンテキストで再利用できることを確認してください。完全なウェブサイトの再設計は、それ自体、つまり再設計であり、既存のものを完全に再構築するのではなく、タフに構築されていないことを確認してください。

元の設計と同じ時間だけ再設計に費やす必要があるとしたら、どれほど恥ずかしいことでしょう。

経験から私を信じてください、控えめなJavaScriptは、あなたがいくつかの高価な間違いをすることを防ぎます。

了解しました。私が行うすべてのネクロでクリプトキーパーと呼んでください。しかし、これの真の価値が適切に理解されたとは感じていません。歴史的に、「無邪気なJavaScript」、つまりファイルにリンクされていないインラインHTMLイベントハンドラー属性とスクリプトタグを介してJSをHTMLから除外することは、以下の重要な要素であると主張されています。

• アクセシビリティの懸念
• SEO
• そして漸進的な強化

嘘！（まあ、今はそうなるでしょう）

問題の真実は、技術的に邪魔なJavaScriptを実行しても、上記の3つの項目を引き離すことができるということです。あなたがHTMLコンテンツを動的に構築していない限り、それはその日の大きなSEO禁止事項でした。

しかし、停止して考える...あなたについて！

実際、分離を維持することの大きな利点、主に最も売れ行きの悪い勝利は、常に開発者がそれから得る直接的な利益でした。必要に応じて、同じイベントの同じHTML要素に必要な数だけイベントハンドラーを配置できます。つまり、が付いたタグがclass="some_class"常に特定の動作を取得するだけでなく、id="bonus_behavior"div 内にあるときにボーナス動作も取得する場合、1つの許可されたイベントハンドラ内のロジックをいじって、そのために分岐する必要はありません。コンテキストに応じて、ハンドラーを追加することも追加しないこともできます。

読みやすい

別の利点は、読みやすさです。これは、ブラウザツールがIEの排他的なエラーメッセージで構成されていて[object]、IMOに問題があることを通知する場合、より重大な問題でしたが、それでもなお大きな問題です。ここではCSS、JSはそこにあり、HTMLはそれらとサーバーの両方が出会う場所です。これらすべてが1か所にまとめられているため、フック（ID、クラス、および階層）を利用して、すべてがHTMLへの接続に使用する抽象化のレイヤーを作成することは理にかなっています。

IMO、HTML、CSS、およびJSを分離しておくことができるほど、読むだけでなく、何が起こっているのかを変更して理解することも簡単になります。「dynamic_combo_box」をクラスとして持つ空のdivがあり、データを動的にロードする空想的な選択を行っていることは良い考えです。私はJSとCSSでそれを見つける方法についてリードを持っています。これらの懸念事項でクラスに遭遇した場合、それが何であるか、そしてHTMLでそれを見つける方法について良い考えを持っています。

だらしのないものにするのは簡単すぎる

そしてもちろん、読みやすさは保守性と密接に関連しています。関連するHTMLが存在するスクリプトタグにすべてをダンプすることで直接処理を行うだけの場合は、作業している別のページのHTMLにそのスクリプトをカットアンドペーストするだけで簡単になります。彼らは同様の機能を望んでいます。つまり、期待に反して動作が時間とともに問題となり、1つの必要な例外を処理するためにさらに無意味な分岐を追加する必要がある場合に、最終的に2つの面倒な類似点になる可能性があります別の人はしませんでした。

そのため、これらのHTMLフックに動作をリギングすることで、コードをスマートに再利用できます。別の実装の動作を分岐する必要がある場合は、同じ関数に移動してHTML階層で処理するか、データattで代替動作をトリガーします。これは、特定のタイプのUI要素がどのように機能するかを理解したいと考える人にとっては1つのストップショッピングです。今すぐ実行してください。これが保守性を実現するための最良の方法です。パニックであろうと無関心であろうと、あまり気にならなかった人のために行うのが最も簡単な「だ」のことをしてください。

しかし、2014年はどうですか？

現代の単一ページのアプリケーションでは、これらのステッカーのいくつかは、これまでのように独断的に動けなくなるべきではないかもしれませんが、私だけではないと私が思うとき、私を信じて私を信じてください。それは最終的に仕事を容易にするのでそれでそれで売られました。私は（いいと思いますが）たいていは良い方法で怠けています。アプリ全体の変更を取得するために1か所のみを変更する必要がある場合、1か所のみを確認してバグを特定する必要がある場合、そして何が何であるかを簡単に理解できる場合は、続行し、そのコードを再利用して非常によく似た処理を行う方法

それは、DBやデータレイヤーを分割するのが良いようなものです。それは結局、ボクサーの混血に10分を費やして翌朝の偏執的な匂いチェックを行うのではなく、前夜に5分すべてかけて洗濯をするような時間節約である理由です。

私にとって、それは私が常に控えめなJSだけでなく、スタイル/動作/コンテンツの分離を可能な限り重視する理由の主なポイントであるそれらの利己的な動機ですそれらの懸念を理解できるほど素晴らしく、クールで便利な方法で混乱させます。

誰もがSPAを実行していて、JSなしで実行している人々に注意を払う必要があることをビジネスに納得させようとしています（アクセシビリティは、おそらく、JS生成コンテンツで処理できるようになりました）。次世代のJS開発者はあまり気にしないようですこれについてはIMOですが、まだ勝利はあります。開発者がこのようなものを書いて保守しているのは、主にあなたのためです。そして、本当に、その勝利は常に最も強調されたポイントであるはずですが、それは最終的にあなたと製品に微調整/変更/デバッグが容易になるという幸運な事故によって利益をもたらすため、何らかの理由で決してそうではありませんでした。

それは大丈夫ですか？

ええ、そうですね。コンテストや何かのための使い捨ての使い捨てアプリで。しかし、私はそれを習慣にしていて、それを実際に行うのが難しくないという理由だけで、それでもそれを行います。

ターゲットの動作環境がわかっている場合、JavaScriptとjQueryのようなフレームワークは本当の天の恵みになる可能性があります。たとえば、SOEがJavascriptとIE8を備えているエンタープライズ環境では、集中的なクライアント側ブラウザアプリケーションを作成するのに安全ではありません。

正常なデグラデーションを簡単にすることは、控えめなJavaScriptを魅力的な選択肢にする多くの要因の1つにすぎません。私の意見では、それは最も重要なものではありません。

個人的な経験から、時間の経過とともに大きく進化する可能性のある大きなプロジェクトについて話している場合、控えめなスタイルを使用すると、アプリケーションの保守、デバッグ、リファクタリングが簡単になります。これが、すべての訪問者に対してJavaScriptの有効化を要求するサイトでも、目立たないスタイルを常に使用する最大の理由です。

一般に、匿名で利用可能で、検索エンジンによってインデックスが作成され、収益が広告によって生成される、従来の「Webサイト」を開発している場合は、適切な低下を提供する必要があります。この種のサイトは、アクセシビリティによって存続し、死んでしまうため、アクセシビリティを制限すると、大量のページビューが失われ、その結果、広告収入が失われます。

制限されたアクセス、通常はインデックスに登録できず、広告収入に基づかない「サイト」（Webアプリケーション）は、はるかに柔軟性が高くなります。それは、幅広いサポート、機能の深さ、開発コストの間の決定に帰着します。従来のアプリケーションを開発するようなものだと考えてください。どのプラットフォームをサポートしていて、最低限の仕様は何ですか？1つのプラットフォームと限られた仕様のみを対象とする場合は、潜在的な市場シェアを失うことを犠牲にして、開発とサポートのコストを抑えた優れた製品の提供に集中できます。

例：Google検索はWebサイトです。Googleドキュメントはウェブアプリケーションです。Google検索は飾り気がなく、JavaScript、CSS、画像などがなくてもまったく同じように機能します。テキストモードのブラウザでも、最新のGUIブラウザと同じように機能します。Googleドキュメントは、JavaScriptが無効になっていると機能せず、正常に機能しません。JavaScriptを有効にするための警告もありません。

私はほとんどのレイアウトとナビゲーションをCSSで処理することを好みます。はい、Lynxはそれをサポートしていない可能性がありますが、私が認識しているすべてのフル機能のブラウザーではオフにできません。次に、JavaScriptを使用して、より派手ではあるが必須ではないものを作成できます。この目的のために、Ruby on Railsも好きです。動的なページ更新が必要ない限り、サーバー側でJavaScriptが必要とすることの多くを実行できます。

質問の回答をさらに対象としています：必要なJavaScriptは好きではありませんが、ChrisFが指摘したように、必要なビジネスケースがあります。

JavaScriptは、クライアント側で配信されるあらゆる種類の動的コンテンツに関しては欠陥標準です。JSがない場合、おそらくSilverlightはありません。

次に、あなたはあなたの市場/聴衆について考える必要があります、あなたはprogrammers.stackexchcangeまたはbbc.co.uk/newsですか？非常に異なる聴衆。

多くのサイトでWebを見回して "邪魔なJavaScript"を見ることができるので、基本的な質問は答えられます。そうです、大丈夫です。多くの人気のあるサイトが、Googleでさえ、それを行います。

ただし、より重要なのは、ユーザーがJavaScriptを有効にする必要があると主張している場合でも、機能の優雅な低下です。そうでないと、非jsユーザーに適切なレベルのエクスペリエンスを提供する必要があります。