Hyperflask – フルスタック Flask および Htmx フレームワーク

(hyperflask.dev)

11 ポイント投稿者 GN⁺ 2025-10-17 | 1件のコメント | WhatsAppで共有

Flask ベースのバックエンド中心Webフレームワークで、複雑なフロントエンド管理なしに高速でシンプルな状態管理を提供
HTMXと組み合わせたコンポーネントアーキテクチャを導入し、サーバーベースのインタラクティブUI構築が可能
ファイルベースルーティング、esbuild + TailwindCSS アセットパイプライン、自動化されたデプロイ環境など、モダンなWebスタックを統合
メール送信(MJML)、バックグラウンドジョブ、SSEベースのプッシュ、翻訳、認証など多様な基本機能を内蔵
コンテナベースの開発・デプロイ環境の標準化と VS Code 統合により、容易な設定とクラウドデプロイを支援

概要: Flask ベースのバックエンド中心Webアプリフレームワーク

Hyperflaskは Flask 上で動作するPython Webフレームワークで、バックエンド主導の設計を志向
フロントエンドの状態管理の複雑さを減らし、サーバー中心の簡潔なアーキテクチャを提供
HTMX、TailwindCSS、esbuild などのモダンなWeb技術を標準搭載
HTMX 統合により、ページ全体をリロードせずにリアルタイムな相互作用を実装できる
コンポーネントアーキテクチャにより、バックエンドおよびフロントエンドのコンポーネントを再利用可能
- Flask 環境にコンポーネント中心の構造を導入し、フロントエンドとバックエンドのコンポーネントを Jinja テンプレートで直接利用可能
- HTMX と組み合わせたサーバーバックエンド型コンポーネントを作成でき、React や Web コンポーネントとも自然に統合される
- コードの再利用性と保守性を高め、大規模アプリ開発にも適した構造を提供
ファイルベースおよびアプリベースのルーティングをサポート
- Python コードと Jinja テンプレートを組み合わせた新しい .jpy ファイル形式を使用
- Astro のページシステムに着想を得て、ルート定義と UI 構成を1か所で管理可能
- これによりルーティング設定が単純化され、新しいページの追加も直感的
オープンエコシステム
- Hyperflask は独自コードベースが小さく、複数の Flask 拡張機能を有機的に組み合わせて構成されている
- 各拡張機能は独立したプロジェクトとして管理され、自由に選択・組み合わせ可能
- すべてのプロジェクトは GitHub のHyperflask 組織で公開されており、ユーザーに合わせたフレームワーク構成を促進
“Batteries Included”
- MJML メール送信、dramatiq バックグラウンドジョブ、SSE ベースのリアルタイムプッシュ、gettext ベースの翻訳(i18n)
- 認証およびセッション管理、画像最適化とストリーミング、静的コンテンツ生成など
- 追加設定なしですぐに使えるプロダクションレベルの機能セットを提供
- SQL 中心 ORM(sqlorm)、SQLite に最適化
環境設定とデプロイ
- コンテナベースの開発/運用環境を標準化し、環境設定の問題を最小化
- VS Code との緊密な統合により、ローカル開発とデバッグが容易
- VPS や主要クラウドサービスへの容易なデプロイをサポート

要約

Hyperflask は Flask エコシステムを拡張し、モダンなフルスタック Python Web開発体験を提供する次世代フレームワーク
HTMX とコンポーネントシステム、ファイルベースルーティング、コンテナで標準化された開発環境により、最小の設定で最大の生産性を実現

1件のコメント

GN⁺ 2025-10-17

Hacker Newsの意見

hyperflask の作者として、長い時間をかけて準備してきたプロジェクトをついに公開できてうれしく思う
詳しい発表記事はこちらで確認できる
いろいろなフィードバックを聞いてみたい
- こういう形がバックエンドに依存しないライブラリ形式だったら、もっと良かった気がする
  すでに Django プロジェクトが 100 万行以上あって簡単には変えられないので、Django アプリに手軽に適用する方法があるのか気になる
