それで、人々ができることは何が彼らのウェブサイトをより良くすることです。それに答えるために、時間をさかのぼってみましょう…
年は1998年で、Webは増加しています。 WWWのアーキテクチャの高レベルの概要を示すために、Tim Berners-Lee -はい、Tim Berners-Leeは「50,000フィートからのWebアーキテクチャ」と呼ばれる論文を公開しています。このレポートでは、コンテンツネゴシエーション、セマンティックWeb、HTML、CSS、Cool URI（変更されない）など、多くのことをカバーしています。
この記事では、バーナーズリーは非常に早い段階でいくつかのデザイン原則にも注目しています。これらの原則の1つは、「最小の力のルール」です。
最小の力のルールは次のようになります：
コンピューターシステムを設計するとき、多くの場合、情報を公開するために、制約を表現するため、または何らかの問題を解決するために、多かれ少なかれ強力な言語を使用することの選択に直面することがよくあります。 […]「最小の力のルール」は、特定の目的に適した最も強力な言語を選択することを示唆しています。
フロントエンドのためにウェブ上で利用できる3つの主要言語があります。
内容を意味的に説明します
プレゼンテーションとレイアウトを制御します
対話性と行動を追加します
最小の力のルールは、CSSに頼る前に、HTMLを使用して可能な限り試して実行することを示唆しています。 CSSで十分でなくなったら、JavaScriptをつかみますが、実際にしなければならない場合のみです。
Derek Featherstoneがうまく言えば：
Webフロントエンドスタック（HTML、CSS、JS、およびARIA）では、スタックのより単純なソリューションの低いソリューションで問題を解決できる場合は、必要です。それは壊れやすくなく、より巧妙で、ただ機能します。
？ホールドアップ：これは、マークアップでフォントサイズと色を設定する必要があるという意味ではありません。これは、Webの「昔の」時代に行ったことです。適切な事例：バーナーズリーの作品で取り上げられているルールの1つは、形と内容の分離です。
Berners-Leeがその記事を公開してからほぼ25年が経ちました。しかし、どういうわけか、彼が送ったメッセージは通り抜けず、多くの開発者（すべてではありませんが）はそれを知らない。この状況をとると、Devaultはそれほど前に遭遇しました：
私のブラウザは、過去28年間HTMLフォームを提出することに完全に能力がありましたが、ある理由で、一部の開発者はJavaScriptのフォームを再現することを決めました。
悲しいことに、これは孤立したケースではなく、むしろおなじみの現象です。頻繁に、私は賢くなったり、車輪を再発明しようとするウェブサイトや図書館を見ます。そうするために、彼らは彼らが目指していたものの正反対を達成します。これらのウェブサイトは、機能性が低く、アクセスしやすく、さらに悪いことに、特定の条件下ではまったく機能しません。
フォームは馴染みのある例かもしれませんが、最小の力のルールを適用することでより良い結果が得られる場合、より多くの状況があります。
これらすべての例では、いくつかの機能を上から下層に移動できます。バーナーズリーは私たちを誇りに思うでしょう。
Webスタックで低いテクノロジーを選択することで、Webプラットフォームのコアに近いものであるため、障害に対する弾力性が組み込まれているという利点も得られます。
JavaScriptは失敗にひどいです。プロセスで読み込まれたり、マングルされたりするスクリプト、または関数に対する1つの間違った引数があり、アプリ全体が機能しなくなる可能性があります。 「未定義のプロパティxを読むことができない」のようなエラーメッセージがあなたに馴染みのあるように聞こえる場合、あなたは私が話していることを知っています。
一方、CSSは失敗するのに非常に優れています。スタイルシートの1つに構文エラーがある場合でも、残りのCSSは機能します。 HTMLでも同じです。これらは寛容な言語です。
なぜ最小の力のルールを使用する必要があるのか疑問に思うなら、ジェレミーキースは彼の記事「評価テクノロジー」に答えをもたらします。
「どれだけうまく機能しますか？」と尋ねる傾向がありますが、本当に尋ねるべきは、「どれだけうまく失敗しますか？」です。
ジェレミー・キース
最小の力のルールから利益を得ることができる有名なウェブサイトは、NikeのWebサイトです。 JavaScriptが無効になっているサイトにアクセスすると、画像が表示されず、靴を注文することもできません。
JavaScriptへのこの過度の依存は、これらすべての壊れた機能をフロントエンドスタックの低いテクノロジーで構築できるため、必要ありません。
☝️なぜ誰かがJavaScriptを無効にしてWebを閲覧するのか疑問に思っているなら、それは多くの場合、彼らの選択ではなく、干渉する外部要因です。 「誰もがJavaScriptを持っているよね？」を参照してください。トピックについての良い説明のために。
このカテゴリのさらに悪い犯罪者は、InstagramやTwitterなどの有名なサイトです。 JavaScriptがなければ、これらのWebサイトはまったく機能しません。彼らはあなたに警告を与えるか、単に空白のままです。 JavaScriptはいつからテキストと画像をWebに表示する必要がありますか？
この孤立したナイキの例ほど悪い必要はありません。 JavaScriptが失敗したときに機能することを拒否するコンポーネントが小さい場合があります。例としてタブ付きインターフェイスを取ります。あなたは多くを見つけることができますがこの機能を提供するJavaScriptライブラリであるキッカーは、HTML、CSS、およびARIA自体がすでにあなたを非常に遠くに導くことができるため、そのためにJavaScriptを必要としないということです。
これらのベースレイヤーを配置したら、JavaScriptを使用してエクスペリエンスをさらに改善します。 JavaScriptを要件ではなく強化と考えてください。
同じことが、利用可能な場合と利用できない可能性のある特定のCSS機能にも当てはまります。基本的なスタイリングを提供し、@supportsを使用して検出可能な機能を使用できる場合、既に持っている結果を強化します。
このアプローチはプログレッシブエンハンスメントとして知られています。機能が利用可能になるにつれて機能を追加し、エクスペリエンスが進む限り結果を改善しますが、特徴がこれらの余分な繁栄なしでは機能しないほどではありません。
また、特定の新機能をまだサポートしていないブラウザの場合、その機能をブラウザに提供するポリフィルを試してみることができます。
Webの初期の頃から、Webプラットフォームが時間の経過とともに多くの新機能を獲得するのを見てきました。新しいHTML要素が定義され、JavaScript（言語）が成熟し、CSSはレイアウトの構築、要素のアニメなどの多くの強力な新機能を獲得しました。
数年前に不可能であり、フラッシュなどの外部テクノロジーに依存することによってのみ行うことができたものは、ブラウザ自体に組み込まれています。
古典的な例は、jQueryが導入した機能です。 10年以上前、jQueryはプロジェクトに初めて立ち寄った最初のものでした。今日、Webプラットフォームが追いついており、document.queryselectorall（）、element.classlistなどが組み込まれているため、もはやそうではありません。 Jqueryはポリフィルがポリフィルと呼ばれる前にポリフィルであったと言えます。
jQueryは馴染みのある例かもしれませんが、Webが追いついた他の多くの状況があります。
ここでの中心的なテーマは、これらの機能がポリフィルや外部ライブラリに依存しなくなったが、Webスタックのコアに近づいたことです。ウェブが追いつきます。
これらの新しいAPIの一部はかなり抽象的ですが、コードに接続できるライブラリがあります。例は、開発者に優しいAxios互換APIを露出させながら、フードの下でフェッチを使用するRedaxiosです。これらの利便性の方法が最終的にWebプラットフォームに流れ込んでも、私は驚かないでしょう。
ほぼ25年前にバーナーズリーが書いたものは、時の試練に耐えています。開発者、そのメッセージを尊重するのは私たち次第です。 Webプラットフォームが私たちに与えてくれるものを受け入れることで、それと戦おうとするのではなく、より良いWebサイトを構築できます。
シンプルにしてください。最小の力のルールを適用します。プログレッシブエンハンスメントを念頭に置いて構築します。
HTML、CSS、およびJavaScript - その順序で。
以上がプラットフォームを受け入れますの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
