Misago、パフォーマンス向上と保守性向上のため React.js から HTMX へ移行

Misago は冗長なコードを排除し、パフォーマンスを向上させるために React.js から HTMX へ置き換えています

Misago は、フロントエンドのアーキテクチャを React.js ベースの Single Page Application (SPA) アプローチから、HTMX を活用したサーバーサイドレンダリングへと移行しています。この転換は、初期ロードや SEO のために Django テンプレートとして構築し、インタラクティブ性のために React コンポーネントとして再度構築するという「二重実装」の問題を解決することを目的としています。この問題は、保守コストの増大とレスポンス時間の低下を招いていました。

React.js と Django のハイブリッドアプローチにおける問題点

以前のアーキテクチャでは、バックエンドとフロントエンドの間で複雑な同期が必要であり、いくつかの技術的なボトルネックが生じていました：

• 重複した実装: ほとんどのページが Django テンプレートと React コンポーネントの両方として存在していたため、UI の変更を行うたびに2つの異なる場所を更新する必要がありました。

• 開発の摩擦: Django テンプレートを編集するカスタマイザーは、変更が一時的に表示された後、React のクライアントサイドレンダリングによって上書きされる現象（フラッシュ）に直面することがよくありました。

• レイテンシの増加: React アプリを「事前準備（pre-bake）」するためにデータを JSON にシリアル化する必要があり、サーバーのレスポンス生成が遅延していました。

• バンドルの肥大化: 翻訳メッセージが django.po と djangojs.po の両方のファイルに重複して存在し、ユーザーの初期ダウンロードサイズが増大していました。

• パフォーマンスの低下: 大規模な JavaScript バンドルは、特に古いモバイルデバイスにおいてパフォーマンスに悪影響を及ぼしていました。

• プラグインの複雑化: プラグイン開発者は Django テンプレートと React コンポーネントの両方を実装する必要があり、サイトのビルドプロセス内に JavaScript のビルドステップを必要としていました。

フォーラムのインタラクティブ性に HTMX が選ばれた理由

フォーラムソフトウェアは、通常、完全に流動的な SPA 体験よりも、モデレーションアクション、投票、通知の更新といった、孤立した「アイランド（島）」内でのインタラクティビティを必要とします。HTMX を使用すると、ページ全体をリロードすることなく、インタラクション時に HTML の一部を新しいサーバーサイドレンダリングされた HTML と入れ替えることで、これらの特定の領域を動的にすることができます。

HTMX を使用することで、Misago はこれらのインタラクションのための JSON シリアル化や専用の JavaScript コンポーネントの必要性を排除します。バックエンドは、要求された「アイランド」に必要な HTML フラグメントを返すだけでよく、ブラウザはそれを既存のページ内に差し込みます。

JavaScript バンドルサイズへの測定可能な影響

初期の移行ステップにより、すでに JavaScript の総占有面積の削減が示されています。例えば、「Forum options」ページを「Account settings」に置き換え、「Threads lists」を Django ビューと HTMX を使用して書き換えた結果、misago.js は以下のように削減されました：

• Account settings の移行: misago.js を 37kb（gzip後 17kb）削減。
• Threads lists の移行: misago.js を 48kb（gzip後 8kb）削減。

これらの変更が行われる前、Misago 0.39 のベースライン JS サイズには、679kb の vendor.js と 615kb（非圧縮）の misago.js が含まれていました。

HTMX への移行に関するコミュニティの視点

この移行を巡る技術的な議論では、サーバーサイドレンダリングのシンプルさを支持する層と、クライアントサイドの状態管理の必要性を主張する層との間で意見が分かれています。

フォーラムにおける HTMX の利点

多くの開発者が、フォーラムは主にテキストベースのコンテンツを配信するため、HTMX の理想的なユースケースであると主張しています。ある寄稿者は次のように述べています：

HTMX はフォーラムソフトウェアに非常によく適合していると思います。フォーラムのウェブサイトは主に非インタラクティブなコンテンツを配信します... HTMX を使えば、サーバー送信イベント（server-sent events）を介して部分的なレンダリングやライブアップデートを行うことができます。

制限事項とトレードオフ

他の開発者は、HTMX は「リッチな」インタラクティビティや高頻度の DOM 更新には苦戦する可能性があると指摘しています。あるユーザーは、商品リストページでの否定的な体験を共有しました：

私が直面した問題は、すべてを一つの「レスポンス」としてまとめて動作させようとすると、体験全体が非常に遅くなったことです。フォーム全体の HTML をすべて送り返すのは... 結果が6つ以上になると、目に見えるほどのラグが発生しました。

別の批判は、React と比較した際のきめ細かな DOM 照合（reconciliation）の欠如に焦点を当てていました：

React はそのような仕組みを中心に設計されています。シームレスな DOM 照合をサポートするために、内部で何らかの魔法のような処理を行っています... もし誰かが htmx のような SSR 的なものをリリースしたとしても、何かが足りないと感じてしまうかもしれません。

今後の移行戦略

Misago は、個々のコンポーネント（Navbar、スレッドリスト、ユーザープロフィールなど）をリリースごとに一つずつ移動しながら、段階的に HTMX へ移行していきます。この移行期間中、一部のページは標準的なマルチページアプリケーション (MPA) として、ページ全体のリロードを伴う形で一時的に機能する場合があります。ただし、投稿への「いいね」や投票のように、ユーザー体験の摩擦を避けるために AJAX や HTMX が使用される箇所は除きます。