- htmx 開発者として、このプロジェクトは本当にすばらしく見える
- 同僚が flask/htmx/sqlalchemy の組み合わせで社内アプリを作って良い結果を出していたが、オープンソース化の承認を得られなかった
  なので hyperflask の新しい試みに期待している
- なぜ ORM に sqlorm を選んだのか気になる
  長い間 Python 開発から離れていたが、みんな SQLAlchemy を使っていると思っていたし、sqlorm についてはなじみがない
- 新しいフレームワークが HTMX を取り入れているのが印象的だ
  HTMX は JS や React を置き換えるさまざまな新しい潮流を刺激している
  Python と Flask の組み合わせを好む人も多いだろうし、サーバーサイド HTMX ではコンポーネントが中核になる
  それに、ホームページが FastHTML より目に優しいのも長所だ
  harcstack.org と比べると
```
Language: Python vs. Raku  
Web framework: Flask vs. Cro  
ORM: ?? vs. Red  
Components: どちらもあり  
HTML: テンプレート vs. 関数型  
CSS: DaisyUI/Tailwind/Bootstrap vs. Pico  
```
  こうした選択肢のおかげで、はるかに広いユーザー層を引きつけられそうだ
  比較対象の HARC stack は、Elm 言語のサーバーサイド版のように HTML を関数型で扱いたい人や、Tailwind の非正規化にアレルギーがある少数派には魅力的に映りそうだ
htmx で Web アプリを開発していて「行き止まり」だと感じたことがある
主な問題は、フロントエンドアプリケーションの状態を URL に保存しなければならない点だ
複数の領域、ウィジェット、ポップアップなど、それぞれがローカル状態とナビゲーションを必要とする現代的な UI では、すべての状態を 1 つのグローバルな URL に収めるのがとても難しい
必要に応じて状態を URL に入れないようにするのも、さらに難しい設計になる
こうした問題は React や Vue のように独自の状態ストアを提供するフレームワークなら簡単に解決できる
phpBB フォーラムのような構成なら問題ないだろうが、今どきのユーザーはもっと進んだ体験を期待している
- 状態を URL にだけ保管しなければならないわけではない
  サーバーストア、セッション、localstorage、Cookie などさまざまな方法がある
  たとえばユーザーのアプリレイアウトのカスタマイズには URL は不要だが、検索結果のように共有機能が必要な場合は、検索条件が必ず URL に入っているべきだ
  何を達成したいのかを考える必要がある
  それに「現代的 UI」という名目で、多数のウィジェットやポップアップを 1 画面 / 1 URL に全部詰め込むのは、むしろ過剰な複雑さになりうる
  React/Vue が提供する状態管理は、すでにサーバー側で十分管理できるものの重複になっていることも多い
- ハイパーメディア方式でも十分に複雑な UI を扱える
  何もかも URL にこだわる必要はない
  セッションや Cookie、タブ ID などを使って状態をタブごとに共有 / 分離できるし、バックエンドの DB から状態を取得すればいい
  ハイパーメディアはリアルタイム / マルチプレイヤー環境でも優れている
  むしろ HTMX の欠点は、状態をバックエンドにもっと置いていないことのほうで、いっそもっと大胆に進んでほしい
- これは単に自分のユースケースに合っていないだけだと思う
  React/Vue が「簡単」だと思うのも面白い
- React や Vue でも、ユーザーが期待するあらゆる問題を解決できるわけではないと思う
- 複雑さが極端に高いケースでない限り、実際には htmx（unpoly、alpinejs、localstorage の組み合わせ）でほとんどのケースを無難に処理できている
hyperflask で興味深いコンセプトを見つけた
- コンポーネント実装: リンク
- ビューとコントローラーを 1 ファイルにまとめる方式: リンク
  ただ、コンポーネントは実質的には内部的に普通のマクロにすぎないので、いっそ直接マクロを書いたほうがよくないかとも思う
  Flask を選んだ理由も気になる
  以前、/dev/push という似たアプローチを試したあと、FastAPI + Jinja2 + Alpine.js + HTMX の組み合わせに移った
  FastAPI も API 専用ではないと気づき、非同期サポートが必要だったので選んだ
  Flask も好きだが、限界を感じたことがある
