Webの将来はサーバサイドレンダリング（SSR）に回帰していく。Denoが主張するIsomorphic JavaScript（もしくはUniversal JavaScript）とは何か？

静的なHTMLファイルをWebサーバが配信する仕組みから始まったWebは、サーバ側で動的にHTMLを生成するCGIの仕組みや、Webブラウザ上でJavaScriptを実行してインタラクティブな操作を実現するなどの仕組みを得たことでWebアプリケーション基盤へと発展しています。

現在、Webアプリケーションの仕組みとして代表的なものがSPA（Single Page Application）でしょう。

SPAはWebブラウザ上で多くの処理が行われるためユーザーの操作に対する反応が速く、インタラクティブ性の高い快適なWebアプリケーションを実現できる利点があります。

しかし、これからのWebはサーバサイドレンダリング（SSR）に回帰していくと主張するのがDenoです。

How do we build large, complex web apps that still feel fast and snappy to our users?

https://t.co/hmGvgRBYns

— Deno (@deno_land) February 1, 2023

なぜWebの将来がSSRに回帰していくのか、Denoは「Isomorphic JavaScript」（あるいはUniversal JavaScript）と呼ばれる仕組みによって「本物のSSR」が実現できるからだとしています。

本物のSSRとは何か？ Denoの主張を見ていきましょう。

SPAは高度なUXを実現できるが欠点もある

そもそもSSRは、Webサーバ上でプログラムを実行することで、ユーザの操作に対応したWebページを生成し、インタラクティブなWebを実現する仕組みでした。

しかしユーザーがボタンなどを押すたびにWebサーバから新しいWebページが送られてきてWebブラウザがそれを読み込み、画面全体が書き換わるSSRの仕組みは、利用者にとって少々まだるっこしい動作に見えました。

そこで、ユーザーの操作に対する画面上の反応やWebページの遷移そのものも含めて、JavaScriptによってWebページを動的に書き換えるCSR（Client Side Rendering）によって、より柔軟でキビキビとした動作を備えた高度なユーザー体験を実現できる仕組みとして注目されたのがSPAです。

ところがSPAはアプリケーションをWebブラウザ上で実行されるJavaScriptとして記述するため、Webアプリケーションを起動するときにはアプリケーション全体をWebブラウザが読み込まなければならず、初回の起動が遅くなりがちなどの欠点がありました。

DenoもSPAについて次のように指摘するツイートをしています。

For CSR/SPA, that's a lot to ship over a network, which also means:
a terrible user experience
slow loading times, and
a lack of interactivity until everything is rendered

What if we can minimize data we send to the client? Enter SSR / islands.

— Deno (@deno_land) February 1, 2023

Denoが示したSSRの利点と欠点を補う方法

その上でDenoはSSRの利点を改めて次のように示しました。

• 高いパフォーマンス　ページがロードされる際には、あらかじめ生成されたHTMLが読み込まれて表示されるため高速である。
• 高い互換性　サーバでHTMLが生成されWebブラウザ側に依存するものがないため、互換性は高い。
• 低い複雑度　サーバはHTMLの生成を主に行うため、比較的シンプルかつ小さなコードベースの実装となる。

そしてSSRを実現するためのフレームワークとして、現在では多くのIsomorphic JavaScriptなフレームワークが存在するとしました。

There are many isomorphic JavaScript frameworks that support SSR: they render HTML on the server with JavaScript and ship that HTML bundled with JavaScript for interactivity to the client.

SSRをサポートする多くのIsomorphic JavaScriptフレームワークが存在しています。それらはJavaScriptによってサーバ上でHTMLをレンダリングし、そのHTMLにJavaScriptをバンドルすることでクライアントにインタラクティブ性を提供します。

Isomorphic JavaScriptフレームワークの例としてNext.jsやRemixなどが挙げられています。

これらのフレームワークはReactベースのフレームワークとして、サーバサイドでReactをベースにしたHTMLの生成ができます。と同時に、Webブラウザ上でインタラクティブな操作を実現するためにもReactを用いることができる、すなわちサーバとクライアントのどちらもReactをベースとした同型（Isomorphic）のコードを実現できると説明しているわけです。

というのもSSRでは、インタラクティブな操作が発生するたびにWebページがWebサーバから送信されて全画面の書き換えが発生する点が欠点でした。

