Flet 2026: Flutter-UI, Python-Logik und die Trade-offs, die Sie sich von Anfang an eingestehen müssen

Ein Thread in r/FlutterDev brachte Flet als “Flutter-Apps in Python bauen” wieder hoch. Die Idee ist nicht neu, aber sie ist hartnäckig, weil die Motivation real ist: Viele Teams haben tiefes Python-Wissen und wollen eine plattformübergreifende UI, ohne am ersten Tag Dart einzuführen.

Quellen: der Reddit-Thread und flet.dev.

Was Flet ist (und was nicht)

Flet ist nicht “Python, das zu Flutter kompiliert”. Das übliche Modell ist:

• Ein Flutter-Frontend, das die UI rendert.
• Eine Python-Laufzeit, die Ihre App-Logik ausführt.
• Ein Protokoll, das UI-Ereignisse und Zustand synchronisiert (häufig JSON über WebSockets).

Diese Unterscheidung zählt, weil sie die Story zu Performance und Debugging ändert. Sie bauen faktisch eine verteilte App, auch wenn sie auf Ihrem Laptop läuft.

Ein winziges Beispiel, das Sie ausführen und durchdenken können

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)

Wenn Sie Python-Entwickler sind, ist das der Köder: Sie bekommen schnell eine UI und bleiben für Geschäftslogik und Bibliotheken im Python-Ökosystem.

Die Trade-offs gegenüber direkter Flutter-Entwicklung (Dart 3.12, Flutter 3.x)

Sie zahlen für die Bequemlichkeit an Stellen, die in der Produktion zählen:

• Latenz und Event-Geplapper: UI-Interaktionen werden zu Nachrichten. Für Formulare und Dashboards kann das in Ordnung sein, aber das Profil unterscheidet sich von reinem Flutter.
• Ökosystem-Mismatch: Flutter-Plugins und -Pakete sind für Dart entworfen. Aus Python heraus auf native APIs zu brücken kann unbequem sein, besonders auf Mobil.
• Split-Brain-Debugging: Flutter DevTools und Profiling auf Dart-Ebene zeigen Engpässe auf der Python-Seite nicht automatisch auf.

Nichts davon macht Flet schlecht. Es macht es nur zu einem anderen Produkt: Flutter-gerenderte UI mit Python-Semantik.

Wann ich Flet wählen würde

• Interne Werkzeuge, bei denen die Zeit bis zur ersten UI die Hauptbeschränkung ist.
• Zuerst Desktop- und Web-Targets, Mobile später.
• Teams mit starker Python-Kompetenz, die eine UI-Oberfläche brauchen, keine “Flutter-first”-Engineering-Kultur.

Wenn Sie eine Consumer-Mobile-App bauen, bei der Frame-Timing, Plugin-Tiefe und natives Debugging zählen, greife ich weiterhin direkt zu Flutter. Flet ist interessant, weil es die Einstiegshürde senkt, aber Sie sollten explizit machen, was Sie dafür aufgeben.