- ビューとコントローラーを 1 ファイルにまとめる方式は、昔の PHP 開発を思い出させる
  プロジェクト規模によっては開発が確かにシンプルになって、それが利点だった
- FastAPI + HTMX の組み合わせも非常に効果的だと思う
Django では経験上、admin scaffolding 機能のおかげで診断やカスタマーサポート用の UI を自作する必要がほとんどなかった
他のフレームワークベースのプロジェクトではこうした機能を自前で実装することになり、出来上がりが Django ほど満足のいくものにならないことが多かった
Hyperflask のように魅力的に見えるフレームワークは多いが、Django の admin フレームワークを手放すのはそれだけ大きな代償だ
実際に Django admin の代替や置き換えパターンを見つけた人がいるのか気になる
- 自分も同じことを感じた
  FastAPI に移ってから Django でいちばん恋しかったのは、プロジェクトを構成するさまざまなアプリだった
  マイグレーション、静的ファイル、テンプレートなど、機能ごとにまとまっている構造がどれほど便利だったかを後になって実感した
- 自分はたいてい Supabase を使っている
  Supabase UI で管理者をトレーニングして、急ぎの管理作業を任せることもある
  あるいは可能なら Airtable をバックエンドとして使うこともある
  でも結局、たいていは Django admin がとても恋しくなり、Django + HTMX の組み合わせがいつも魅力的に感じられる
- Flask-Admin もあるが、Django Admin よりずっとシンプルだ
  今後こうした問題を解決していきたい
いろいろなフレームワークで HTMX を使ってきた結果、Go + Templ + HTMX の組み合わせは、多機能さとシンプルさをうまく両立していると思う
- 自分の経験では Go は冗長すぎて、むしろ Go + Templ + HTMX から Flask + Jinja + HTMX へ移ろうかと考えている
  Go のテンプレート定義のやり方は面倒に感じる
- 次にぜひ試してみたい組み合わせが FastAPI + Jinja2 + HTMX だ
  自分は今このスタックを使っている
hyperflask は Flask と htmx の哲学とずれている感じがする
抽象化レイヤーが多すぎるし、htmx との統合ポイントもあまり見えない
FastHTML のように htmx が組み込まれた方式を期待していた
- FastHTML は本当に楽しく使っている
プロジェクトごとに starfield デモ（星空エフェクト）が出てくると、いつも速度調整機能やマウスカーソルを追従する効果がほしくなる
次の Hyperflask バージョンで追加されるとうれしい
プロジェクト自体はすばらしいし Htmx も好きだが、最近は Datastar にも注目している
- コンソールで以下のコードを実行すると、速度調整などさまざまな効果を付けられる
```
new WarpSpeed("warpdrive", {
  "speed": 20,
  "speedAdjFactor": 0.03,
  "density": 2,
  "shape": "circle",
  "warpEffect": true,
  "warpEffectLength": 5,
  "depthFade": true,
  "starSize": 3,
  "backgroundColor": "hsl(224,15%,14%)", 
  "starColor": "#FFFFFF"
});
```
- もしかしてこういう機能のことだろうか
- nova.app は今まで見た中で最高だ
HTMX ベースで完全な Fullstack Async 体験を求めるなら、Litestar も参考になる
最初に見たとき、Python コントローラーファイルに HTML テンプレートを直接付け足す構造がなぜ必要なのか理解しづらかった
単純な render 関数 1 つを省くために複雑になっているように感じた
自分が見落としているポイントが何なのか気になる
- この方式は、htmx が重視する Locality of Behavior の原則と通じるものがある
  JavaScript 界隈の Astro Pages から着想を得ている
  実際、開発者体験も良かった
  - Locality of Behaviour の説明
  - Astro Pages の案内
Flask の限界を語って「なぜ FastAPI ではないのか」と言う人は多いが、個人的には Litestar が最良の代替だと思う
Litestar は htmx サポートを標準で提供している
詳しくはこちらで見られる

Hyperflask – フルスタック Flask および Htmx フレームワーク

概要: Flask ベースのバックエンド中心Webアプリフレームワーク

要約

関連記事

1件のコメント

Hacker Newsの意見