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

221日前原文(hyperflask.dev)

概要

Hyperflask はFlaskベースの BETA版フレームワーク
バックエンド駆動型アプリ の構築と 状態管理 の簡素化
コンポーネントシステム や ファイルベースルーティング など多機能搭載
開発・運用環境 はコンテナ標準化、VS Code連携
拡張性 が高く、必要な部分だけの利用も可能

Hyperflaskの特徴

Flask を基盤とした Python製ウェブフレームワーク
HTMX や コンポーネントシステム を統合し、 インタラクティブアプリ の簡単構築
バックエンド主導で 状態管理の複雑化を回避
フロントエンドの“footgun” （落とし穴）を削減

コンポーネント駆動アーキテクチャ

Hyperflask独自のコンポーネントシステム を導入
フロントエンド（Web Components, React等） と バックエンド両対応
Jinjaテンプレート 内でコンポーネントを利用可能
HTMX により サーバーバックのインタラクティブコンポーネント 作成が容易

ファイルベースルーティング

ファイルベースルーティング をサポート
Pythonコード と Jinjaテンプレート を組み合わせた新ファイルフォーマット採用
Astro pages から着想を得た設計

充実した標準機能（Batteries included）

MJMLによるメール送信
バックグラウンドジョブ 実行
SSEによるプッシュイベント
多言語対応（翻訳）
認証、コンテンツストリーミング、画像最適化 などの機能

柔軟なコンテンツ運用

静的サイト生成 にも対応
ハイブリッドモード で 動的リクエスト時のみサーバーアクセス

標準化された開発・運用環境

コンテナ標準化 による 開発・本番環境の統一
VS Codeとの統合 でセットアップ・運用が容易
VPSや各種クラウドサービス へのデプロイも簡単

拡張性とエコシステム

Hyperflask本体は小規模なコードベース
多くのFlask拡張機能 をシームレスに統合
拡張や関連プロジェクト はHyperflask組織下で独立開発
必要な部分だけ 選択的利用 が可能
詳細・最新情報は Hyperflask公式GitHub および ロードマップ 参照

Hackerたちの意見

なんか、プロジェクトがスターフィールドのデモをやるたびに、どこかにスピードトグルがあるんじゃないかって探しちゃうんだよね。それに、マウスカーソルに追従してほしいなって思ってる。次のハイパーフラスクのウェブサイトのバージョンで実装されるかも！でも、プロジェクト自体はめっちゃいい感じ。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" });

└

これみたいなやつ？ https://data-star.dev/

└

https://nova.app/ は今まで見た中で一番いい。

いろんなフレームワークでHTMXを使ってみた結果、Go + Templ + HTMXが一番好きになったよ。汎用性とシンプルさのバランスがいい感じ！

└

次に試してみたいスタックはこれだね（今はFastAPI + Jinja2 + HTMXを使ってる）。

ハイパーフラスクの作者です。ずっとこのプロジェクトに取り組んできたので、やっと発表できて嬉しいです。こちらに発表記事を書きました: https://hyperflask.dev/blog/2025/10/14/launch-annoncement/ フィードバックもらえると嬉しいな！

└

Pythonとhtmxの大ファンとして…めっちゃ楽しんでる！すぐにチェックするよ！

└

ちょっと興味本位なんだけど、htmxの代わりにunpoly.jsやalpine-ajaxを考えたことある？もしあったら、なぜhtmxを選んだの？

└

これめっちゃいいね！純粋なFlaskでTailwind + DaisyUI + Bootstrap Iconsを使ってアプリを作ってるんだけど、まさにあなたが使ってるスタックと同じだね。ただ、正直言うとJSフレームワークなしで生のJavaScriptを書いてるだけなんだけど。

└

同僚がflask/htmx/sqlalchemyで内部アプリを作ったんだけど、素晴らしい結果が出たのにオープンソースにする承認が得られなかったんだ。君の作品を見るのが楽しみだよ！

└

よっ、俺はhtmxの人だ！これめっちゃいいね！

面白いコンセプトがいくつかあるね: - コンポーネント: https://hyperflask.dev/guides/components/ - ビューとコントローラーを同じファイルにまとめる: https://hyperflask.dev/guides/interactive-apps/ でも、これって足元をすくわれるかも。例えば、コンポーネントは実際には普通のマクロだから、じゃあマクロを使えばいいじゃん？フラスクを選んだ理由も気になるな。/dev/push [1] で似たようなアプローチから始めたけど、FastAPIが単なるAPI用じゃないってわかってから、FastAPI + Jinja2 + Alpine.js + HTMXに移行したんだ。ちゃんとした非同期サポートが欲しかったから。フラスクは好きだけど、制限を感じない？

これってFlaskやhtmxの本質に矛盾してる気がする。抽象化が多すぎるよね。それにhtmxとの統合が全然見えないんだけど？FastHTMLみたいにhtmxが組み込まれてるのを期待してたのに。

└

FastHTML大好き！

htmxを使ってウェブアプリを作ってみたけど、結局行き詰まった。主な問題は、フロントエンドアプリの状態がURLにあること。これじゃ現代のUIには柔軟性が足りないよ。いろんなゾーンやウィジェット、ポップアップがあって、それぞれにローカルナビゲーションやアクティベーション状態が必要なのに、全部を一つのグローバルURLに入れるのはすごく難しい。グローバルURLに全部を入れなくて済むようにアプリを設計するのも難しい。この問題は、ReactやVueがそれぞれの状態ストアを提供していて、状態を保持したり、ブラウザのタブ間で要素を共有するのが簡単だから、簡単に解決できる。phpBBフォーラムみたいにアプリを作るなら問題ないけど、今のユーザーはもっと良いものを求めてるよ。

