2026 年の Flet: Flutter UI、Python ロジック、最初に認めておくべきトレードオフ

r/FlutterDev のスレッドで「Python で Flutter アプリを構築する」として Flet が再浮上しました。新しいアイデアではありませんが、根強いのは動機が本物だからです。多くのチームには深い Python の専門知識があり、初日から Dart を採用せずにクロスプラットフォームの UI が欲しいのです。

ソース: Reddit のスレッド と flet.dev。

Flet とは何か (そして何ではないか)

Flet は「Flutter にコンパイルされる Python」ではありません。一般的なモデルは次のとおりです。

• UI をレンダリングする Flutter のフロントエンド。
• アプリのロジックを実行する Python ランタイム。
• UI イベントと状態を同期するプロトコル (多くの場合、WebSocket 上の JSON)。

この区別が重要なのは、パフォーマンスとデバッグの物語を変えるからです。実質的に、ノート PC で動いていても、分散アプリを構築していることになります。

動かしながら考えられる最小限の例

import flet as ft

def main(page: ft.Page):
    page.title = "Start Debugging: Flet demo"

    name = ft.TextField(label="Name")
    out = ft.Text()

    def greet(e):
        out.value = f"Hello, {name.value}"
        page.update()

    page.add(name, ft.ElevatedButton("Greet", on_click=greet), out)

ft.app(main)

Python 開発者なら、フックはここです。素早く UI が手に入り、ビジネスロジックとライブラリは Python のエコシステムに留まれます。

Flutter を直接書くのと比べたトレードオフ (Dart 3.12、Flutter 3.x)

利便性の対価は、本番で重要な箇所で支払います。

• レイテンシとイベントのやり取り: UI 操作がメッセージになります。フォームやダッシュボードなら問題ないかもしれませんが、純粋な Flutter とはプロファイルが異なります。
• エコシステムのずれ: Flutter のプラグインやパッケージは Dart 向けに設計されています。Python からネイティブ API へブリッジするのはぎこちなくなりがちで、特にモバイルでそうです。
• 分裂脳のデバッグ: Flutter DevTools や Dart レベルのプロファイリングは、Python 側のボトルネックを自動で表に出してくれません。

これらのどれも Flet を悪いものにはしません。ただ、別の製品にしているだけです。Flutter がレンダリングする UI に Python のセマンティクスというものです。

私が Flet を選ぶ場面

• 最初の UI までの時間が主な制約となる社内ツール。
• 先にデスクトップと Web、モバイルは後。
• UI の表面が必要なだけで「Flutter ファースト」のエンジニアリング文化ではない、Python の力が強いチーム。

フレームのタイミング、プラグインの深さ、ネイティブのデバッグが重要な消費者向けモバイルアプリを作るなら、私は依然として Flutter を直接選びます。Flet は参入障壁を下げる点で興味深いですが、何を犠牲にしているかを明示しておくべきです。