なぜウェブはそんなに複雑なのですか？

フロントエンドで今年の結果の議論は突然議論の主題になりました 。 私の意見を追加し、他の人の意見を聞いてうれしいです。

現代のウェブで何が起こっているのかを話すのは理にかなっているように思えますが、外部と内部から知覚されるものは完全に異なっています。 はい、「内部」にはいくつかのレベルがあります。 「再びレイアウトを複雑にする」という見方は、完全に正しいものであり、誤ってand落したものですが、「抽象化の構築を妨げない」という見方も効果がありません。

現代のウェブが複雑になりすぎていると誰かが不平を言うとき、この現代のウェブは彼がオンライン銀行や購入フォーム、ソーシャルネットワークでの個人的なやり取り、インスタントメッセンジャーのウェブ版で自分のお金を信頼していることを思い出したいたびに、クラウド内の個人ファイル。 そしておそらく、彼はこれらのシステムの開発プロセスを複雑で、難しいが、信頼でき、失敗しないことを本当に望んでいます。

画像ソース

現代のフロントエンドと彼の友人の下で、彼らは今では外から見えるよりもはるかに多くを理解しています。 これらは、古典的なWebサイトとSPA、電子上のアプリケーション、およびCordova、NativeScript、React Native、さらにはFlutter上のモバイルアプリケーションです。 これは、CDN、地理分散サービス、JS上のチャットボット、さらには機械学習ツールを備えた複雑なインフラストラクチャであり、 アセンブリやレイアウトの生成を最適化し ます 。

また、Web自体には、以前はデスクトップモードでのみ動作する可能性があった非常に複雑なソリューションが表示されます。 私自身、数年前にブラウザーで本格的なゲノムブラウザーの開発に触れました。パフォーマンスと60FPSを提供することに従事していました。これは十分に大きいが解決可能な問題でした。 5年前でさえ、ゲノムブラウザを強力なコンピューターにインストールすることはできないと誰も考えられなかったため、医師や研究者はタブレットや軽量のラップトップからでもゲノムを操作できました。

なんで？

現時点では、HTML + CSS + JSバンドルは、その機能だけでなく、その上に構築されたソリューションの数-CSSフレームワーク、ビジュアルコンポーネントのライブラリ、膨大な数のサービスへのインターフェース、およびSAASの面でも最も強力なインターフェースの1つです。 。 潜在的なオーディエンスとアクセシビリティの開発時間の効率という点では、Webテクノロジーはモバイルソリューションとデスクトップソリューションの両方を先取りしています。 そして今、それは3つの領域に分かれています：

• 部分的に動的なコンテンツ（ギャラリー、ポップアップなど）を持つ完全に静的なサイトとほぼ静的なサイトの開発
• サーバーフレームワーク（django、rails）での「クラシック」Webアプリケーションの開発
• Webクライアント開発

そして、それらはそれぞれ完全に異なる特異性を持っています。

JSの開発は本当に苦痛だったので、この痛みを解決するソリューションが登場し始めました。

それらを見ると、非常に興味深いことがわかります。まず、jQueryやCoffeeScriptなどのソリューションが登場し始め、言語の冗長性と冗長性が低減されました。 しかし、それらはすぐに消えていき、代わりにコードを可能な限り効率的に再利用し、エラーを静的に検出し、効果的な抽象化を構築し、シンプルでよく説明されたインターフェースの背後に個々の難易度を「隠す」ツールを導入しました。

GraphQLが登場しました。これは、RESTの記述、文書化、および保守の複雑さに関する問題を解決します。 TypeScriptとFlowが登場し、タイピング不足の問題を解決しました。 非同期操作、クラス、およびデータストリームを効果的に操作できる新しい言語エンティティが登場しました。 WebAssemblyが登場しました。これにより、他の言語のコードを再利用し、すばやく実行できます。

これらのソリューションはすべて同じことを目的としています。コードの再利用と「フラットな」チームを構築する可能性です。 他の人のコードを取得して使用を開始するために、問題を解決します。

