【Qiita Night】Denoからリリースされた最新フレームワーク Fresh を触ってみた

概要

2022/10/21(金)に行われた「Qiita Night～フロントエンド～」にて、「Denoからリリースされた最新フレームワーク Fresh を触ってみた」という登壇をさせていただきました！
本投稿は登壇内容を記事化したものになります！

スライドはこちら

アーカイブはこちら

登壇内容

「Denoってなに？」「Denoは知っているけど、Fresh？」みたいな人に、最新Webフレームワーク「Fresh」を知ってもらえるきっかけになればと思います！

そもそもDenoとは

• Node.jsの開発者であるRyan Dahlが新しく開発した JavaScript/TypeScriptの実行環境
• Nodeを作った時の改善点を取り入れて再作成したため、さまざまな機能が標準で搭載されている
  • TypeScriptのデフォルトサポート
  • Promiseファースト
  • ESModuleのサポート
    などなど...
• これまでNodeで利用していたNPMのモジュールシステムは利用できず、Deno独自のモジュールシステムを利用して開発を行う
  • これは8月末に大幅な方向転換が発表されました。
  • Denoが大幅な方針変更を発表。3カ月以内にnpmパッケージへの対応を実現

Denoの公式トップページにまとめられています。

Deno 公式より「Fresh」ver1.0 がリリース

• Deno自体には他のWebフレームワークが存在していたが、今回Deno公式からWebフレームワーク「Fresh」がリリースされた

Freshの特徴

• Deno公式にも記載されているが、大きな特徴が6つある。
  • Just-in-time rendering
  • Island based client hydration
  • Zero runtime overhead
  • No build step
  • No configuration
  • TypeScript support
• いくつか特徴をグルーピングして説明をします。

開発の初期設定不要 & TSのサポート

• Denoをランタイムに利用しているので、TypeScriptが標準で利用することができます。(tsconfig.json不要)
• deno lint , deno fmt を利用できるので、リンターやフォーマッターの設定も不要
• プロジェクト作成時にTailwindCSSを自動インストールすることができる
• Reactと一緒の構文で書ける Preactで記述することができる
  参考：Preactの始め方&Reactとの違い
  

ビルド工程なし & リクエスト時レンダリング

• DenoはDeno DeployというCDN Edge環境で動作することを想定されている。
• デプロイ時にTypeScript/JSXのソースコードをビルドしない。
  -> リクエスト時にサーバーサイドでビルドしたHTMLを返却する
  -> レスポンスの速さ < リリース速度を重視している

ランタイムがゼロ & ハイドレーションの最適化

• 今主流のSPAでなくMPAを選定している
  • SPAを利用した場合、静的なページでもJSが呼び出されてしまう。
  • MPAを採用することで、静的なページを作成した時にJSの読み込みがゼロになる。(Zero runtime overhead)
• アイランドアーキテクチャ設計の採用
  • 静的な画面だけを作るだけなら問題ないが、インタラクティブな画面やコンポーネントも利用したい場合がある
  • アイランドアーキテクチャの採用で上記の課題を解決する

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

• アイランドアーキテクチャはAstroが最初に提唱したWebアーキテクトパターン。
• 画面のUIを静的なアイランドと動的なアイランドで分離させて設計を行う。
• これまでのSPAフレームワークでSSRを利用する場合、全てのコンポーネントをハイドレーションしていたが、アイランドアーキテクチャは必要なコンポーネントのみハイドレーションを行う。
  • 基本はサーバーサイドで静的なHTMLを生成する。
  • 動的なコンテンツが必要なアイランドが存在する場合、クライアント側でレンダリングするためのJavaScriptを読み込むようになっている。
    ->部分的なハイドレーションを行うことで、JSの読み込みを最適化している

参考：SSR の知識ゼロから始める Angular Universal - ハイドレーションとは

なぜアイランドアーキテクチャを使う?

• 先ほども説明したが、SPAフレームワークで静的なページを作成すると大量のJSが読み込まれる
• 例は「Hello World」のような簡易的なページが、大量のJSが読み込まれている

そもそも静的なページにはJS不要だよね？ というところから生まれたアーキテクチャになります。

ケーススタディ (vs Next.js)

Freshの例が見当たらなかったので、類似のアイランドアーキテクチャを採用しているAstroのAstro MPA vs. SPAを参考しますが Next.js をベンチメークに置いた検証で以下の結果が計測されました。

• vs. SPA (Next.js) - 94% JavaScriptを削減
• vs. SPA (Next.js) - 34% ロードが速い
• vs. SPA (Next.js) ‒ ネットワーク使用量を65%削減

SPAの時代は終わったの?

• そんなことはなく、動的なパーツが多いWebアプリはSPAの方が適している
  • そもそもSPAフレームワークは動的なWebアプリを作るために生まれた
• 今の流行的にとりあえずNext.jsで作れば良いという思想に対してのアンチテーゼとして生まれたのではないかと考えている

これからフロントエンドエンジニアはSPA or MPA でより用件に適したフレームワークを選定する必要があるというのがまとめになります。

最後に

Devトークでフロントエンドエンジニアの方と意見交換を募集しております！
よろしければ一緒に技術についてお話ししましょう