フロントエンドフレームワーク第0課：フレームワークを学ぶ前に知っておくべきこと

注: この記事は AI によって翻訳されています。もし不自然な表現や誤りがありましたら、メールやその他の手段でお知らせいただけると幸いです。フィードバックをいただけると助かります！

フロントエンドフレームワークの選択は、多くの初心者（私を含む）にとって常に大きな疑問でした。私は当初、会社が React を使用していたため、React を書くしかありませんでした。最近、縁あって Angular に触れる機会があり、それがきっかけで「フロントエンドフレームワーク」について、「フレームワーク」とは一体何を指すのか？何が「フレームワーク」と呼ばれるのか？なぜフロントエンドでそれを使用する必要があるのか？使用しないとどうなるのか？Vue3 がすごいと聞いたが、学ぶべきか？などの問題について、より深く考えるようになりました。

そしてこの記事は、上記の問題のいくつかを解決するための私の思考であり、フレームワークを学び始める前に知っておくべき基本的な概念だとも考えています。

Web の歴史について簡単に

技術の発展は日進月歩ですが、技術の本質は「問題解決」にあります。

技術の文脈を理解することで、目の前の技術を理解し、将来の発展を想像するのに大いに役立つと信じています。

1990 年代：Web の誕生

1990 年 12 月 20 日、ティム・バーナーズ＝リーは最初のウェブサイトを書き、World Wide Web を設計しました。
この時期は静的なウェブページが主で、せいぜい動的なメニューや画像効果がある程度でした。

2000 年代：Web 2.0 ＋ Ajax

2004 年の Web 2.0 の誕生により、ウェブページの対話性が向上し始めました。Facebook (2004) や Youtube (2005) はこの時期に登場しました。
Ajax の非同期リクエストの応用により、ウェブページはブラウザではなく JS を介してリクエストを送信できるようになったため、データを更新するためにリロードする必要がなくなりました。

2010 年代：Web アプリケーション（Web Application）概念の出現

この時期から、Web の複雑さと対話性は大幅に向上し、当初はデスクトップアプリケーション（Desktop Application）でしかできなかったことができるようになってきました。

このような高い対話性を持つウェブサイトが必要とする基本的な処理に対応するために、フロントエンドフレームワークが誕生しました。

Angular 1.0 (2010)
React (2013)
Vue (2014)

（より詳細な進化の歴史に興味がある場合は、下部に参考リンクを添付します）

具体的に、フロントエンドフレームワークは何を処理してくれるのか？

一、コンポーネント (Components)

再利用可能で独立した UI、例えば Button

純粋なネイティブ HTML、CSS、JS だけでコンポーネントの概念を実現するのは非常に面倒です。フレームワークを使用することで、素早くコンポーネントを作成でき、コードの再利用、開発の加速、開発者体験の向上に役立ちます。
一つのコンポーネントには、階層間の通信方法（External Props）、管理可能な内部状態（Internal States）、**ユーザーイベント（Listen to browser events）**が含まれます。

二、状態管理 (State Management)

データとユーザー操作イベントの相互作用フローを管理する

ウェブページ内の状態は、現在のウェブサイトであなたが置かれている段階を表します。例えば、会員システムには訪問者と会員の 2 つの状態があり、メッセージには既読と未読の 2 つの状態があるなどです。ウェブサイトの複雑さに応じて、Web アプリケーション全体で管理すべき多くの状態が存在します。

大まかに 3 つの状況があります：

コンポーネントレベルの状態（Component-Level State）：状態は単一のコンポーネント内でのみ管理・使用されます。React の useState のようなものです。
コンポーネント間の状態（Share State Across Components）：データや状態がコンポーネント間で渡され、複数のコンポーネントに同時に影響を与える状況です。React の useContext や Props のようなものです。
グローバルな状態（Global State）：ウェブページのどこでも管理・取得できる状態です。React では通常、管理を助けるために Redux と組み合わせて使用されます。

三、ライフサイクル (Life Cycle)

ブラウザ上でフレームワークが動作するプロセス。DOM とブラウザのレンダリングメカニズムを処理してくれます。

私たちが書いたコンポーネントが実際にブラウザに表示される際、実際には次のプロセスを経ています：Mounting → Updating → Unmounting

Mounting：コンポーネントのインスタンスが作成され、DOM に表示される時
Updating：状態が変化した時、DOM を再レンダリング（re-render）する
Unmounting：コンポーネントが DOM から削除されようとする時

各フレームワークはこのようなプロセスに従っていますが、再レンダリングをトリガーする方法は、基礎となる実装ロジックによって異なります。これは、フレームワークがユーザーの対話イベントや状態の変化にどのように対応するかに関わります。フレームワークのパフォーマンス最適化の大部分は、再レンダリングのメカニズムを処理することにあります。

四、ルーティング (Routing - Client-Side)

フロントエンドでページ間のナビゲーションや切り替えを処理する

以前のサーバーが HTML を直接フロントエンドに吐き出す方法

ウェブサイト上のリンクをクリックすると、ブラウザはサーバーと通信し、表示するための新しいコンテンツを取得します。
新しいコンテンツを取得した後、アドレスバーの URL が変わります。

フロントエンドフレームワークの方法

