【ITニュース解説】You don’t need NPM to ship fully-featured apps.

現代のウェブ開発では、プロジェクトの選択肢として「人気のある」技術スタックを選ぶことがよくある。しかし、その人気の裏で、開発の複雑さが増大したり、開発者体験が損なわれたりする問題も指摘されてきた。さらに、ソフトウェアの安全性が脅かされるようなニュースも耳にするようになり、既存のツール群に代わる「次世代のツール」が求められている状況がある。このような背景から、Go言語のエコシステムで、新しいフルスタックのウェブアプリケーションフレームワークが開発された。このフレームワークは、リアクティブな状態管理、コンポーネント指向、ライフサイクル制御、デフォルトでのサーバーサイドレンダリング（SSR）を特徴とし、HTTP APIを使わないアーキテクチャを採用している。Go言語で動的かつ安全で高速なウェブアプリケーションを開発し、開発者により良い体験を提供することを目指している。

このフレームワークの基本的な考え方として、現代のフロントエンドフレームワークが持つ概念を、より独立した基本的な要素（プリミティブ）に分解し、開発者がこれらを個別に、または組み合わせて自由に使えるようにするという哲学がある。これは、フレームワークが開発者に特定のやり方を「強制する」のではなく、より柔軟な制御を可能にすることを重視している。

ウェブUIの核心であるHTMLの動的な更新について、このフレームワークは独自の解決策を提示する。従来のリアクティブフレームワークは、状態の変化時に仮想的にUIを再構築し、差分を計算して適用することでDOM（Document Object Model）操作を抽象化する。一方、JavaScriptやjQueryのようなライブラリは、要素を直接指定してコンテンツを操作する。このフレームワークは、前者のような強制的な抽象化ではなく、かといって後者のような意味論のない文字列操作でもない、新しいアプローチを採用している。

その核となるのが「Door」という概念である。Doorは、ウェブページのDOMツリーの中に存在する動的なコンテナであり、実行時にその内容を更新したり、完全に置換したり、削除したりできる。これは型安全に実現され、開発者はより確実な方法でUIの変更を制御できる。Doorは内部的にツリー構造を形成し、各Doorは独自のライフサイクルを持つ。DoorはDOM操作の基本的なツールでありながら、これ単体でも多くのシンプルなUI変更を可能にする、より高度な抽象化の基盤となる。

次に、アプリケーションの状態管理について、このフレームワークは「Beam」という概念を導入している。現代のUIにおける状態は、一般的に「UIの表示内容を決定する引数」と「UIの再描画をトリガーするきっかけ」という二つの役割を果たす。しかし、既存のフレームワークでは、状態がUIのレンダリングとは直接関係のない「コミュニケーション」や「中間データ」として使われ、複雑な連鎖的な副作用を引き起こすことがあると指摘されている。 Beamは、まず「コミュニケーションの基本要素」であり、その上で「レンダリングを駆動するきっかけ」としても使えるという考え方を持つ。Beamは値の変化ストリームとして機能し、その値を読み取ったり、変化を購読したり、監視したり、他の値から派生させたりできる。BeamとDoorを組み合わせることで、Beamの値が変化したときに、関連するDoorのコンテンツを自動的に更新することが可能になる。Beamは特定のUI要素に縛られず、Doorのツリー構造と連携することで、一貫性のあるレンダリングを保証する。

さらに、ウェブアプリケーションのルーティングについては「Path Model」というアプローチを取る。従来のウェブ開発では、URIのパス部分がサーバーのファイルパスに対応し、クエリパラメータがデータの受け渡しに使われることが多かった。現代のフロントエンドフレームワークではパス自体が抽象化されているが、パス構造がUIコンポーネントやファイルツリーと密接に結合していることがあり、柔軟性に欠ける場合がある。 Path Modelは、ルート自体を変化するデータ、つまり状態として捉える。各ページルートは、URIのマッチング、デコード、エンコードを行うための構造体として定義される。これにより、複数のパスパターンを宣言したり、型安全なパラメータキャプチャを行ったり、幅広い型のクエリパラメータを利用したりできる。Path Modelの情報はBeamを通じてページのレンダリング関数に渡され、そこから特定の情報を取り出して、その値に基づいて動的なコンテンツをレンダリングできる。また、Beamの値の変更を通じて、プログラムからリンクを生成したり、ページを移動させたりすることも可能である。このアプローチは、より多くのコード記述が必要になる場合もあるが、型安全で予測可能であり、ルーティングの設計においてこれまでにない自由度と信頼性を提供する。

