本セッションの登壇者
セッション動画
よろしくお願いします。最後のセッションですね。
最初に自己紹介ですが、すぎうらゆうじといって、PixelGridという会社で働いています。
オンラインだとこういうアイコンやアカウントで活動しています。
今日のテーマですが、ご紹介いただいたようにアイランドアーキテクチャです。この単語を聞いたことがある人もいるかもしれませんが、これは具体的にどういう作り方で、どういうものか、何が嬉しいのか、といった話を今日はしようと思っています。資料は英語なんですけれど、説明はめちゃめちゃ日本語でやるので、あまり身構えずに聞いてください。
静的な「海」と動的な「島」で構成されるアイランドアーキテクチャ
アイランドアーキテクチャとは何かというと、右の画面の図みたいに、ページ全体の構成を静的な「海」と、JSが必要な動的な「島」にたとえて作りましょうという構造です。これらのページは事前にでもいいし、サーバーサイドでもいいんですけれど、レンダリングしておいて、ユーザー側のブラウザに返します。
ダイナミックな島に関してはクライアントでハイドレーション(hydration)という処理を行って、カルーセルが動くようにしたり、ポップアップを開いたり、ビデオを再生するといったことができるようになっています。
なんでこんな作りにするのかという話ですが、Webページとは基本的に、静的な部分と動的な部分(動く部分や置き換わる部分)の組み合わせになっていると思うんですけど、静的な部分がけっこう多いはずなんですよね。それはもちろん要件によるし、動的な部分がほとんどだというのであれば、それこそSPAで作ればいいのですが、そうじゃないかもしれないケースがあると想定して、我々は技術を選定しないといけません。
今、流行っているいわゆるNextとかその手のフレームワークを使うと、あれはもともとがSPAをいい感じに作るという見地に立って生まれているものなので、たとえば右の画像みたいにただ「Hello, World!」と言っている静的な画面を作るだけにしても、こんなにもJSの読み込みと実行が必要になってしまいます。現状ではこれをどうすることもできないし、読み込んだJSは全部無駄になるということが課題としてあります。
このハイドレーションって今日のLTでもけっこう何回も出てきたんですけど、トップダウンのアプローチで優先付けもないので、さっきの画面みたいに「てっぺんにあるカルーセルにすぐ触れるようにしたいけど、下の方にあるメディアプレーヤーの処理が重くていつまでも触れない」みたいなことが普通に起こり得る可能性があります。そもそも、JSを使っていないページでJSがいらないのになんでダウンロードするんだという話で、そういうことを回避したい、必要なJSを必要なときにだけ使えるようにできないかな…というのがモチベーションですね。
パーシャルハイドレーション - ページ単位ではなくコンポーネント単位で処理をする
そこでアイランドアーキテクチャです。キーワードになるのはパーシャルハイドレーションという処理です。
これは何かというと、従来のNext.jsのようなフレームワークがやっていることをページレベルのフルなハイドレーションだとすると、そうじゃなくてコンポーネント単位、島単位でハイドレーション処理をしようというものです。
そうすると何が嬉しいのかというと、そもそもJSのサイズが必要な部分だけに減ります。もちろんダイナミックな島がなければゼロJS、つまりJSなしでも動くようになります。それぞれの島がハイドレーションする処理は、全部平行(パラレル)にできるので、それぞれが干渉し合うこともなく速い。そういうふうに個別にハイドレーションできるようになっているということはつまり、タイミングを全部ずらしたりもできるということで、requestIdleCallbackでブラウザのリソースに余裕があるときにやる、IntersectionObserverで画面に入ったらやる、といったことができるようになります。
なんとなく懐かしい気持ちになる人もいると思うのですが、昔はこうやってjQueryとかで、この要素に対してJSを有効化するみたいなことを、我々はあたりまえのようにやってきたんですよ。プログレッシブエンハンスメントという名前を付けたりもしたんですけれど、当時これをやるのはメンテナンスも開発者体験もあまり良くなくて、今からここに戻るのは厳しいなという話がけっこうあると思うんですよね。でも2022年になった今、そういうことがいい感じにできるようになってきています。
アイランドアーキテクチャを試せるツール
じゃあ実際に今の話を聞いて、自分が作りたいものがNextとかNuxtとかのSPA系フレームワークじゃなくていいなと思った場合、このアイランドアーキテクチャをやってみようかなと思った場合にどうするかということです。
今、この分野は熱くて、我こそは我こそは! という競合がいっぱいあります。たぶんここ(下画像)に載ってないだけでまだあると思うんですけど、全部見つけられるだけ見つけて載せておいたので、気になるものがあればそれを使うという感じで試してみるといいかなと思います。
これはAstroを選んだ場合のコード例なのですが、だいたいこんな風に書きます。Reactだったりコンポーネント志向なコードを書いたことがある人は、見れば何をやってるか、絶対わかると思います。このclient属性が付いているところだけがパーシャルハイドレーションで、どういうタイミングで有効化したいかみたいな指定です。本当にそれぐらいですね。
ためしに「Astroを使ってみていい感じになったよ!」という声を探してきたんですけど、この人はNext.jsでブログを作っていて、それをAstroに変えたらバンドルサイズがめちゃくちゃ減ってすごく驚いているということです。これは普通に起こり得ることなので、皆さんも手元でやってみてこの驚きを体験してほしいなと思います。
今日アイランドアーキテクチャについて話す内容はここまでなんですけれど、Go 1 step further - そのもう一歩先へという意味で、(ほかのLTでも)何度も話が出ていたQwikというフレームワークがあります。これは本当に今までのものと考え方が全然違っていて、本当に必要なときにだけJSを利用するデザインになっています。。従来のフレームワークで作ると、初期ロードに必要なJSのコードサイズはO(n)で増えていくけれど、Qwikで作ると絶対O(1)で止まるという特徴もあって、本当にこれは試してみてほしいなと思います。
私の発表は以上です。ありがとうございました。
