HonoXって知ってますか?
ここ最近、HonoというなんかイケてるTypeScriptのフレームワークがあるらしいよ。というのはチラホラYouTubeなどでも聞くようになりました。
しかし、React・Next.jsはあってもHonoでつくられているWebサイトはこれ。などの紹介はなく、まだまだ一部の人のオモチャのような感じがあります。
実際にWebサイトつくるイメージがわかないとそりゃ情報の多いNext.jsになりますよね。ってことであまり紹介されていないHonoをパワーアップしたメタフレームワークHonoXについてざっくりと説明させていただきます!
その前にHonoって?
Honoは日本人の和田 裕介(@yusukebe)さんが、Cloudflareで動くフレームワークが欲しいと開発したTypeScriptフレームワークです。
とても軽量で、どこでも動き、ライブラリを入れなくてもほとんどのことができるくらい、いろんな機能が入っています。書き心地はNode.jsフレームワークのExpressに似ています。
HonoXとは
HonoXは、フルスタックのウェブサイトやWeb APIを作成するためのシンプルで高速なメタフレームワークです。ビルドにはViteが使用されています。開発者チームはHono開発者と同じです。
HonoXのポイント
- JSXでレンダリング
- ファイルベースルーティング
- 必要な部分だけCSRも可能(islands)
- Reactフックが使える
- レンダリングが選べる
- SSGもできる
- もちろんHonoの機能が使える
- Web標準API準拠でどの環境でも動く
- RPCによる型安全なAPI呼び出し
- とにかく軽くて速い
npm create hono@latest
通常のHonoをインストールコマンドを実行して、テンプレート選択でx-basicを選択してください。
すると、プロジェクト構成がこんな感じで作成されます。
├── .wrangler
| ├──state/v3
|
├── app
│ ├── global.d.ts
│ ├── routes
│ │ ├── _404.tsx
│ │ ├── _error.tsx
│ │ ├── _renderer.tsx
│ │ |
│ │ └── index.tsx
│ └── client.ts
| ├── server.ts
| └── style.css
|
├── node_modules
| ├──.bin
| ├──.mf
|
├── public
| ├──.assetsignore
| └──favicon.ico
|
├── package.json
├── package-lock.json
├── tsconfig.json
├── vite.config.ts
└── wrangler.jsonc
HonoXの特徴
ここからはHonoXの特徴をこんなことできるよ。という感じで解説していきます。
JSXでレンダリング
HonoXはReactで知られるJSXが使えます。
Hono独自のJSXでサーバーサイドにてレンダリングされ、ユーザーにはHTMLが返されます。仮想DOMは生成されないのでとても軽くなります。
islandsフォルダに置くクライアントサイドレンダリングのJSXは軽量な仮想DOMが使用されています。
ファイルベースルーティング
HonoXはNext.jsと同様にファイルベースルーティングです。
routesフォルダ内にある.tsxファイルがファイル名がそのままページのURLになり、ネストさせることも容易です。
ニュースページで一覧、詳細ページという構成であれば、
├── news
| ├── [id].tsx
| └── index.tsx
とすれば、一覧ページとページIDごとの詳細ページが簡単に作成できます。
[slug].tsxとすればWordPressのようなスラッグごとのページができます。
必要なところだけクライアントサイドレンダリング
HonoXはNext.jsのようにここはサーバーサイドレンダリングで動的なUIのところはクライアントサイドレンダリングにすることが可能です。必要な部分だけJSが動き、高速にページが表示されます。クライアントサイドレンダリングにはReactのように仮想DOMによって差分計算されます。
クライアントサイドレンダリングされるtsxファイルを指定する方法は2種類です。
- islandsフォルダにtsxファイルを置く
- 先頭に
$をファイル名につける
Reactフックが使える
クライアントサイドレンダリングされたコンポーネントではなんとuseStateなどのReact互換のフックが使えます。
ドキュメントには「ReactフックについてはReactのドキュメント見れば学べます。」と書いてあります。
useState()
useEffect()
useRef()
useCallback()
use()
startTransition()
useTransition()
useDeferredValue()
useMemo()
useLayoutEffect()
useReducer()
useDebugValue()
createElement()
memo()
isValidElement()
useId()
createRef()
forwardRef()
useImperativeHandle()
useSyncExternalStore()
useInsertionEffect()
useFormStatus()
useActionState()
useOptimistic()
Reactでレンダリングすることもできる
Honoは特定のUI技術に依存しません。
HonoXは BYOR(Bring Your Own Renderer) という考え方を採用していて、好きなレンダラーを使っていいよ。とされています。
つまり、HonoJSXじゃなくてReactのJSXのレンダリングがいいから使いたい場合、Reactが使えます。(Reactはフレームワークじゃなくてライブラリですしね)
Reactを使いたい場合、Reactをインストールします。
npm i @hono/react-renderer react react-dom
npm i -D @types/react @types/react-dom
Reactのレンダラーを使う場合、Reactの仮想DOMを使うレンダリングになります。
SSGもできる
HonoXはSSG(静的サイト生成)も可能です。
Honoの機能が使える
HonoXの中身はHonoなので当然、Honoの豊富な機能が使えます。
Honoには認証(JWT、Basic)、CORS、テスト、バリデーションなどのWeb開発に必要な、豊富な機能が含まれています。
ライブラリに依存しなくても、さまざまな機能が使えます。
もちろんライブラリを追加することも可能です。
Web標準、どのランタイムでも動く
HonoはWeb標準API(MDNで定義されている)に基づいています。つまり、フレームワーク固有の独自ルールに縛られることがなく(ロックインがなく)、Honoを通じて学んだ知識はそのままWeb開発の基礎力として蓄積されます。
また、Cloudflare Workers、Deno、Bun、AWS Lambda、Node.jsなど JavaScriptが動く環境であればどこでも動作します。 これにより、最初は慣れているNode.jsで開発し、途中でCloudflare Workersへ移行するといったインフラの変更も、アプリケーションコードをほとんど書き換えることなくスムーズに行えます。インフラに縛られないという自由は、長期的な運用において大きな強みとなります。
デプロイも簡単です。
RPC
バックエンドとフロントエンドで型定義をしてくれるRPC機能を搭載しています。
APIのエンドポイントやレスポンスの型を自動で推論してくれるため、型安全にAPIを呼び出すことができます。
Swaggerなどのドキュメント管理や手動での型定義が不要になり、型安全な状態でAPIを呼び出すことができます。 バックエンドの仕様変更も即座にフロントエンドの型エラーとして検知できるため、開発効率と保守性が向上します。
とにかく軽いから速い
Honoのコア機能は14KB程度です。これはReactなどのライブラリや、Expressなどの一般的なサーバーサイドフレームワークと比較しても圧倒的に軽量です。 コードサイズが小さいことは、読み込み時間の短縮だけでなく、Cloudflare WorkersなどのEdge環境におけるコールドスタート(起動時間)の高速化に直結します。
HonoXはどんなサイトに向いているのか
Hono作者のyusukebeさんはこうおっしゃってます。
HonoXの得意なこと、逆に不得意なところが分かってきました。
・ 得意 - インタラクションの少ないWebサイト
・ 不得意 - インタラクションの多いWebアプリ
そもそも、ページごとにフルHTMLをサーバサイドでレンダリングするMPA = Multi Page Applicationを作るためのフレームワークです。
ですので、SPA = Single Page Applicationを作ることはできない、もしくは超不得意です。
ReactベースのNext.jsに比べて、圧倒的に軽く、高速なHonoXですがクライアントサイドレンダリングがベースのものと比べるとどうしてもインタラクティブなUIには弱いようです。
クライアントサイドレンダリングのislands Architectureでほとんどをやれば可能かもしれませんが、それなら得意なNext.jsでやるべきですよね。(圧倒的にエコシステムが整っているのはNext.jsです)
HonoXはこんなサイトが良さそう
HonoXはインタラクションの少ないWebサイトが向いているということは、Reactを使わず、WordPressやRuby on Rails、Laravelだけで制作されたWebサイトは置き換えることができそうです。
- ブログや記事がメインのサイト
- コーポレートサイト、LP
- ECサイトなど
それ以外にも、そもそもTrelloやNotionなどのようなWebアプリにする必要があるサイトも実際はそこまで多くはないはずです。
どんなUI/UXにしたいかに当然よりますが、HonoXは今後有力な選択肢になるかもしれません。
HonoXの今後
HonoXはまだアルファ版
そんなHonoXですが、まだアルファ版であり、正式なリリースはされていません。破壊的な変更があるかもしれません。(ここまで説明しておいてすいません。)
どれくらいの変更があるかはわかりませんが、まだ慎重に見ながら採用したほうが良さそうです。ただベースとなっているHono本体はすでに非常に安定しており、本番運用もされています。
HonoXはバックエンドとしてはExpressに近いシンプルで直感的な書き心地を持ち、フロントエンドとしては Reactに近いJSXやフックを使った開発体験を提供してくれます。
さらに、ベースが Web標準技術で作られているため、特定のベンダーや環境にロックインされることがありません。 これはつまり、技術的に廃れにくく、学んだ知識が無駄にならないということです。
みんな使いましょう
正式リリースの時期については、
使用例が増えて、フィードバックができったらベータ、そして「1.0」へと進んでいきたいと思います。
とのことなので、使用例を増やして「1.0」がリリースされるのをみんなで待ちましょう。
ありがとうございました。
実例
