Message to the Flet Team from a Single Developer

[SM0871]

Flet Team,

I am writing to you as a Python developer who has long valued and used Flet. I chose your framework precisely for its simplicity, directness, and "Pythonic" nature. For me, Flet was like Flask for UI – logical, predictable, and based on patterns that, as a Python developer, I know and understand. You opened the door for me to create applications with an interface without needing to delve into HTML, CSS, or JavaScript.

The announcement of the React-style declarative approach with @component, use_state(), and Observable has caused me great concern and raises fundamental questions about the future of a tool I've grown fond of.

For Whom Is This Change?
The true strength of Flet for me was its accessibility – the ability to quickly build a working interface in clean, understandable Python. My personal experience with Flet involves building small to medium-scale applications – internal tools, prototypes, admin panels. In my projects, the imperative approach worked perfectly. It was intuitive: create a control, assign an action to it, add it to the page. I didn't have to think about hooks, side effects, or the virtual DOM. This approach wasn't waiting for a problem to solve – it simply worked.

Now, seeing this new, declarative model, I ask myself: Do I really need another framework with React patterns in my projects? Will my applications become better, or just more complex? In my case, the answer is: no. The current, imperative approach still perfectly fulfills its role.

Why React, Not Python?
I am confused by the direction in which development is heading. Python has a rich tradition and excellent, native design patterns – classes, decorators (like those known from Flask), clear life cycles. Why would a framework created for Python developers borrow concepts from the JavaScript/React ecosystem, instead of evolving in a way natural to Python? Instead of copying use_state(), wouldn't it be better to improve the imperative API or introduce more Pythonic solutions for state management, such as dedicated state classes or a middleware system? This seems more in line with the spirit of Python and the needs of its developers.

Double Learning Curve and Identity Blurring
The vision that as a user I must now choose and understand two different interface programming paradigms within one framework is overwhelming. How am I supposed to learn this effectively? How is a newcomer supposed to do it? I fear that Flet will lose its clear, cherished identity as a simple and accessible UI framework for Python. There is a real risk it will become just another complex reactive framework, losing what made it unique and attractive. In this way, you might cause current users – like me – to start looking for simpler alternatives, while new ones, who already know React, will probably still choose React, Vue, or Svelte. This is a path that could lead to losing both groups.

Appeal for Dialogue and Transparency
In light of these concerns, I sincerely ask you for clear communication and clarification on several key issues:

What is the true, long-term vision for Flet? Will the imperative API remain a fully supported "first-class citizen," with the declarative approach merely an optional add-on for those who want it? Or do you plan a gradual but inevitable shift towards declarative as the primary model?
How do you plan to teach these two radically different mental models in the documentation? Won't this create unnecessary chaos and fragmentation for new users who won't know where to start?
Have you considered alternative, more "Pythonic" paths of development for handling large, complex applications? Were concepts based on classes, clear contracts, or modularity, which are closer to Python's philosophy than directly implementing React patterns, ever on the table?
I am here because I love Python and came to love Flet for how it harnessed Python's power and clarity. Please, do not turn the architecture of the road – transparent, controlled, and understandable step by step – into the architecture of the wizard, where the framework's magic hides from me, the developer, what is truly happening.

Hoping for an explanation and open dialogue,

[FeodorFitsner]

Thank you for sharing your concerns!

As I mentioned in another thread, the declarative model in Flet does not replace the imperative approach that Flet developers are already familiar with. The Flet Component API (also known as Flet Components) is a micro-framework built on top of the core Flet framework.

A similar evolution happened on the web. Browsers expose a DOM that can be manipulated imperatively (createElement, appendChild), and libraries like jQuery emerged to simplify that style of development. Later, React introduced a declarative framework built on top of the same browser APIs. React didn’t replace the browser DOM—it complemented it—and went on to power many large websites and applications.

Flet follows the same philosophy. The Component API complements the existing Flet controls API. You can continue building Flet apps exactly as before, or you can choose the new declarative approach. Both styles are valid, and both are supported in Flet—and will continue to be supported going forward.

[icstos]

Now I feel a bit confused, for example, the new feature: ft.Router cannot be used in imperative programs (no relevant examples are seen, and errors are reported when trying to explore), but ft.Router is really a good solution. Is it a declarative trend? However, the use of declarative programs also has some awkward problems。 #5841

[amuza2]

As a developer who also frequently builds cross-platform desktop applications using Avalonia UI and Community Toolkit MVVM (C#), I want to chime in on this discussion.

I completely understood why the original author felt concerned. If your background is strictly Flask/Tkinter, seeing React-like hooks dropped into Python feels alien, complex, and un-Pythonic.

However, coming from a modern desktop MVVM framework like Avalonia UI, I want to reassure you: this architectural shift is actually exactly what Flet needs to grow up into a professional cross-platform tool.