Denoのフロントエンドフレームワークの比較
要約
フレームワーク
おそらく、現時点で最もGitHubのスター数が多いDeno製フレームワークです (2022/08時点で8.5K) カスタムハンドラーを実装することで、APIエンドポイントを作成することもできます。
プラグインシステムが実装されており、これによって様々なフレームワークやファイル形式(MDXなど)をサポートすることも可能です。 2022/10 追記) 現在は、開発がやや滞っているようです
v0.5.0現在、SSRやSSGなどの機能はサポートされていないものの、将来的には実装される予定のようです。 スタティックサイトジェネレータ
Denoで実装されたシンプルなスタティックサイトジェネレータ プラグインシステムによって拡張が可能
Adaptersという様々なプラットフォームを抽象化するための仕組みの導入が検討されているようです。 これが導入されれば、例えばDeno Adapterを実装することにより、Gatsbyが生成した本番向けの成果物をDenoで動かせるようになりそうです。 CSS
ビルドツール
Luath ※現在はしばらくメンテナンスされていなさそうです テストフレームワーク
Denoに組み込まれたテストランナ
現状はこれを使っておくのが無難だと思います
E2Eテスト
タスクランナ
Gitフックもサポートしています
依存管理
Import mapsとは、Denoやブラウザなどにbare specifierを認識させることができる機能ですが、これは依存関係の管理にも活用することができます。 基本的には、まずこのアプローチを試してみるのがよいのではないかと思っています。
利用しているフロントエンドフレームワークやツールなどがpackage.jsonを要求する場合は、こちらの使用も検討するとよいかもしれません。 あるアプリケーションやライブラリなどが依存するパッケージをdeps.tsという単一のファイルでまとめて管理する手法です。 シンプルではありますが、Tree shakingのことなども考えると、フロントエンド開発においてはあまり推奨されない手法だと個人的には思います。
CDN
Deno向けのモジュールは基本的にここから探すとよいでしょう
ブロックチェーンをベースに実装されているようです。
小さなスクリプトを配信することを目的としたモジュールレジストリです。
npmパッケージの利用について
Denoでは、以下のいずれかの手段などによりnpmパッケージを利用することができます。 また、これらの手法は併用することも可能です。
使用しているフレームワークや読み込みたいパッケージなどに応じて、適宜使い分けるとよさそうです。