これは、Webが大規模なチームでの作業に向けて発展していることを示す明確な証拠であり、「アダルト」ソリューションのプラットフォームになっています。

さらに発生した一連のイベントは、さらに明確な証拠になりました。ReactNative、NativeScript、Dart + Flutter、およびネイティブプラットフォームでコードを再利用するための他のソリューションが登場しました。 これは非常に重要なポイントです。Web上で他の言語を使用する機能がないため、企業は、すべての顧客に新しい機能を提供するための小さな開発コストと時間を削減できる「銀の弾丸」を求めてプロセスを微調整し始めました。 どのプロジェクトでも迅速であることが重要であり、高レベルの専門家がJSで効果的に作業する機会を求めて団結し始めました。

ちなみに、同じ理由で、テンプレートエンジンは部分的に停止し始めました：別のセマンティクスの使用は、JS（Angular、Vue）の小さな拡張子を持つ使い慣れたHTMLを使用するか、レイアウトを記述するための言語（React、Flutter）を使用するよりも効果が低いことが判明しました 拡張できない、開発者を新しい言語に導入する必要がある、プラットフォームが死ぬリスク、分散化により、HTML / DOMプラットフォームに可能な限り近づけようとするフレームワークテンプレーターを好むようになりました。

ただし、コードを効率的に記述することに加えて、コマンドを同期するための「係数」もあります。 この言語で超高速で作業できるが、同時に2人の開発者間で個々の機能を同期させるとひどい痛みが生じる場合は、ニッチのままである可​​能性が高いです。 したがって、多くの言語機能とソリューションは、同期の問題と問題がないことを減らすことを特に目的としています。 彼らはこの「係数」を減らします。これは、何人のジュニアが同時にミドルをコントロールできるか、そして何人のミドルがリード開発者によってコントロールできるかを示します。 このような機能の最新の例の中で、es6インポートは循環依存性の問題を部分的に解決しますが、開発者の記述方法に関係なく、 よりきれいにgitコードで期待通りの適切なマージを取得できます。 それは美しくあるべきではなく、うまく同期されるべきです。

その結果、わずか数年で、プラットフォームとしてのウェブが大企業や真面目なチームに引き継がれたため、大多数が「javascript疲労」を経験しました。 ちなみに、Chromiumに代表されるウェブ上のGoogleのほぼ独占の主な主張は、ウェブプラットフォームとJSの機能に必要なものを押し込めることです（ただし、これは通常、ほとんどの企業が必要とするものと一致します）。

その結果、一方では、どこでも再利用できるコードのための非常に楽しいプラットフォーム、大規模なフラットコマンドを使用できる構文が得られました。 しかし...

すべてが複雑になり、誰もが混乱しました

そして、誰も何をすべきか理解できませんでした。 実際、問題は何ですか？ これら3つの異なるカテゴリ。

• 部分的に動的なコンテンツを含む完全に静的なサイトとほぼ静的なサイトの開発：このタイプのアプリケーションは、エントリポイントとしてのHTML、最大ダウンロード速度、オプションのJSが特徴です。
• サーバーフレームワーク（django、rails）での「クラシック」Webアプリケーションの開発：これらのソリューションは現在、エントリポイントとしてHTMLを読み込むことを特徴としていますが、最大ダウンロード速度ではなく、コードの再利用、DRY、バックエンド統合に焦点を当てています。 JSコードは、フレームワーク（通知、フォーム、ターボリンクなど）によって部分的に生成されます。部分的には、自分で記述する必要があります
• クライアントWebアプリケーションの開発。 ここで予期しないことが起こります。エントリポイントではなくHTMLがアプリケーションマニフェストとレンダリングプラットフォームの両方になり、「エントリポイント」がJSになります。

