"The fastest way to build Flutter apps in Python" is the title of Flet's web page. As someone coming from the Flutter world reading the line I draw an ideal picture of "swapping Dart language for Python and magically having the whole power of Flutter framework at the tips of your fingers".

Not Flutter

Upon inspection of the sample code written in Flet, I see no Flutter:

• There are no widgets - the cornerstone of Flutter (immutable UI configuration). There's no such concept.
• It has its own library of controls, you can't use the standard Flutter UI library
• It is imperative, i.e. you explicitly create UI elements (aka controls) and mutate their state
• UI updates are explicit and require page.update() call

Philosophically, the above snippet of Flet code represents anti-Flutter, the way of doing UI that Flutter was created to move away from. Here's the quote from Flutter architectural overview:

Flutter is a reactive, declarative UI framework, in which the developer provides a mapping from application state to interface state, and the framework takes on the task of updating the interface at runtime when the application state changes. This model is inspired by work that came from Facebook for their own React framework, which includes a rethinking of many traditional design principles.

While Flutter is used to power Flet behind the scenes, it is hidden deep. None of the features Flutter is famous and valued for can't be seen in Flet.

Not the fastest

Flutter is known for its reach ecosystem and availability of many high-quality libraries. There're over 38000 packages at pub.dev and none of those e are available to build UI in Flet.

Besides none of the Flutter-specific materials (blogs, StackOverflow questions, docs) can be applied here.

As long as you're not building a counter app there're few readily available modules OR docs that can make you faster.

What Flet actually is

In a wide sense, Felt is a cross-platform, server-driven, imperative UI framework for Python. It uses Flutter behind the scenes to build and package UI clients that communicate with the Python backend and render the UI. It keeps developers away from Flutter clients, they are ready-made and not intended to be changed.

In the context of the Flutter ecosystem, Flet is a package published at pud.dev that allows you to put a widget in your app and render UI generated by Flet's Python server:

Widget build(BuildContext context) {

    return const MaterialApp(

      title: 'Flet Flutter Demo',

      home: FletApp(pageUrl: "http://localhost:8550"),

    );

  }

Is it bad?

No, it's not! The creators of the package did a huge job and presented a UI framework that lets anyone who knows Python jump onto developing cross-platform apps for Windows, Linux, macOS, Android, iOS, and the Web. There's no need to learn a new programming language. No need to learn complicated paradigms with state management, reactive UI whatever.

However, the communication from Flet's team can be confusing and misleading.

If someone has Flutter experience, is building an app, and comes to Flet seeking to integrate Python - the expectations will likely be inflated and wrong. I don't think this person can be convinced to forgo all the goods of Flutter and switch to a completely new UI framework which is light years behind. There're better ways to couple Flutter and Python.

If someone has Python knowledge but no UI development experience, is building a simple UI for any of the platforms, and wants to start fast - Flet can be the right choice.

Yet if you're building UI that will last, Flet's imperative UI (reminding of the old good days of C++/MFC, Delphi, and ASP.NET Web Forms) can be an issue. There's a reason why we have plenty of modern UI frameworks that don't do that. With a sophisticated UI state, you will be creating a lot of hard-to-maintain and buggy code. Keeping in your head all the places that need to be manually updated (every time you have a new requirement) won't be easy. Learning a capable UI framework that promotes good practices might be a better option for building complicated UI driven apps.