なぜIsland Architectureなのか
本記事の目次
Island Architectureとはなにか
ページ内で静的なコンポーネント部分と、動的なコンポーネント部分など、それぞれを独立してレンダリングする手法です。
どうやら静的なコンポーネントを海に見立て、動的なコンポーネント部分をそこにぽつんと存在する島に見立てているようです。
良いところ
Island ArchitectureはデフォルトでJavaScriptを送信しません。
動的なコンポーネントが存在する場合のみ、その分だけJavaScriptを読み込むだけです。
このおかげで、サイト自体の転送量も段違いに少なくなりますし、何より速くなります。
また、無駄なインタラクティブなコンポーネントはかえってユーザエクスペリエンスを悪くするので、静的ベースなのはとても素晴らしいコンセプトです。
悪いところ
SPAとはかなり相性悪いです。
なんせデフォルトでJavaScriptを送信しないため、MPAベースなのです。
ただ、そこらへんのSPAよりはパフォーマンスは確実に良くなります。
アーキテクチャの現状
Island Architectureは少し新参なため、このアーキテクチャで構築されているフレームワークは少ないです。
ですが、従来のフレームワークより確実にパフォーマンスは良いので、これから多く採用されるような気がします。
アーキテクチャの歴史
歴史を遡ると、同じような考え方は存在していました。
それは、PHPです。(!?)
もちろん違う部分はありますが、PHPでは静的な部分をサーバサイドでレンダリングして、動的な部分はクライアントサイドのJavaScriptを書いて実行してました。
なので、本質的には同じようなものです。時代はめぐりますね...
明示的なWebフレームワーク
Island Architectureでは、サーバサイドとクライアントサイドの別け隔てが激しいため、半ば強制的に明示的なフレームワークになります。
たとえばFreshというフレームワークでは、islands/
というディレクトリにインタラクティブなコンポーネントを入れるよう明示しています。
実際に使用している例
Fresh
FreshはDeno謹製のWebフレームワークです。
ちなみにこのサイトもFreshで実装していますが、なんと某阿部ひろしのファンサイトよりも高速です。
実際ソースを見てもらうとわかりますが、JavaScriptはほとんど送信されていません。
というか、Google Analytics等以外は全く送信していません。
自分のブログにはインタラクティブな要素はないのでね(泣)
Astro
こっちは有名だとおもいますが、Island Architectureを利用しているSSG(Static Site Generator)です。
内部的に様々なフレームワークを使えて、それもJavaScriptは送信しないと言うことなのでどういうことやっていうぐらい便利なフレームワークです。
こちらもブログ作成にはかなりおすすめなのでぜひ使ってみてください。
おわりに
Island Architectureはこれからの未来を作ってくれるものだと確信しています。
みなさんも新しい技術に触れてみてはいかがでしょうか。
スポンサーリンク
