【巨大化するWebアプリ】JavaScriptはブラウザから離れてどこへいく

はじめに

最近のWebフロントエンドアプリは高度で複雑な機能を持つ巨大なものに進化しました。それに伴いパフォーマンスについての考慮なども必要になっています。例えばフレームワークではサーバーサイドレンダリングを利用することでブラウザで実行するJavaScriptの量を減らすような動きをします。

これらのJavaScriptの巨大化と配慮について私見を残します。

膨れ上がったWebアプリをロードするという現状

最近のWebアプリケーションは、リアルタイム更新、インタラクティブなUI、オフライン対応、状態管理など多くの機能を備えています。これらの機能を実現するために、大量のJavaScriptコードやライブラリを利用します。ReactやVue.jsのようなフレームワークは、レンダリングや状態管理を仮想DOMによって簡素化しますが、それ自体もJavaScriptコード量を増やしています。

このように膨れ上がったWebアプリのコードはロードに時間がかかるため、表示の遅れや、機能が有効されるまでに時間がかかるなどユーザー体験を悪化させることがあります。

また、現代ではあらゆる人が様々な環境で利用するので必ずしも高速なネットワークがあるとは限りません。電波の入りが悪い場所や通信制限中のスマートフォンなど。ロードに不備があるとレイアウトが崩れたり、機能が正しく動作しないなど、サービスが正しく提供できないことになります。

フレームワークの高機能化、様々なライブラリの登場などにより開発体験は向上しアプリもリッチになっていく反面、コード量が増大していっています。

JavaScriptの実行・解釈をブラウザから離す傾向

最近のフレームワークではブラウザで全てのJavaScriptを実行しないような仕組みを取り入れています。これによりWebアプリケーションのパフォーマンス向上、ユーザー体験の最適化などを目的としています。ブラウザの負荷軽減や初期ロードの高速化により安定したサービスの提供を目指しています。

最近注目のサーバーサイドレンダリング（SSR）は、Next.jsやSvelteKitなどのモダンフレームワークで採用されているレンダリング手法です。SSRでは、JavaScriptをサーバー側で実行し、ブラウザには完成したHTMLを送信します。これにより、クライアントサイドレンダリング（CSR）に比べて初期表示が高速化されます。

HTMLがブラウザに送信された後、JavaScriptがロードされてインタラクティブな機能が有効化されます。このプロセスを「ハイドレーション」と呼びます。ハイドレーションが完了するまでは、ページ内の動的機能（クリックイベントやフォーム送信など）は一時的に利用できないことがあります。

SSRは初期表示速度を向上させ、ユーザーに迅速にコンテンツを届けることができます。

事前にフレームワークのコードをコンパイルし、最小限のコードをブラウザに渡すというアプローチもあります。Svelteは事前コンパイルを行うことで、リアクティブな操作を検出し、必要最小限の純粋なJavaScriptコードを生成します。このアプローチにより、ブラウザがロードするコード量を抑え、バンドルサイズを小さくすることができます。

一方、ReactやVue.jsはリアクティブなアプリケーションを実現するために仮想DOMを採用しています。仮想DOMは効率的なDOM操作を可能にしますが、フレームワーク自身のコードがブラウザで実行される必要があるため、その分コード量が増える傾向があります。

Svelteは仮想DOMを使用せず、更新が必要な箇所だけを効率的に処理します。また、事前コンパイルによりフレームワークのコードを省略できるため、結果としてブラウザで実行されるJavaScriptの量を大幅に削減しています。

このように最近ではSSRや事前コンパイルなどのように、ブラウザに渡すコード量を抑える工夫が行われています。

フレームワークでブラウザ標準機能を活用する

近年、Web開発のフレームワークは、JavaScriptに過度に依存するのではなく、ブラウザの標準機能を活用する方向へ進化しています。

Fetch APIやForm要素といったブラウザに組み込まれた機能を利用することで、フレームワークの内部ロジックを簡潔化し、ロードするJavaScriptの量を削減し軽量化します。またWeb標準に準拠することでブラウザが最適化した機能を利用し、追加のJavaScriptを用いるよりもパフォーマンスの向上を期待できます。

こういった流れの中で注目のプログレッシブエンハンスメントという言葉があります。プログレッシブエンハンスメントは、Webアプリケーションの基本機能をブラウザ標準機能で実現し、必要に応じてJavaScriptで追加の機能を提供する設計思想です。SvelteKitなどのフレームワークはこの思想に沿った設計になっています。

これにより基本的な動作をHTMLとブラウザ標準機能で保証しつつ、必要に応じてJavaScriptによる動的機能を追加することができます。例えばフォームの送信であればJavaScriptが有効な場合はリアルタイムバリデーションを行うなど。またオフライン対応の一環としてJavaScriptが動作しない環境でも、最低限の機能が利用可能になるような作りになります。

おわりに

この話は巨大なJavaScriptの処理をどこに押し付けるかという話だと考えています。今まではブラウザに全てやらせていたが、それではパフォーマンスに問題が出てしまう。そこで事前コンパイルやサーバーサイドレンダリングなどが活用されています。（もちろんサーバーサイドレンダリングにはパフォーマンス意外にもセキュリティ的なメリットなどありますが、話がズレちゃうので）

今後ブラウザの処理機能が向上すれば、これらの工夫もまた別の形に進化するか衰退するか、また状況も変わるかと思います。ビルドツールの進化も目覚ましい昨今なのでこちら方面からの動きもあるかもしれないですね。

変わり続けるJavaScriptを取り巻く環境、JSの明日はどっちだ。