その欠点を補うために、サーバでHTMLを生成した上で、そのHTMLにJavaScriptをバンドルすることで、インタラクティブな操作が発生したときにはSPAのようにWebブラウザ上でのCSRによる動的な画面書き換えを可能にするわけです。

このような静的なWebページにイベントをアタッチしてJavaScriptを実行できるようにし、動的なWebページにすることは「Hydration」（ハイドレーション）と呼ばれています。

このハイドレーションのためのJavaScriptフレームワークとしてサーバと同じものが使えるのであれば、SSRとCSRのコードの共通化によりシンプルで小さなコードが可能になります。

つまりDenoが主張する、SSRにおいてIsomorphic JavaScriptを用いる利点をおおまかに説明すると、HTMLをレンダリングするためのコードを書いたらそのコードはSSRにもCSRにも使えるため、共通のコードによって、サーバでHTMLを生成させて素早くWebページが表示できて、ユーザーの操作に対して動的な画面書き換えでキビキビ動くWebアプリケーションが簡単に作れてしまうし、コードが共通化されているのでシンプルかつ小さくなる、ということになります。

（ハイドレーションを効率化する仕組みとしてDenoはIsland Architectureも提唱していますが、ここでは省略します）

「本物のSSR」をIsomorphic JavaScriptが実現する

本当にそんな、Isomorphic JavaScriptなコードが書けるのでしょうか？ Denoのブログでは、サーバとクライアントの両方でレンダリングのために実行されるIsomorphic JavaScriptの例がサンプルコードとして示されています。

以下はそれを紹介している部分の引用です。

This client.js file is available to both the server and the client — it is the isomorphic JavaScript we need for true SSR. We’re using the render function within the server to render the HTML initially, but then we're also using render within the client to render updates.

このclient.jsファイルはサーバとクライアントの両方で利用可能であり、これが本物のSSRに必要なIsomorphic JavaScriptです。サーバ側でrender関数を使用して最初にHTMLをレンダリングし、クライアント側でもrenderを使用してレンダリングの更新を行います。

かつてCGIやServletなどが登場したことでSSRによるWebアプリケーションが登場したときには、サーバ側はPHPやPerl、Javaなどの言語で記述し、そこに高度なインタラクティブ性を持たせようとすると、クライアント側はJavaScriptで記述することになり、サーバ側とクライアント側で異なるプログラミング言語での開発と管理を行う必要がありました。

しかしNode.jsやDenoなどのサーバサイドJavaScriptの発展によって、サーバもクライアントもJavaScriptで記述できるようになり、それがIsomorphic JavaScriptという仕組みに発展しました。

そして「it is the isomorphic JavaScript we need for true SSR」（これが本物のSSRに必要なIsomorphic JavaScriptです）との記述が示すように、Isomorphic JavaScriptが本物のSSRを実現する、そしてそれがこれからのWebなのだ、というのがDenoの主張だと読み取れるわけです。

マイクロソフトもBlazorでサーバとクライアントのコードを共通化へ

こうした主張、つまりサーバとクライアントの両方でレンダリングのためのコードを共通化することで、効率的なWebアプリケーション開発を実現しようとしているのは、実はDenoだけではありません。

昨日の記事「Blazorの生みの親が「Blazor United」発表。SPAとSSRを1つのBlazorに統合し、共通のソースコードで記述可能に」で紹介したBlazor Unitedも、Webページを生成するBlazorのコードを記述すると、それをSSRのためのコードとしても、CSRのコードとしても使えるような柔軟な仕組みを備えていることが示されました。

BlazorはWebAssemblyを使って.NETとRazorコンポーネントをサーバでもクライアントでも実行可能にするというアーキテクチャを備えています。

つまりIsomorphic .NETの基盤を備えているというわけです。

Denoは「Isomorphic JavaScript」としてJavaScriptによってサーバとクライアントのコードの共通化による「本物のSSR」の実現を示していましたが、Blazor Unitedが示すように、WebAssemblyを使えばそれはJavaScript以外のプログラミング言語やフレームワークでもIsomorphicは実現可能です。

そう考えると、今後サーバとクライアントで共通して使えるIsomorphicな言語やフレームワークの可能性はさらに大きく広がるのではないでしょうか。