Webフロントエンド技術の学習コスト
ここまでに、昨今のWebフロントエンド事情のとある側面をかいつまんで解説しました。
SSRは、自分でイチから仕組みを構築すると考えると面倒な手法なのですが、SSRを前提としたフレームワーク（Next.jsなど）や、SSRを前提としたホスティングサービス（Vercelなど）も現れ、Webフロントエンドを扱うエンジニアは、さほど苦労することなくSSRの動作環境を構築できるようになっています。
ブラウザとサーバーでは同じJavaScriptでもAPIが違う
さて、ここで着目したいのは、JavaScriptの学習コストの話です。
前述したように、近年のWebフロントエンド分野に携わるエンジニアは、Webブラウザで動くJavaScriptも、Node.jsで動くJavaScriptも、どちらも一定のレベルで書けることが求められています。どちらも同じJavaScript言語なので、一見すると学習コストが低いように思えるかもしれません。その感覚は、概ね正しいでしょう。2010年代の過渡期であればともかく、2020年代であれば、文法レベルでの差異はないようなものですから、困ることは少ないはずです。
しかし、ランタイム、標準ライブラリの違いとなると話は別です。Webブラウザの標準ライブラリであるWeb APIと、Node.jsの標準ライブラリには、大きな差異があります。
とはいえ、クライアントに必要なAPIとサーバーで必要なAPIでは、目的が違います。目的が違えば標準ライブラリのラインナップが違うのは当たり前のことなので、差異の存在自体は悪いことではありません。必要になったものから順に学習していけばよいのです。
SSRではブラウザとサーバーのコードをどちらも書く
では何が問題なのかというと、SSRの文脈ではWebブラウザ向けのコードとサーバー向けのコードを、同じ人がどちらも書くことを要求されることが多いのです。特に、SSRに特化したフレームワークを使っている場合、Webブラウザ向けのUI描画のコードのすぐ隣にサーバー向けのコードを書くことになるケースがあります。その関数のスコープの中ではどんな標準ライブラリが使用できるのか、常に脳内をスイッチしながら書き進めることができるのは一定レベルで器用な人です。
筆者は器用な側の人間ではありますが、だからといって万人に（特に初学者に）この器用さを求めることができるとは思いません。そう思う程度には、難しいことが要求されていると思います。また、熟練者であっても、多少なりとも思考の切り替えにスイッチングコストはかかります。別々の言語間を往復することに比べればコストは格段に少ないものの、ゼロではありません。
こういった学習コストを抑えることができれば、初学者がWebフロントエンド分野で物作りができるようになるまでの時間はぐっと短縮されるはずです。
［コラム］サーバーサイドJavaScriptの相互運用のための取り組み
2010年代のサーバーサイドJavaScriptといえば、ほぼNode.jsのことを指していました。しかし、2020年代になって、Node.js以外の選択肢が増えてきています。
- Deno：Node.jsの作者が新たに作成したTypeScript/JavaScriptランタイム
- Cloudflare Workers：Cloudflareのエッジコンピューティングのランタイム
- Bun：Zig言語で記述された高速なランタイムを含む総合ツールキット
それぞれ、開発元がサーバーサイドJavaScriptにどのような役割を与えたいかによって、少しずつ標準ライブラリのクセが異なっています。ブラウザとサーバーの差異だけでも困っているのに、サーバー同士にも差異があると困ってしまいそうですね。
こういった課題感はそれぞれの開発元にもあったようで、Node.js、Deno、Cloudflare Workersの相互運用性を確保するためのコミュニティグループが発足しているようです。
各ランタイムで共通で使えるAPIを確保することで、どのランタイムでも動くライブラリやアプリケーションを作りやすくなっていくことが期待されます。
基本的には、ブラウザのWeb APIを取り込みつつ可能な限りブラウザと同じ動きをするように実装するようなので、ブラウザとの差異が小さくなることも期待できそうです。ただし、「ブラウザではない」ということも重要な要素なので、まったく同じにはならないという点で、注視していく必要があるでしょう。
Bunは個人開発から法人化したばかりということもあり、このグループには入っていませんが、今後の成長次第では入ってくるのかもしれないと筆者は勝手に思っています。