サーバーはルートノードとして HTML を一つだけ返し、その後の変更はその DOM を更新することになります。
ページ間の切り替えはもはやブラウザを介さず、フロントエンド側で JS を介して動的に変更されるため、ルーティングもフロントエンドで実装する必要があります。
React は実装を支援するために React-Router を必要としますが、Angular には独自の組み込み Routing システムがあります。

フロントエンドフレームワークがもたらすメリット

ここまでフレームワークが適用する概念について多く語ってきましたが、これらの概念が達成できるメリットや効果を少し整理してみましょう。

一、より良い開発者体験

フロントエンドフレームワークは、多くの技術変革と同様に、JavaScript 自体に新機能を提供したわけではなく、ウェブサイトをより簡単に書くための方法を提供しただけです。

再利用可能な独立したコンポーネントを書くことで、コードの可読性と保守性が大幅に向上します。以前のネイティブ JS で新しい DOM 要素を繰り返し作成しようとする方法は、一目で理解するのが困難でした。ToDo リストのコードをフレームワーク使用前後で比較してみると、その違いがわかるはずです。
フレームワーク自体を使用することで、チームや個人の作業効率を向上させることができます。フレームワークの知識体系があれば、多くの仕様がフレームワークレベルで定義されるため、プロジェクトを理解する際の認知的負荷が大幅に軽減されます。

二、様々な便利なツールとエコシステム

一つの技術が台頭した後、人々はその基礎の上に多くの便利なツールを開発し続け、以前は考えられなかった多くの新しい可能性や問題が出てきます。気運が高まると、その技術の使用を好む人々が徐々に「コミュニティ」を形成していきます。

コミュニティはその技術のエコシステムを構築します。開発者はニーズに応じて様々なツールを開発し、将来の開発体験と効率を向上させます。

したがって、技術自体も重要ですが、人々にその技術を使ってもらえるようにすることも非常に重要です。

（技術もマーケティングを知る必要があり、マーケティングが成功してコミュニティができて初めて普及します。結局のところ、個人や少人数のグループの能力には限りがありますから）

長々と話しましたが、結局どうやってフレームワークを選べばいいの？

選択するのは子供、大人は問題を解決する。

上記の概念を理解した後、主要なフレームワークはすべて同様の問題を解決しており、共通の実装概念を持っていることがわかります。ただ基礎となるメカニズムが少し異なるだけで、別のフレームワークを学ぶことは、新しい構文と実装メカニズムに慣れるだけであり、その背後には実際には同じ問題解決の思考回路が共有されています。

したがって、選択することよりも、私たちが気にかけるべきことは：

JavaScript により詳しくなること
上記の概念がフレームワーク内でどのように動作し実装されているかを理解すること

どうしてもフレームワークを選びたい場合は、React、Vue、Angular のドキュメントを一通り見て、チュートリアルをやってみて、どのフレームワークが好きかを感じてみることをお勧めします。

実際、一生書き続けさせてくれるフレームワークなんてありません。

フレームワークを学ぶ過程では、常に自分自身に「フレームワークエンジニア」にならないようにと言い聞かせてください。つまり、フレームワークという「ツール」を使うことにとても慣れているだけで、フレームワークが最初にどのような問題を解決するために現れたのか、そしてその後の技術変革がフレームワークが現在直面しているどのような問題を解決するためのものなのかを無視してはいけないということです。

最近ではサーバーサイドレンダリング（Server-Side Rendering）の概念が非常に人気があるように、将来的にも間違いなく多くの変革があるでしょう。

最後に、概念を明確にしましょう：Framework vs Library

私たちは「三大フレームワーク」と言うのに慣れていますが、実は React は Library としか言えません。フレームワークとしては、あなたのために処理してくれることが少なすぎるからです。

フレームワーク (Framework)：前述のように、機能が完備されたフルセットであり、実装方法に対してより厳しい要件があります。例えば、Router、FetchAPI 操作などには規定があります。

Angular はすべてのものを公式 API に統合しているため、フレームワークの基準に完全に適合しています。

ライブラリ (Library)：React を例にとると、実際にはライフサイクルのみを処理します。その他はサードパーティのライブラリ（レンダラーには react-dom、ルーターには react-router など）の助けを借りて統合する必要があります。

結び

実際にはカバーされていないことがまだたくさんありますが、冒頭で述べたように、この記事の目的は、皆さんがフレームワークを学ぶ前に、いくつかの構造を把握し、この技術がどこから来たのか、なぜ使うべきなのか、使うと何の問題が解決できるのかを理解してもらうことであり、盲目的に飛び込んで学ぶことではありません。私が最初に Angular のドキュメントの海に直接飛び込んだとき、本当に溺れているように感じました。しかし、最初にフレームワークの基本構造を把握できれば、大海原で無力感を感じることはなく、少なくとも遠くに島が見えるようになると信じています 🏝。

最後に、ここまで読んでくださった皆さんに感謝します。これは私が初めて書いた技術記事です。実は以前から書きたいと思っていました。普段、共有する意欲のある多くの先輩方から恩恵を受けていますから。莫力全 Kyle Mo さんと Ian-Lai さんの励ましのおかげで、ついに第一歩を踏み出すことができました！

もし不明な点があれば、コメントで教えてください。今回の共有内容が皆さんのお役に立てば幸いです。それでは、また次回お会いしましょう〜

もし気に入ったら、拍手をお願いします。最大 50 回まで拍手できます。役に立ったと思う程度に応じて拍手してください。これは私が調整するための根拠にもなります 🙌

References

進化の歴史に関するリンク：