フロントのフレームワーク、何を学べば無駄にならない

半年前にやっと使えるようになったフレームワークの書き方が、気づけばもう「古い書き方」と呼ばれている。公式ドキュメントのサンプルコードが更新され、周りのエンジニアが別の名前のツールを話題にし始める。覚えた作法が無駄になったわけではないが、次に何を学べば同じ徒労を繰り返さずに済むのか、答えがはっきりしないまま時間だけが過ぎていく。

フロントエンドのフレームワークは、たしかに入れ替わりが速い分野だ。だがその速さの正体を分解すると、「何に時間を投資すべきか」の判断材料が一つ見えてくる。

移り変わっているのは「表現層」だけ

フレームワークが変わると、書き方の見た目はがらりと変わる。コンポーネントの定義の仕方、状態の更新の呼び方、ファイルの置き場所のルール――ここだけを見ていると、学んだことがすべてリセットされたように感じる。

しかし一歩引いて見ると、フレームワークが入れ替わっても変わっていないものがある。「画面の状態をどう持つか」「どのタイミングで何を再計算するか」「データがどこから来てどこへ流れるか」という設計上の問いそのものは、フレームワークの外側にずっと居座っている。フレームワークが変わるたびに作法は変わるが、その作法が解こうとしている問題は同じ問題のままだ。言い換えれば、フレームワークはその問題に対する「今どきの答え方」を提供しているだけで、問いそのものを所有してはいない。この「問い」の部分――設計・型・状態管理・非同期処理・データフローの考え方――は、表現層の下に流れる土台であり、フレームワークが入れ替わっても持ち運べる資産になる。

「新しくて速い」は、蓄積が薄いことの裏返り

ここで一つ、意外な非対称がある。新しく登場したフレームワークほど、ビルドやランタイムの速さを売りにすることが多い。速さは実際に魅力的だが、その速さは裏側で「まだ誰もあまり詰まっていない」ことと表裏一体でもある。

試しにStack Overflowに累積した質問数――これまでに世界中の開発者がつまずき、やり取りを重ねてきた量――を見てみる。Svelteはこれまでに6,281件、Remixは672件、SolidJSは323件。対して横断的な土台であるTypeScriptは234,150件、Reactは473,884件。これは成長の勢いではなく、単純な蓄積量の差だ。新しくて速いフレームワークを選ぶほど、同じ壁にぶつかったとき参照できる先人の記録は薄く、広く使われてきた土台を選ぶほど、その記録は厚い。つまり学習の歩留まり――同じ時間を投資したときにどれだけ困りごとを解決できるか――は、新しくて速いフレームワーク固有の作法よりも、どのフレームワークでも通用する土台の方が高い。これは好みの話ではなく、蓄積の量という構造の話だ。

何を学ぶかより、何に時間を割かないか

この構造を踏まえると、学習の優先順位は自然と決まってくる。フレームワーク固有のAPI名や設定ファイルの書き方を丸暗記することに時間を使うより、「このフレームワークは状態をどう扱っているか」「このフレームワークは何を見てDOMを更新しているか」を、別のフレームワークと比較しながら理解する時間に寄せる。前者は次のフレームワークに乗り換えた瞬間にリセットされる知識で、後者は乗り換えてもそのまま使える理解だからだ。

これは「新しいフレームワークを学ぶな」という話ではない。むしろ新しいものに触れる機会は増やしてよい。ただそのときに、表面の書き方を覚えることをゴールにせず、「このフレームワークは、状態管理・非同期処理・データフローという共通の問いに、どう答えているか」を確認する作業として触れる。そうすれば、次にまた別のフレームワークが流行っても、作法の差分を学び直すだけで済み、土台の理解をゼロから作り直す必要がなくなる。

今日からできる一手は小さい。次に新しいフレームワークのチュートリアルを開くとき、最初のページで「このフレームワークの状態管理は何に似ているか」を自分の言葉で一文にしてみる。その一文が書けたなら、学習の時間配分はもう土台側に寄り始めている証拠だ。型についての理解を先に固めておきたいなら、

https://s-tasklog.com/learn/typescript

が参考になる。フレームワーク同士の違いを比較しながら選びたいときは、

https://s-tasklog.com/vs

で技術を横に並べて見ることができる。たすくろぐは、こうした学習の優先順位を考えるときの材料を提供するサイトだ。