フロントエンドの真実

起源

まだフロントエンドという言葉が生まれる前。
古代のプログラマー達はサーバーで一画面ずつ丁寧にHTMLを構築していた。

ところがあるとき一人のプログラマーがブラウザ上で動的にHTMLを書き換えることに成功する。

これに多くのプログラマーが続いた。

次第に勢力を増していった彼らはサーバーを離れ、自らをフロントエンドエンジニアと名乗り、サーバーに残ったもの達をバックエンドエンジニアと呼ぶようになった。

きっかけ

先日こんな投稿がとある掲示板（ここではXと呼ぶことにしよう）に寄せられた。
https://x.com/phikhi/status/1767195364912697848?s=20

たしかに、Server Actionsを使って書くReactと、いにしえのPHPは非常によく似ている。

ふと10年近く前の出来事を思い出した。
それは次のような同僚との会話だった。

👨🏻‍💻「React触ってみました。」
👨🏻‍💼「え、どんな感じやった？」
👨🏻‍💻「なんかPHPに近い感じがしました。」
👨🏻‍💼「へ〜、そうなんや」

今思えばこのときから彼は異変に気付いていたのかもしれない。

PHPとの不可解なつながり

改めてここ数年のフロントエンドの動向を振り返ると、そこにはいくつかの不可解な点があった。
そしてそれらを辿っていくと必ずPHPに行き着くのである。

その一つが先ほどのとある掲示板「X」への投稿内容だ。
投稿内容の信憑性を確かめるべく、当時を思い出しながら出来る限り事実に基づいて再現してみた。

いにしえのindex.php

<span class="class-name"><?php echo htmlspecialchars($text);?></span>

いにしえのindex.html

<span class="class-name"></span>
<script>
$('.class-name').text(text);
</script>

~ 10年後 ~

近代的なIndex.jsx

<span className="class-name">{ text }</span>

10年の時を経て現代に甦ったいにしえのコードを見て衝撃が走った。
驚くべきことに、フロントエンドはあたかもPHPに導かれたかのような進化を遂げていたのである。

果たしてこれは偶然なのだろうか、、、？
その答えは無数に絡み合ったフロントエンドとPHPとの不可解なつながりの中に隠されていた。

ファイルベースルーティング

以前はプログラムでルート定義を行っていたが、今ではルールに従って配置したファイルのパスがそのままURLに対応するファイルベースルーティングが主流だ。

では、古代のプログラマー達はどのようにルーティングを行なっていたのだろうか？

当然だが古代のプログラマー達はルーティングをサーバーで行っていた。
彼らは公開ディレクトリというディレクトリを設定し、そこからのパスがそのままURLに対応していた。

いにしえのPHP

/var/www/html/form/complete.php -> http://www.www.www/form/complete.php

近代的なファイルベースルーティング

pages/form/complete.tsx -> https://www.www.www/form/complete/

動的ルートこそ無いもののまさしくファイルベースルーティングである。

これだけで断言することは出来ないが、やはり何者かによってサーバーの技術が持ち込まれた可能性がありそうだ。

SSR

SSRことサーバーサイドレンダリングについて語る前にSPAについて知っておく必要がある。

SPAとはHTML構築の大半をブラウザ上で行うことで、ページ全体の読み込みを伴う画面遷移をすることなく画面を切り替えることが出来る仕組みである。

バックエンドとのやり取りは主にJSON形式のデータのみで行うためスムーズな画面遷移や作業分担、画面を跨いでのデータの引き継ぎが容易に行える等、ユーザー、開発者双方にメリットをもたらし、瞬く間にWebの世界を席巻していった。

サーバーで構築したHTMLを配信する時代から、ブラウザ上でHTMLを構築する時代への移り変わりである。

勿論良いことばかりでは無かった。

HTMLの構築をブラウザ上で行うため、JavaScriptをサポートしないクローラーはSPAで構築されたサイトのHTMLを読むことが出来なかったのである。

その中には、検索順位に影響を与えるクローラーや、Webページをシェアした際にそのページの情報を読み取るクローラー等、サイトを運営する上で無視することの出来ない重要なクローラーも含まれていた。

また、ブラウザ上でHTMLを構築するためページが増えるに従って初回に読み込むJavaScriptファイルが肥大化するという問題も抱えていた。

それらの問題を克服すべく試行錯誤の末たどり着いたのがSSRだった。

SSRはブラウザ上で行っていたHTMLの構築と同じ作業をあらかじめサーバーでも行うというアプローチを取り、見事にこの問題を克服してみせた。

一方で、この出来事は何者かがフロントエンドの技術をバックエンドに漏洩した事を示唆していた。

ハイドレーション

問題を完全に克服したかに見えたSSRだったが、別の問題が新たに注目される。
ハイドレーションによるパフォーマンス問題だ。

サーバーサイドレンダリングされたHTMLはただのテキストであり、これを動的なアプリケーションとして動かすためには

1. その画面のレンダリングに必要な全てのJavaScriptを読み込み
2. サーバーで行ったレンダリングをブラウザ上で再現し
3. イベントリスナーの設定（ハイドレーション）を行う

干からびたHTMLという大地に、イベントリスナーという水を給水することで本来の姿を取り戻すのだ。

あらかじめ完成したHTMLを受け取っているため表示はされるものの、この一連の処理が完了するまでは動的な操作は行えないのである。

アイランドアーキテクチャ

こちらはAstroというフレームワークで有名になったアーキテクチャで、例えば静的なHTMLのレンダリングを行うだけのブラウザ上では不要なJavaScriptを取り除き、動的な要素にのみハイドレーションを行う。
これによって読み込むJavaScriptのサイズは削減され、部分的にハイドレーションすることでパフォーマンスが改善される。

事前に構築されたHTMLに最小限のイベントリスナーを設定するという手法は古代のPHPエンジニアが用いた手法に酷似している。

Resumable

こちらはquikというフレームワークで採用されている手法で、ハイドレーションそのものを行わない。
これがどのように動くかというと、その画面で必要なクリック等のイベントをbodyやwindowでハンドリングし、イベントターゲットに設定された属性から必要なJavaScriptをダウンロードし、実行するのだ。

このbodyやwindowでイベントをハンドリングするというテクニックはイベントのターゲットとなる要素をごっそり入れ替えてもイベントリスナーを張り替える必要がなく、jQuery時代に多用されたテクニックである。

結論

これらの事からフロントエンドエンジニアがサーバーを離れたとき、PHPエンジニアが紛れていたのは明らかである。

ーーフロントエンドはPHPに支配されていた。

フロントエンドエンジニアに成り済ましたPHPエンジニアたちは歴史の闇で暗躍し、フロントエンドを自分たちの都合の良いようにバックエンドに似せたものへと誘導し、フロントエンドで培われた技術をSSRと称してバックエンドのものにしてしまっていた。

果たしてフロントエンドはこの先生をきのこることが出来るのだろうか。
10年後が楽しみである。

あとがき

10数年前にPHPに入門し、JS、HTML、CSSと手を広げていった自分は、冒頭の投稿を見てそういえば最近のこの技術、昔やってたあれと似てるな〜と懐かしくなったので昔話や普通のことをなんかそれっぽく書いてしまいました。
反省はしていません。