開発者の生産性を高めるためのツールキットも充実している。 イベントバインディングでは、対象となるUI要素の前に特別な属性を記述するだけで、イベントリスナーを簡単かつ型安全に設定できる。これにより、保護されたHTTPエンドポイントが生成され、イベントの発生からサーバーでの処理、その後のUI更新までを一貫して扱えるようになる。この属性には、イベントの処理フロー制御、並行処理ルール、前処理、エラーハンドリングなどの詳細な設定が含まれる。 UIの処理中であることをユーザーに伝えるための「インジケーターAPI」も提供される。これは、特定のクラスの追加、属性の設定、コンテンツの変更などによって、一時的な視覚的フィードバックを提供する。処理が完了し、関連するUIの変更が適用されると、これらのインジケーターは自動的にクリアされる。 複雑なユーザーインターフェースで発生しがちな、連続したフォーム送信やダブルクリックのような重複するアクションを管理するためには、「緻密な並行処理管理」機能が用意されている。これは、処理の遅延（デバウンス）、新しいイベントのキャンセル（ブロッキング）、イベントの順次処理（シリアル）、優先度に応じた処理、特定の境界内でのイベント管理（フレーム）といったメカニズムを提供し、UIが予期せぬ動作をすることなく、高度に動的なインタラクションを正確に制御できる。 また、JavaScriptとの統合も簡単である。描画や一部のUIタスクなど、クライアント側での処理が適している場合には、JavaScriptを柔軟に利用できる。フレームワークの内部でカスタムのリクエストハンドラを宣言し、それをJavaScriptからAPIのように呼び出したり、JavaScriptで定義したハンドラをGo言語から呼び出したり、Go言語のデータをJavaScriptに渡したりすることが可能だ。

このフレームワークに関して寄せられる一般的な懸念に対しても、開発者は見解を示している。 「サーバーでのイベント処理は遅延を招き、ユーザー体験を損なうのではないか」という点については、ネットワークの応答時間（ping値）が100ミリ秒未満であれば、ほとんど瞬時に感じられ、200ミリ秒以上でも許容できる範囲だと説明している。また、従来のフロントエンドフレームワークでも、イベントが最終的にHTTPリクエストをトリガーするならば、本質的な遅延の差はないと指摘し、サーバーをユーザーの近くに配置することが重要であると述べている。 「アニメーション機能が不足しているのではないか」という質問に対しては、主にSaaS製品、ビジネスプロセス自動化ツール、顧客ポータル、管理パネルといった、アニメーションを多用しないアプリケーションを主なターゲットとしていると回答している。基本的なCSSと連携した遷移は可能であり、もし需要があればさらなる対応を検討すると付け加えている。 「一部のAPIが冗長である」という意見に対しては、開発者に最大限の制御と柔軟性を提供することを意図しており、必要であれば開発者が独自にシンプルなラッパーコードを書くことで、この問題を解決できると説明している。失われた機能をハックするよりも、独自のラッパーを作る方がはるかに簡単だという考え方である。 学習曲線については、既存のツールとは異なるため、慣れるまでに時間はかかるが、一度習得すれば、非常に堅牢で機械的な感覚で開発でき、クライアントとサーバー間の摩擦がないため、伝統的なスタックには戻れないほど高い生産性と開発者体験が得られると述べている。

このフレームワークは「doors」という名前であり、開発者体験やパフォーマンスが向上し、ドキュメントやテストも一定レベルまで整備された。このフレームワークは有償製品だが、開発用途および非商用プロダクションでの利用は無料となっている。また、BUSL-1.1というライセンスの下で提供され、各バージョンはリリースから4年後にオープンソース化される仕組みになっている。これは、フレームワークの持続的なサポートと継続的な改善を目的としている。開発者は、ユーザーからのフィードバックを積極的に求めており、GitHubでの質問や意見交換を通じて、フレームワークをさらに発展させていきたいと考えている。