In-depth Development Feedback on Flet

[Qye-Leisure]

Flet is my favorite Python framework and the only one in Python that supports cross-platform and cross-end development. I have been learning and developing with Flet for six months, using it to build both simple and complex components. Here is my experience:

Regarding performance:
The first issue I encountered was Flet's performance. After the 0.83 update, performance improved, but in some cases it remains very laggy, which left me puzzled. Eventually, I discovered that some Flet components lack a throttling mechanism. If such components are inadvertently used in highly interactive scenarios, the lack of throttling in returned data causes communication congestion, leading to significant lag across the application. In other cases, the component's built-in throttling design is flawed — for example, a throttle set to 200ms. If three events are triggered within 200ms, the data returned should be the sum of all three events, but in reality, only one event is returned. These issues mainly occur in components like InteractiveViewer and Draggable, which have very smooth animations. As in my case below, without adding DragTarget(), even 1000 modules run smoothly, but adding DragTarget() makes 200 modules very laggy — simply because DragTarget() lacks event throttling. In contrast, InteractiveViewer does have event throttling, but the data it returns is incorrect.

Therefore, in addition to optimizing the underlying communication of the framework, I believe Flet's performance experience also greatly depends on fine-tuning individual components. If these two components had proper throttling, they would run very smoothly.

Regarding development experience:
For development with Flet, I mainly use an imperative style, though I've also tried declarative. After testing, I found the best approach is to use imperative style for custom components and declarative style for pages. This is because custom components may involve very complex code and functionality, but as independent classes they are easy to maintain — you only need to look at that class. Declarative style, on the other hand, offers the best efficiency and maintainability for page development.

However, during development, I encountered a serious issue: when building custom components with the @ft.control decorator, support for callback functions is very poor. If callbacks are needed, using @ft.control for custom components is even less convenient than simply using traditional class-based approaches. If this issue could be resolved, the imperative development experience would undoubtedly be much better.

I haven't used declarative extensively — only for some page construction. However, sometimes I cannot directly use components built imperatively in declarative mode. That might be due to my own technical limitations — I'm not sure, because there are very few declarative code examples, which limits my familiarity with it. But I am still looking forward to it.

One more point: managing the state of multiple components declaratively requires setting a key. I recall Flet probably has an internal component ID that is not exposed externally. I wonder if this ID could be used to track each component — that would be much more convenient than using key. This is just my opinion; I don't fully understand the underlying technology, as I am not a professional developer.

Summary:
Regarding Flet's performance, I feel it has almost reached a standard that allows it to be used in most scenarios (not for high-performance applications, but for ordinary dashboards, node editors, mind map editors, etc.). However, insufficient optimization of details drags down Flet's performance.

In terms of development experience, @ft.control has poor support for callback functions, but this can be replaced with traditional class-based writing, so it's not a big deal. The main issue is the unclear integration between imperative and declarative approaches — whether both can be used together is not explicitly stated in the documentation. Moreover, there are too few declarative code examples; based on the current documentation, it is not sufficient to learn Flet's declarative development.

QQ2026513-8410.mp4

QQ2026513-8449.mp4

import flet as ft


if __name__ == "__main__":
    def main(page: ft.Page):

        位置=None
        def 节点在画布内移动时(e):
            nonlocal 位置
            位置=e.local_position
            print(f"正在移动{e.local_position}")


        def 节点拖拽完成事件(e):
            print(f"移动完成{位置}")


        def 模块拖拽(e):
            x = e.control.left+e.local_delta.x
            y =e.control.top+ e.local_delta.y
            e.control.left,e.control.top=(x,y)
            e.control.update()
        
        def 模块容器(zb:tuple):
            模块 = ft.Container(
                width=300,
                height=80,
                border_radius=5,
                border=ft.Border.all(1,ft.Colors.BLACK),
                content=ft.Row(
                    spacing=0,
                    controls=[
                        ft.Draggable(
                            content=ft.Container(
                                width=50,
                                bgcolor=ft.Colors.GREEN
                            ),
                            on_drag_complete=lambda e :节点拖拽完成事件(e),
                        ),
                        ft.Container(expand=True,bgcolor=ft.Colors.AMBER),
                        ft.Draggable(
                                    content=ft.Container(
                                        width=50,
                                        bgcolor=ft.Colors.GREEN
                                    ),
                                    on_drag_complete=lambda e :节点拖拽完成事件(e),
                                ),
                            ]
                        )


            )



            return ft.GestureDetector(
                mouse_cursor=ft.MouseCursor.MOVE,
                drag_interval=5,
                on_pan_update=模块拖拽,
                left=zb[0],  
                top=zb[1],  
                content=模块
            )  



        模块显示层=ft.Stack(
                margin=0,
                expand=True,     
                controls=[
                    模块容器((50+i*10,50+i*10)) 
                    for i in range(200)],   
                )
        

        轨迹监控层=ft.DragTarget(
                    content=ft.Container(expand=True),
                    on_move=节点在画布内移动时)

        基础布局=ft.Stack(
            controls=[
                轨迹监控层,
                模块显示层

                
            ]

        )

        page.add(
            ft.Container(expand=True,content=基础布局,bgcolor=ft.Colors.BLUE_200 ,margin=0)
        )
        
    ft.run(main)

[Qye-Leisure]

I've observed a phenomenon in complex application event scenarios (when refreshing hundreds of components at once): Flet is extremely fast from sending update events to the UI refresh, with no perceptible delay. However, after the refresh tasks are completed, the UI freezes. This suggests that Python sends data to Flutter very quickly (likely thanks to the performance optimizations in version 0.83), but the UI lag after the update tasks finish indicates something is blocking the UI during that period. It’s very likely a problem with Flutter sending data back to Python — specifically, Flutter might be sending a large amount of data to Python in a short time, causing event blocking. This makes sense because during the UI freeze, the tooltip labels on containers still respond normally. I’m not entirely sure about the deeper details due to my limited technical knowledge.

However, this shows that Flet’s performance ceiling is actually quite high. Although it’s hard to match native Flutter performance, with proper optimization it should still outperform many web frameworks. Moreover, developing apps with Flet is much faster than web development, and the learning curve is lower too.