JavaScript フレームワークの 4 つの時代
- WBOY転載
- 2023-04-10 11:51:031522ブラウズ
2012 年に、私は主に JavaScript でコーディングを始めました。私はかつて地元企業向けに PHP アプリケーション、基本的な CMS、Web サイトを最初から最後まで構築しましたが、会社はそれを書き直して機能を追加することにしました。
プロジェクト マネージャーは、私に .NET を使用することを望んでいました。その理由の 1 つは、彼がそれを知っていたからですが、アプリをネイティブのように感じさせたかったからでもあります。 app プログラム - ページの更新や操作アクションを長時間待つ必要はありません。調査とプロトタイピングを行った後、当時出始めたばかりの新しい JS フレームワークを使用してこれらのことができるとマネージャーを説得しました。
私が最初に選んだフレームワークは、実際には Angular 1 でした。ルーターでいくつかの問題が発生する前に、かなり大規模なアプリを構築し、FuelPHP のバックエンドを使用していました。子ルート/アウトレットが再レンダリングされるたびにちらつき、本当に設計されているように感じました。このシナリオは、時間。
その後、ある人から Ruby on Rails Ember を勧められ、試してみたところ、非常にうまく機能すると思いました。私は両方のフレームワークのアイデアも気に入っています。これらのコミュニティのエコロジーも気に入っています。そして全体的に、当時の代替フレームワークと比較して非常に生産的でした。
それ以来、多くのことが変わりました。フレームワークが次々に登場し、大きく進化しました。ブラウザーで JavaScript を使用してアプリケーションを構築できるという考えは、一部の特殊なものから標準的な慣行になりました。私たちが構築してきたインフラストラクチャは完全に変わり、新たな可能性が可能になりました。
この期間中、さまざまなアイデアの間でかなりの競争と衝突もありました。どの JavaScript フレームワークを使用するか、CSS の書き方、関数型プログラミングとオブジェクト指向プログラミング、状態を最適に管理する方法、どのビルド システムまたはツールが最も柔軟で高速であるかなど。振り返ってみると、私たちがしばしば間違ったことについて議論し、将来を見据えた考慮事項を無視しているのは面白いことですが、もちろん、これは結果論でもあります。
そこで、過去数十年の JavaScript 開発を振り返り、私たちがどこまで到達したかを確認するために、回顧展を開催したいと思いました。大きく4つの時代に分けることができます。 ：
- 元の時代
- 最初のフレームワーク
- コンポーネント中心ビュー層
- フルスタックフレームワーク
それぞれの時代にはそれぞれのテーマや核となる矛盾があるが、同時に重要な教訓を学び、着実に前進したいとも考えている。
今日も議論は続いています。ウェブは肥大化しすぎていませんか?平均的な Web サイトは本当に React で書く必要があるのでしょうか? JavaScript も使用する必要があるでしょうか?もちろん、現在が未来を表すことはできず、既存の枠組みは将来的に置き換えられる可能性が高いですが、それは私たちが前進するために役立ついくつかの既存の視点にも基づいています。
元の年
JavaScript は 1995 年に初めてリリースされました。上で述べたように、私は 2012 年に JS を書き始めました。それから約 20 年後、私が最初のフレームワーク時代と呼ぶものの始まり近くになりました。ここでは私が多くの歴史をごまかしている可能性があり、この時代は多くのサブ時代に分割され、それぞれが独自のパターン、ライブラリ、ビルド ツールなどを持っている可能性があると想定できます。
つまり、経験していないことは書けないのです。私がフロントエンド アプリケーションを書き始めたとき、新世代のフレームワークは成熟し始めたばかりでした。 Angular.js、Ember.js、Backbone など。
これまで、最も先進的なテクノロジーは jQuery や MooTools などのライブラリでした。これらのライブラリは当時重要でした。ブラウザが重要な JavaScript を実装する方法の違いを滑らかにするのに役立ちました。
たとえば、IE がイベントを実装する方法は、イベントのバブリングとイベントのキャプチャという Netscape とはまったく異なります。そのため、今日の標準では最終的に両方が実装されますが、それまではライブラリを使用して、両方のブラウザで動作するコードを記述する必要があります。
これらのライブラリは主に、小さな独立したユーザー インターフェイス コンポーネントを作成するために使用されます。アプリケーションのビジネス ロジックのほとんどは依然としてフォームと標準の HTTP リクエストを通じて実行され、HTML はサーバー上でレンダリングされ、クライアントに提供されます。
少なくとも私が知る限り、今の時代で語れるようなビルド ツールはありません。当時の JavaScript にはモジュール (少なくとも標準モジュール) がなかったため、コードをインポートする方法がありませんでした。すべてがグローバルであり、それを整理するのは非常に困難です。
この環境では、JS が完全なアプリケーションを作成するために使用されるものではなく、おもちゃの言語として見なされることが多いことは理解できます。当時私たちが行っていた最も一般的なことは、jQuery を投入し、いくつかの UI ウィジェット用のスクリプトを作成することでした。
時間が経ち、XHR が導入され普及するにつれて、特にクライアントとサーバーの間で何度もやり取りを行う必要がある複雑なプロセスの場合、UI プロセスの一部をページに配置するようになりました。アプリケーションはサーバー上に残ります。
これは、モバイル アプリが登場し始めた頃の状況とはまったく対照的です。 iOS と Android のモバイル アプリは、当初から、Objective C や Java などの実用的な言語™ で書かれた完全なアプリケーションでした。さらに、これらは完全に API 駆動型であり、すべての UI ロジックがデバイス上にあり、サーバーとの通信は純粋にデータ形式で行われます。これにより、ユーザー エクスペリエンスが向上し、モバイル アプリが爆発的に増加し、モバイルとウェブのどちらが優れているかという今日の議論に直接つながりました。
これすべてを JavaScript で行うのは、当初はばかげていると考えられていました。しかし、時間が経つにつれて、アプリケーションはより野心的なものになり始めました。ソーシャル ネットワークはチャット、DM、その他のリアルタイム機能を追加し、Gmail と Google ドキュメントは同等のデスクトップ アプリケーションをブラウザで作成できることを示しました。また、Web はどこでも動作し、より簡単であるため、ますます多くの企業が Web アプリケーションの作成に目を向けるようになりました。 -定期メンテナンス。これにより業界全体が前進し、JS を使用して重要なアプリケーションを作成できることが明らかになりました。
当時、JavaScript には今日の機能がすべて備わっておらず、すべてがグローバルであり、通常は各外部ライブラリを手動でダウンロードして静的フォルダーに追加する必要がありました。 NPM はまだ存在しておらず、モジュールも存在せず、JS には現在の機能の半分もありませんでした。
ほとんどの場合、各アプリケーションはカスタマイズされ、各ページには異なるプラグイン設定があり、各プラグインには状態の管理と更新のレンダリングのための異なるシステムがあります。これらの問題を解決するために、最も初期の JavaScript フレームワークが登場し始めました。
最初のフレームワーク
2000 年代後半から 2010 年代前半にかけて、完全なクライアント側アプリケーションを作成するために特別に設計された最初の JS フレームワークが登場し始めました。この時代のいくつかの有名なフレームワーク:
- Backbone.js
- Angular 1
- Knockout.js
- SproutCore
- Ember .js
- Meteor.js
もちろん、他にもたくさんあり、おそらく一部のサークルではさらに大きなものもあります。これらは主に、Xiao Ming がコーディングに使用しており、比較的人気があるため、私が覚えているものです。
これは、未知の領域に入りつつある生成フレームワークです。一方で、彼らがやろうとしていたことは非常に野心的であり、実際には成功しないだろうと多くの人が考えていました。
シングル ページ JS アプリケーション (SPA) は根本的に劣っていると主張する多くの否定論者がいますが、多くの点でそれらは正しいです。クライアント側のレンダリングは、ロボットがこれらのページを簡単にクロールできないことを意味し、ユーザーはアプリケーションが描画を開始するまでに数秒待つ必要があります。これらのアプリの多くはアクセシビリティの悪夢であり、JavaScript がオフになっている場合はまったく機能しません。
一方、私たちには JS で完全なアプリケーションを構築した経験がないため、最適なアプローチについては多くの競合するアイデアがあります。ほとんどのフレームワークは他のプラットフォームで人気のあるものを模倣しようとするため、ほとんどすべてのフレームワークは Model-View-* の反復になります。モデル-ビュー-コントローラー、モデル-ビュー-プロデューサー、モデル-ビュー-ビューモデルなど。しかし、長期的には、これらは実際には成功しません。特に直感的ではなく、すぐに非常に複雑になってしまいます。
この時代は、JavaScript アプリケーションをコンパイルする方法を本格的に実験し始めた時代でもありました。 Node.js は 2009 年にリリースされ、NPM は 2010 年に続いて (サーバーサイド) JavaScript 用のパッケージを導入しました。
CommonJS と AMD は、JS モジュールを最適に定義する方法をめぐって争う一方、Grunt、Gulp、Broccoli などのビルド ツールは、これらのモジュールを組み合わせて成果物となる最終製品を作成する方法をめぐって争っています。
ほとんどの場合、これらは非常に一般的なタスク ランナー スタイルのツールで、JavaScript を構築するだけでなく、HTML、CSS/SASS/LESS、その他多くのものを実際に構築できます。 Web アプリケーションに組み込むことができます。
しかし、私たちはこの時代から多くのことを学びました:
- URL ベースのルーティングが基礎です。このルーティングのないアプリケーションは Web を破壊するため、最初からフレームワークでこれを考慮する必要があります。
- テンプレート言語による HTML の拡張は、強力な抽象化レイヤーです。多少扱いにくい場合もありますが、ユーザー インターフェイスと状態の同期を維持するのが簡単になります。
- SPA のパフォーマンスは非常に低く、Web にはネイティブ アプリケーションにはない多くの追加の制限があります。すべてのコードを Web 上で公開し、JIT 化し、ローカル アプリケーションがダウンロードされてコンパイルされている間にそれを実行してアプリケーションを起動する必要がありますが、これは気の遠くなる作業です。
- 言語としての JavaScript には多くの問題があり、状況を改善するには本当に改善する必要があります。フレームワークだけではそれを行うことはできません。
- アプリケーションを大規模に作成するには、より優れた構築ツール、モジュール、パッケージングが絶対に必要です。
全体的に見て、この時代は生産的でした。欠点にもかかわらず、アプリケーションの複雑さが増すにつれて、クライアントを API から切り離す利点は非常に大きくなり、多くの場合、結果として得られるユーザー エクスペリエンスは驚くべきものになります。特別な事情がない限りこの時代は続くかもしれませんが、私たちは今でもMV*的なアイデアを繰り返しています。
しかし、突然小惑星が現れ、既存のパラダイムを粉々に打ち砕き、小規模な絶滅事象を引き起こし、私たちを次の時代へと押し上げました。この小惑星はリアクトと呼ばれました。
コンポーネント中心のビューレイヤー
React がコンポーネントを発明したとは思いませんが、正直に言うと、コンポーネントが最初にどこから来たのかはわかりません。しかし、それは少なくとも .NET の XAML まで遡り、Web コンポーネントが仕様として進化し始めたのはそのときです。結局のところ、それは問題ではありませんでした。このアイデアが現れると、すべての主要なフレームワークがすぐにそれを採用しました。
後から考えると、これは完全に理にかなっています。HTML を拡張し、長期間存続する状態を減らし、JS ビジネス ロジックをテンプレート (JSX、ハンドルバー、ディレクティブなど) に直接バインドします。
コンポーネントベースのアプリケーションは、ジョブを実行するために必要な抽象化のほとんどを排除し、コードのライフサイクルを大幅に簡素化します。すべてがアプリケーションのライフサイクルではなくコンポーネントのライフサイクルに結び付けられます。これは、両方とも、やるべきことがはるかに少なくなることを意味します。開発者として考えてみましょう。
しかし、当時は変化がありました。フレームワークは、本格的なフレームワークではなく、「ビュー レイヤ」として宣伝され始めました。フロントエンド アプリケーションに必要なすべての問題を解決するのではなく、レンダリングの問題の解決に重点を置いています。
ルーティング、API 通信、状態管理などのその他の問題は、ユーザーの判断に委ねられます。この時代の有名なフレームワークには次のようなものがあります。
- React.js
- Vue.js
- Svelte
- Polymer.js
他にもたくさんあります。今振り返ると、これは主に 2 つのことを実現したため、第 2 世代フレームワークの中でも人気のあるフレームワークだったと思います。
- これにより、範囲が大幅に狭まります。これらの問題をすべて事前に解決しようとするのではなく、フレームワークの中核はレンダリングに重点が置かれており、より広範なエコシステム内の他の機能についてさまざまなアイデアや方向性を検討できます。悪い解決策もたくさんありますが、良い解決策もあり、次世代がクリームの中から最良のアイデアを選択する道が開かれています。
- これにより、私たちはそれらを受け入れやすくなります。 Web ページ全体を引き継ぐ完全なフレームワークを採用することは、アプリケーションの大部分を書き直すことを意味しますが、既存のサーバー側モノリスでは不可能です。 React や Vue などのフレームワークを使用すると、その一部を既存のアプリケーションに一度に 1 つのウィジェットまたはコンポーネントずつドロップできるため、開発者は既存のコードを段階的に移行できます。
これら 2 つの要因により、第 1 世代のフレームワークを追い越して第 2 世代のフレームワークが急速に発展しました。遠くから見ると、すべてが理にかなった、合理的な進化であるように見えます。しかし、当時その中にいることは非常にイライラする経験でした。
まず、仕事でどのフレームワークを使用するか、またはアプリケーションを書き直すべきかどうかを議論するときに、そのようなフレームワークに遭遇することはほとんどありません。むしろ、多くの場合、「もっと速い！」「もっと小さい！」「必要なものがすべて揃っている！」ということになります。
関数型プログラミングとオブジェクト指向プログラミングについての議論もあり、多くの人がすべての問題の解決策として FP に注目しています。公平に言えば、これらのことは真実です。ビューレイヤーのみのフレームは、（最初は）小さく、より速く（最初は）、必要なものはすべて揃っています（自分で多くのものを構築またはステッチする場合）。
もちろん、関数型プログラミング パターンは JavaScript を悩ませている多くの問題を解決します。平均すると、関数型プログラミング パターンのおかげで JS の方が優れていると私は思います。
しかし、現実には特効薬はありません。アプリケーションは依然として大きく、肥大化し、複雑であり、状態の管理は依然として難しく、ルーティングや SSR などの基本的な問題は依然として解決する必要があります。
私たちの多くにとって、人々が望んでいることは、これらすべての問題を解決しようとするソリューションを放棄し、読者が自分で解決できるようなソリューションに置き換えることです。
私の経験では、これは、新しい製品や機能を提供するためにこの変更を喜んで受け入れ、必要な時間を費やした追加機能すべての開発に資金を提供しないエンジニアリング グループの一般的な慣行でもあります。
その結果、これらのビュー レイヤーを中心に構築された自家製フレームワークが作成されますが、それ自体が肥大化して複雑で、操作が非常に困難になります。
人々が SPA に関して抱えている問題の多くは、この断片化されたエコシステムに起因していると思います。これは、SPA の使用量が爆発的に増加しているときに発生しています。新しい Web サイトでは、ルーティングが正しく行われていなかったり、その他の細かい部分が適切に処理されていなかったりすることが今でもよくあり、非常にイライラさせられます。
しかし一方で、既存の第 1 世代のフルサービス フレームワークは、これらの問題の解決にはあまり役に立ちません。これの一部は、多くの技術的負債によるものです。第一世代のフレームワークは、ES6 よりも前、モジュールよりも前、Babel や Webpack よりも前、私たちが多くのことを解明する前に構築されました。
反復的な進化は非常に困難であり、Angular が Angular 2 で行ったように、完全に書き直すと、コミュニティの勢いが失われます。
そのため、JavaScript フレームワークに関して開発者はジレンマに陥っています。時代遅れになり始めているオールインワン ソリューションを選択するか、フレームワークの半分を DIY で無料で利用できるかのどちらかです。最大限に活用できることを願っています。良い結果が得られました。
これは当時非常にイライラさせられましたが、最終的には多くのイノベーションにつながりました。 JavaScript エコシステムは非常に急速に進化しており、これらのフレームワークがベスト プラクティスを確立するにつれて、他にも多くの重要な変更が発生しました。
- Babel のようなトランスパイラーは標準となり、言語の最新化に役立ちます。機能が標準化されるまで何年も待つのではなく、今日から使用することができ、言語自体がより速く、より反復的なペースで機能を追加し始めます。
- ES モジュールが標準化されたため、最終的に、Rollup、Webpack、Parcel など、ES モジュールを中心とした最新のビルド ツールの構築を開始しました。スタイルやイメージなどの非 JS リソースであっても、インポート ベースのバンドルが徐々に標準になりつつあります。これにより、ビルド ツールの構成が大幅に簡素化され、ビルド ツールがより無駄がなく、高速になり、より包括的になります。
- 標準化される API が増えるにつれて、Node 標準と Web 標準の間のギャップはゆっくりと、しかし着実に縮まりつつあります。 SSR は現実的な可能性になり始め、その後あらゆる本格的なアプリケーションで実行されるようになりましたが、そのたびにカスタム セットアップでした。
- エッジ コンピューティングがリリースされ、JavaScript ベースのサーバー アプリケーションに SPA の配布/応答時間の利点が提供されます (以前の SPA は、完全にロードするのに時間がかかる場合でも、CDN 上の静的ファイルであるため、通常はより速くロードを開始しました)終わり）。
この時代の終わりには、いくつかの疑問が残ります。以前よりも優れたモデルがあるにもかかわらず、状態管理と応答性は (そして今でも) 厄介な問題でした。
パフォーマンスは依然として難しい問題であり、状況は改善されつつありますが、依然として数多くの肥大化した SPA が存在します。
アクセシビリティの状況も改善されましたが、多くのエンジニアリング組織にとって、それは依然として後回しであることがよくあります。しかし、これらの変化は次世代のフレームワークへの道を切り開き、現在私たちはそのフレームワークに入りつつあると言えます。
フルスタック フレームワーク
個人的には、最後のフレームワーク時代が本当に静かに到来しました。それは、私が過去 4 年ほどを Ember のレンダリング層の内部を掘り下げて調査し、第一世代のフレームワーク (まだ) に影響を与えた前述の技術的負債を解決しようとしていたからだと思います。しかし、これらの第 3 世代のフレームワークはすべて、前世代のビュー レイヤー フレームワークを中心に構築されているため、それがより微妙になるためでもあります。これらのフレームワークには次のものが含まれます:
- Next.js (React)
- Nuxt.js (Vue)
- Remix (React)
- SvelteKit (Svelte) )
- Gatsby (React)
- Astro (Any)
これらのフレームワークは、ビュー層が成熟して統合されるにつれて始まりました。コンポーネントがコアの上に構築されるということに全員が同意したので、アプリケーションの他の部分 (ルーター、ビルド システム、フォルダー構造など) の標準化を始めるのは理にかなっています。
これらのメタフレームワークは、ゆっくりと、第一世代のオールインワン ソリューションと同じ機能をすぐに構築できるようになり、それぞれのエコシステムから最適なパターンを厳選し、成熟するにつれて、それを組み込む。
そして彼らはさらに一歩前進しました。
これまで、SPA はクライアントのみに焦点を当ててきました。 SSR はすべてのフレームワークが解決したいと考えているものですが、それは最適化として、つまりレンダリングされる方法としてのみであり、最終的にはメガバイトの JS がロードされたときに置き換えられます。
さらに深く考え直した第一世代のフレームワークは Meteor.js の 1 つだけですが、その同型 JS のアイデアは実際には実現しませんでした。
しかし、アプリケーションのサイズと複雑さが増大するにつれて、この考えが再考されました。
バックエンドとフロントエンドを組み合わせると実際に非常に便利であることに気付きました。これにより、特定のリクエストの API シークレットを非表示にしたり、ページを返すときにヘッダー ファイルを変更したり、API リクエストをプロキシしたりすることができます。 Node と Deno がますます多くの Web 標準を実装し、サーバーサイド JS とクライアントサイド JS の間のギャップが年々縮まっていくにつれ、結局のところ、これはそれほど突飛なアイデアではないように見え始めています。これをエッジ コンピューティングや素晴らしいツールと組み合わせると、信じられないほどの可能性が生まれます。
最新世代のフレームワークはこの可能性を最大限に活用し、クライアントとサーバーをシームレスに統合します。これがどれほど素晴らしいことであるかを強調することはできません。過去 9 か月間、SvelteKit を使って作業してきましたが、何度座って「これが私たちが常にやるべきことだ」と自分に言い聞かせたかわかりません。最近遭遇したいくつかのタスクは、このセットアップを使用すると、信じられないほど簡単になります。
サーバー側の OAuth をアプリケーションに追加して、認証トークンがサーバーから出ないようにするとともに、API にリクエストを行うときにトークンを追加する API プロキシを追加します。- 特定のルートを CDN に直接プロキシすることで、他のフレームワークで構築された静的 HTML ページをホストできるようになり、ユーザーが独自のカスタム ページ (一部のクライアントに提供するサービス) を作成できるようになります。
- キーを必要とする外部サービスを使用する必要がある場合は、いくつかの異なるワンタイム API ルートを追加します (まったく新しいルートを API に追加したり、バックエンド担当者と調整したりする必要はありません)。
- LaunchDarkly の使用をサーバー側に移すことで、ロードする JS が減り、全体的なコストが削減されます。
- バックエンド ルーティングを通じて Sentry リクエストをプロキシすることで、広告ブロッカーが原因で報告されないエラーをキャッチできるようになります。
- そして、これは氷山の一角にすぎません。このパターンには本当に多くの優れた点があります。その最大の点は、プログレッシブ拡張のアイデアを再活性化し、サーバーとクライアントの組み合わせ機能を活用して、ユーザーが無効にした場合にクライアントが基本にフォールバックできるようにする方法です。 JavaScript HTML HTTP。
私自身もスパの仕事を始めた頃はスパは完全に諦めていて、これからのトレンドだと思っていましたが、もしかしたら復活する世界が来るかもしれません。本当に素晴らしいです。
これらは新しい機能です。経験から、私はこれらのフレームワークを新世代フレームワークとして分類します。以前は解決が困難または不可能だった問題も、応答処理ロジックをわずかに変更するだけで簡単になりました。
信頼性の高いパフォーマンスとユーザー エクスペリエンスは、すぐに提供されるため、追加の構成は必要ありません。新しいサービス全体を構築する代わりに、必要に応じてエンドポイントやミドルウェアをいくつか追加できます。これは人生を変えるものでした。
この世代では、第 1 世代と第 2 世代のフレームワークとそのユーザーの間の主要な対立点のいくつかも解決されていると思います。
それはゼロ構成用語への移行から始まりましたが、最終的には第 2 世代フレームワークを中心としたエコシステムの成熟と安定性によって推進されており、これは文化的な変化でもあると思います。
第 3 世代フレームワークは現在、再びオールインワン ソリューションになろうとしており、レンダリングだけでなく、フロントエンド開発者として解決する必要があるすべての基本的な問題を解決しようとしています。
SPA を悩ませている多くの問題すべてに対処し、重要なことに、それらを一緒に解決するためにコミュニティが団結しているようにこれまで以上に感じています。
次はどこへ行きますか?
全体として、JavaScript コミュニティは正しい方向に進んでいると思います。私たちはついに、「単なるビュー層」ではない完全なアプリケーションをゼロから構築するための成熟したソリューションを開発しました。
私たちはついにネイティブ アプリケーション SDK と同じスタートラインで競争し始め、すぐに使える完全なツールキットを提供します。
この分野では、やるべきことがまだたくさんあります。 SPA の世界ではアクセシビリティは長い間後回しになっており、GraphQL 以外ではデータ ストーリーには何らかの工夫が必要だと今でも考えています (好むと好まざるにかかわらず、Web のほとんどは依然として REST で実行されています)。
しかし、傾向は正しく、共有ソリューションの方向に進み続ければ、これらの問題を以前よりも良い方法で解決できると思います。
私はまた、これらのパターンを Web プラットフォーム自体にさらに高めることの可能性にも興奮しています。 Web コンポーネントは現在も静かに反復されており、SSR やグローバル登録の削除などの問題に取り組んでおり、これらの第 3 世代フレームワークとの互換性が高まります。
別の方向では、WebAssembly は驚くべき方法でこのパターンを反復できます。あらゆる言語でフルスタックのフレームワークを作成できることを想像してみてください。
Rust、Python、Swift、Java などの同型言語は、最終的にフロントエンドとバックエンドの間の障壁をほぼゼロに減らすことができます。システムのエッジにある小さな HTML テンプレートだけです (皮肉なことに、これにより、ユーザー エクスペリエンスは向上しましたが、ほぼ一周してきました)。
ここでの私の最大の願いは、断片化の時代と新しい JS フレームワークの時代を日々超えて進んでいることです。自由と柔軟性はイノベーションを生み出しますが、同時に、Web 上で混乱し、つながりがなく、根本的に壊れたエクスペリエンスをもたらすこともあります。
開発者が 50 以上のオプションから選択し、限られたリソースと厳しい納期でそれらを組み合わせなければならない場合、これは私たちが目にする経験であり、それは理にかなっています。高速で一貫性があり、信頼性が高く、楽しく使用できるアプリもあれば、イライラして混乱し、遅く、壊れやすいアプリもあります。
もっと使いやすく、デフォルトで正しい動作をするツールを開発者に提供できれば、おそらく平均的な Web サイトはより良くなり、平均的なエクスペリエンスはよりスムーズになるでしょう。
すべての Web サイトを修正できるわけではありません。劣悪な UX デザインは、いくらコードを書いても修正できません。しかし、共通の基盤が築かれるので、どの Web サイトも少しずつ良い状態でスタートし、すべての開発者が他のことに集中できる時間が増えます。
以上がJavaScript フレームワークの 4 つの時代の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。