エントリポイントが意味すること：これは特定のエンティティであり、その読み込みは製品ユーザーへの最小配信に等しくなります。 ユーザーが情報を表示する必要がある場合は、HTML + CSSが必要です。アプリケーションを実行する場合は、HTMLから実行されるJSが必要です。

そして、全員を完全に混乱させるために、4番目のカテゴリーが登場しました。

同型アプリケーション

Web開発の「同形」とは、通常、サーバーとクライアントの両方で機能するものを意味します。 このモードでは、react、angular、vue.jsのアプリケーションが動作します。たとえば、既製のフレームワークがあります-NextやNuxtなど。

両方のタスクはそれらに関連しています。Webアプリケーションは、できるだけ早く初期状態をユーザーに提供し、アプリケーションとして機能する必要があります。 つまり、HTMLとJSの両方を、コンテンツ用とアプリケーション用の2つのエントリポイントとして配信する必要があります。 これにより、2つの矛盾する段落が作成されます。一方では、配信されるデータの量が最小限である必要があり、他方ではコードの再利用が必要です。 JSの場合、これはWebpackチャンク、コード分割、動的コードのロード、JSに残されたテンプレートによって解決されますが、CSSはまだ残っています。 そして最も重要なのは、ユーザーに1バイト余分に配信しないことです。 そして、誰かがアイデアを思いついた：そのようなアプリケーションは本当に2つのエントリポイントを持っています。 これらは、2つの独立したエンティティとして処理できます。

これから、CSS-in-JSの概念が生まれました。静的コンテンツ用のCSSファイルの生成と、コンポーネントの横にあるスタイルの保存という2つの別個のプロセスに焦点を当てています。

JSに残されたすべて。

JSでは、スタイル、レイアウト、実際のコードを見つけることができます。

今ではすべてがjsにあり、それは良いことです

別の余談をする価値があります-今食料品側に。

開発中または開発中の製品が他の方向に「移動」できることが重要です。 次のいずれかのレベルで機能します。

• コード行を追加することにより、視覚的なコンポーネントを最小限のロジックでコンポーネントに変換する機能は非常に優れています。 最初から書き直す必要はありません。

  
  
  
  
  
  
  

• SPAまたはサーバー側のアプリケーションに安価に変えることは本当にクールですが、それはめったに不可能です。 コストを課さないのであれば、そのようなプラットフォームで最初から始める方が賢明です。

  
  
  
  
  
  
  

したがって、サーバー上でレンダリングされる必要があるリスク、つまりコンポーネントをリファクタリングする必要があるリスク、テンプレートエンジン間を移動するリスクがあるWebプロジェクトのほとんどは、リスクを回避しようとします。

一部のエンティティが非常に安価に他のエンティティに変わる単一のプラットフォームがある場合、開発は非常に高速です。

角度/反応/ビューのアプリケーションの場合、これはまさにそうです。 彼らは理解するのが難しいです。 もちろん、Angular 1ほど複雑ではありませんが、とにかく-それらを理解するための道のりは長く、6ヶ月のオンラインコースではそれらを理解するのに十分ではありません。 しかし、彼らは数週間前に、そして数日で-数ヶ月かかっていたものを、数時間で行う機会を提供します。

しかし、逆もまた真です-多くの人はそれらを必要としませんが、「ファッショナブル」であるために使用されます。

Webおよびモバイルアプリケーショングループのインフラストラクチャアーキテクトとレイアウトデザイナーが話しているとき、彼らにとっては大変なことです。 現在、これらは非常に異なる方向であるため、JSを除き、知識に共通部分はありません。

次に「Webは非常に複雑になり、肥大化した」と言いたいときは、Googleの受信トレイメールクライアント（レターに応じて含まれるインテリジェントエンティティを含む）、Cloud9やインターネットバンキングなどのWeb IDEの設計と作成がどれほど難しいかを考えてください。

しかし、コーダーがあなたのところに来て、彼が反応する必要があるという事実について話し始めたら、彼はランディングページのレイアウトに厳密なタイピングとデコレーターが必要なので、説得に屈しないでください。