└

あなたのユースケースには行き詰まりだよ、はっきり言っておくね。それに、ReactやVueのことを「簡単」だと思ってるのが面白い。

└

ReactやVueは、ユーザーが期待することを何も解決してないよ。

└

フロントエンドアプリの状態がURLにあることが主な問題です。状態を維持する方法はいろいろあって、サーバーストアやセッション、ローカルストレージ、クッキーなどがあるよ。例えば、ユーザーにアプリのレイアウトをカスタマイズさせたい場合、これはURLに入れる必要はないよね。次に、ユーザーが結果を共有できる検索機能を提供する場合、検索条件は確実にURLに含めるべきだよ。これは白黒つけられるものじゃなくて、アプリが何を達成すべきかを考える必要がある。 > 現代のUIでは、いろんなゾーンやウィジェット、ポップアップがある。これはHTMXの問題とは完全に独立してるけど、アプリの機能がすべて一つの画面やURLに収まる必要はないよ。「現代的」と「肥大化」の間には微妙な線があって、残念ながらその線は毎日越えられてる。 > ReactやVueはそれぞれの状態ストアを提供していて、状態を保持できる。多くの場合、サーバーサイドで既に利用可能なものを重複していることもあるよ。

└

すごく複雑なユースケースには向いてるかもしれないけど、私はhtmx（とunpoly）＋alpinejs＋ローカルストレージを使ってて、まだフィットしないケースには出会ってないよ。

└

ハイパーメディアはそれらすべてをうまくやってくれるよ。URLに全部詰め込む必要はないんだ。シンプルなセッションやクッキー、タブIDを使えば、状態をタブ間で共有したり、分離したりできる。あとはバックエンドのデータベースでルックアップすればいい。ハイパーメディアはリアルタイムやマルチプレイヤーに関してもずっと優れてる。HTMXの弱点は、バックエンドに十分な状態を持たせてないところかな。もっと過激になってもいいと思う。

Djangoを使った経験から言うと、管理用のスキャフォールディングは診断やカスタマーサービスのワークフロー用のUIを作るのにかなりの手間を省いてくれる。関わった他のフレームワークのプロジェクトでは、その部分を自分たちのコードベースで再構築することになって、余計な作業が増えて、結果もあまり良くなかったりする。HyperflaskのようなフレームワークにはDjangoに比べて魅力的な部分がたくさんあるけど、管理フレームワークを手放すのは大きな代償だね。他に成功しているパターンを見つけている人はいるのかな？

└

俺もそう思ったけど、fastapiに移行して一番恋しかったのはDjangoプロジェクトを構成するアプリケーションたちだね。マイグレーション、静的ファイル、テンプレートがプロジェクトの一つの側面にまとめてあるのはめっちゃ便利で、これがないと気づかなかった。

└

Flask-Adminはあるけど、Django Adminよりもシンプルすぎるかな。将来的にこの問題に取り組むつもりだよ。

コードをちょっと見てみたけど、ここにあるいくつかのコンセプトが気に入ったよ。jinjapyをフロントマター付きのjinjaテンプレートとして導入するのは、いくつかのシナリオで役立つね。sqlorm（https://github.com/hyperflask/sqlorm）には特にワクワクした。これを取り入れるのはまだ早すぎるけど、コンセプトはすごく好きだ。pydanticをよく使っているから、SQLをpydanticの拡張としてドックストリングにしてほしいな。どこでもシリアライザーを書くのは疲れるし、コードベース全体で参照できる単一のpydanticモデルがあった方がいい。主にDjangoを使っているけど、最近はORM以外のフレームワークのバッテリーをあまり使わなくなってきた。

└

ありがとう！このプロジェクトで色々なことを紹介できて、誰かが気づいてくれて嬉しい :D 他の人にも興味があれば、HNにSQLORMを投稿したよ：https://news.ycombinator.com/item?id=45607688

一見したところ、PythonのコントローラファイルにHTMLテンプレートを追加するデザインの選択が理解できない。テンプレートレンダリングの呼び出しを削除するためだけに、かなりの複雑さがあるように思えるけど、何か見落としてる？

└

これはhtmxが従っている「行動の局所性」[0]の原則と一致してるんだ。JavaScriptの世界ではAstro Pages [1]に触発されてる。同じようなものだね。これを使った開発者体験が本当に好きだったよ。[0] https://htmx.org/essays/locality-of-behaviour/ [1] https://docs.astro.build/fr/basics/astro-pages/

2025年に非非同期の基盤（Flask）でフレームワークを構築するのは奇妙だね。Flask APIをスケールさせる唯一の方法はgeventを使うことだけど、それは問題が待ってるだけだと思う。Asyncioの方がずっと良くて、安全だし、業界でも採用されてるよ。

└

視点が足りないと思うな。まだまだ同期コードがたくさん書かれてるし、実際にデプロイされてるPythonのほとんどは非同期じゃないんじゃないかな。ほとんどのアプリは大規模なスケールを必要としてるわけじゃなくて、シンプルさが求められてるよ。

└

検索機能を使ったときにQuartが言及されていないのに驚いたよ：https://hyperflask.dev/guides/setup/ 最近、FlaskとQuartをほぼ同じように考えていて、PythonのバックエンドにはQuartを使ってる。知らない人もいるかもしれないけど、Quartは非同期のFlaskで、システム内部は共有してるから、Flask用に作られたものをQuartで使うのは普通に簡単だよ。

ハクソク