Wow there's a surprising amount of negativity here.
I've used this for a fairly complex app at work and it's great. (It's certainly not vibe coded as one commenter suggested.) It's a Python layer on top of Flutter, and it was the only UI framework I could find for Puthon that was fast and worked on all major desktop and mobile OSs. I think maybe Kivy could too but it seemed like it would be an uphill struggle for a good desktop app.
It's a bit of a gateway drug for pure Flutter. If you need some complex, quickly updating control then you can write a Flutter control (in Dart) and wrap it in a Flet (for Python) control for better performance than doing it all in Python. I've ended up doing that for the main display in our app, and there's always the option to move more and more business logic into that.
One downside to Flet is that I wish they didn't try "fix" some design decisions in Flutter. For example, they have a Flet "Container" widget that wraps a bunch of different Flutter layout widgets. The Flet version does seem easier to understand to me, but there's just so much more documentation (and StackOverflow answers etc.) for Flutter than for Flet that it would be easier overall if they just mirrored the Flutter controls precisely.
I built an iOS app with python library as core component and SwiftUI as UI layer. It is not fun to cross compile the dependencies for iOS, I need implement the iOS interfaces, cannot just simplify use macos for native api. There is a good beeware project port a lot python libraries to iOS. Without that to port from scratch would be a lot of work for a middle size apple.
My personal stance on this type of UI framework is that I won't waste my time on it unless I see it being used in mature, large-scale applications. Complex software often involves dealing with obscure edge cases; you certainly wouldn't want to spend a huge amount of time building an app, only to discover that the framework itself has serious flaws that make it impossible to proceed.
To paraphrase you: "no one should release new open source software libraries because it is not enterprise ready on day one with thousands of deployments and every feature imaginable".
I believe Python has done more harm than good to the industry.
Its by nature very inefficient, it leads you in the direction to some very poor abstractions (inheritance, monkey patching, mixins etc) and as a result code that is very prone to subtle bugs and issues.
It deserves all the love it gets as an approachable language, but it deserves a lot more flack for everything else.
Big disagree. I've been following this project since it's early days, and have made a few projects based on it. I haven't been bitten by any "inefficiencies" in such a way that'd make me give up the language. And at this very moment I'm working on what's essentially a Python REPL that can build and return Flet controls (as well as the traditional string result), making writing and running adhoc native "applets" fully on mobile a possibility (haven't seen anything else that does this).
I'm in the middle. I've been using Python since the early 2.x series.
The good parts are that the inbuilt data structures and their apis are efficient and clean enough to write code that's mostly readable. Most of the heavy lifting is done in hand tuned C and performance intensive external modules are also written in C. There are several good projects that are written using it and while it's not theoretically perfect, it's useful enough. Like Stroustrup said - there are 2 kinds of the languages, ones that everyone complains about and ones that no one uses.
The bad parts are that it's very easy to use. Almost in a Visual Basic "producing crap just takes a squeeze" kind of way. It opened up programming to a lot of people (the genesis of Python was in the CP4E project - where this was the aim). This resulted in a lot of bad patterns, inefficient code, badly written but popular libraries. Also, the indentation idiom and other restrictions resulted in a lot of convoluted APIs.There's also a lot of baggage from the pre multi-core CPU era (threading etc.).
I still think of it as a great glue language. If there are libraries that are fast and can run well, a good FFI or wrapper which Python can leverage will amplify the reach and usability of the library.
On the overall, a language that's older than the venerable Java which people are still using (and hence complaining about) speaks to its longevity. So, atleast by that definition, it is successful.
But when it comes to GUI toolkits, which of them are efficient? React Native, Tauri, Electron. I don't see a efficient one other than Native toolkits. Even they have their own problems.
PS: Loved your website's (https://ben.church/) messaging for different audiences. Especially the "My Wife" one. Gave me a good laugh. :)
I built a few Kivy apps years ago at an old job. It was a little clunky, but it got the job done. Haven’t heard of this framework yet, I wonder how compares in developer experience? Anyone have any experience with it?
The problem is I don’t want to use Python for everything that bad. If I’m going to reach for a cross platform toolkit these days, I’m personally going to reach for Tauri. Could be useful if you’re really married to Python I suppose.
Choosing to build an application around a framework whose top contributors are Claude and Copilot may have catastrophic consequences for your project, especially if it's a business.
Native build size depends on what you want in the app, like the app I'm currently working on is almost 300MB, but I've added a few custom extensions to it (charts, iroh, and more). Earliest APK I can find is 140MB. In this day and age I honestly wouldn't worry much about app size though given how much storage devices have.
kivy, which does the same thing, has been around for over 10 years. I built my thesis in it a few years ago. not recommended—too many limitations and build issues in practice. given that this one is less mature...I'm not optimistic.
All software has limitations, that's why we keep writing more software.
Kivy is great, and the contributors are friendlier than most. I particularly like it for Android, but it's definitely way up there in terms of "easy reliable multiplatform python framework".
It also gives you a ton of options for how you want to use it, more than one way to skin a cat philosophy.
I tried using Kivy some years ago and also found it pretty painful. Flet I've been using for a while now and find it a joy by comparison, and it's actively developed, with a release every couple months or so. With the stability of v1.0 I expect that to slow a bit though, as I'd say at least core Flet is feature complete.
Please no, python should be deprecated at this age, especially in the era of llm, horrible language from the performance to the dependencies to everything, can’t believe it got popular over perl back in the day
I don’t understand the points attempted to be made here.
> especially in the era of LLM
Using a tool to generate a product in a language that someone isn’t familiar with is not a good idea.
> horrible language from the performance…
Nor is it a good idea to choose a language strictly for its performance when requirements like portability and framework maturity are at the forefront.
> …to the dependencies…
Dependency management isn’t the greatest, but it’s also not awful for a deployed product. Managing dependencies as a developer with multiple projects that each have their own virtual environment may not be fun but it’s not exactly an impossible mess.
> …to everything
from __future__ import everything
> can’t believe it got popular over Perl back in the day
And I’m sure people can’t believe that the iPod got more popular than the Zune, but sometimes convenience and taste are what drive decisions.
The things it focuses on makes it wildly popular, and will continue to make it so. So popular that quite a few have been using it as a wrapper for packages with a Rust core, for example. I personally think they should stick to all Rust because they're only polluting the ecosystem, making Python less usable for an increasing number of scenarios.
Performance isn’t important for any of the millions of things I use python for. I learned Perl first and gladly gave it up for syntax readability and easy of use over the years.
Pick the tool that’s right for you and the job, arguing against something based on your specific preferences should be seen as an argument without merit. I gave up Perl around the turn of the millennium, maybe it improved sense, but I really hated it back then-but I don’t go around badmouthing it and telling people to get rid of it.
Python is almost as ubiquitous as html, css, etc. It’s everywhere
I used it quite a bit for writing tools for applications like Maya and Blender as it's the only fully supported API surface. I take it it's pretty bad for anything more complex. I notice it's used quite a bit in science and math communities too.
I love Python,i have been writting Python since 2.2 era, Is great. Bit it's slow as hell, Django is slow, and the filters and custom shit to hit db on the template makes it slower. The parameters styles are too many and now instead of removing things they keep adding features, ok no Gil Is great but match? They should stop now. I hope i will never have to use custom cython modules again. I have even used Python in asterisk agi fastagi etc. But it's really slow and we should accept that
I don't really disagree with any of that and I have my own complaints about Python. Personally I would have been happy if they stopped at Python 2.7 but I also have numerous complaints about all of the programming languages I use heavily. There's no perfect language.
There is more than one axis (or two or three). One some axis popular and/or widespread is required for good. You can't have very large number of readily available libraries applicable to many domains without a language being popular and/or widespread.
What the heck? Python is a joy to program in and it's great for making small utilies, scripts, and even programs that don't require incredible performance. Perl is a pretty horrific-looking language.
Wow there's a surprising amount of negativity here.
I've used this for a fairly complex app at work and it's great. (It's certainly not vibe coded as one commenter suggested.) It's a Python layer on top of Flutter, and it was the only UI framework I could find for Puthon that was fast and worked on all major desktop and mobile OSs. I think maybe Kivy could too but it seemed like it would be an uphill struggle for a good desktop app.
It's a bit of a gateway drug for pure Flutter. If you need some complex, quickly updating control then you can write a Flutter control (in Dart) and wrap it in a Flet (for Python) control for better performance than doing it all in Python. I've ended up doing that for the main display in our app, and there's always the option to move more and more business logic into that.
One downside to Flet is that I wish they didn't try "fix" some design decisions in Flutter. For example, they have a Flet "Container" widget that wraps a bunch of different Flutter layout widgets. The Flet version does seem easier to understand to me, but there's just so much more documentation (and StackOverflow answers etc.) for Flutter than for Flet that it would be easier overall if they just mirrored the Flutter controls precisely.
I built an iOS app with python library as core component and SwiftUI as UI layer. It is not fun to cross compile the dependencies for iOS, I need implement the iOS interfaces, cannot just simplify use macos for native api. There is a good beeware project port a lot python libraries to iOS. Without that to port from scratch would be a lot of work for a middle size apple.
My personal stance on this type of UI framework is that I won't waste my time on it unless I see it being used in mature, large-scale applications. Complex software often involves dealing with obscure edge cases; you certainly wouldn't want to spend a huge amount of time building an app, only to discover that the framework itself has serious flaws that make it impossible to proceed.
What is the point of this comment?
To paraphrase you: "no one should release new open source software libraries because it is not enterprise ready on day one with thousands of deployments and every feature imaginable".
If you don't want to use it, don't use it
Python needs to be in less places not more.
I believe Python has done more harm than good to the industry.
Its by nature very inefficient, it leads you in the direction to some very poor abstractions (inheritance, monkey patching, mixins etc) and as a result code that is very prone to subtle bugs and issues.
It deserves all the love it gets as an approachable language, but it deserves a lot more flack for everything else.
Big disagree. I've been following this project since it's early days, and have made a few projects based on it. I haven't been bitten by any "inefficiencies" in such a way that'd make me give up the language. And at this very moment I'm working on what's essentially a Python REPL that can build and return Flet controls (as well as the traditional string result), making writing and running adhoc native "applets" fully on mobile a possibility (haven't seen anything else that does this).
I'm in the middle. I've been using Python since the early 2.x series.
The good parts are that the inbuilt data structures and their apis are efficient and clean enough to write code that's mostly readable. Most of the heavy lifting is done in hand tuned C and performance intensive external modules are also written in C. There are several good projects that are written using it and while it's not theoretically perfect, it's useful enough. Like Stroustrup said - there are 2 kinds of the languages, ones that everyone complains about and ones that no one uses.
The bad parts are that it's very easy to use. Almost in a Visual Basic "producing crap just takes a squeeze" kind of way. It opened up programming to a lot of people (the genesis of Python was in the CP4E project - where this was the aim). This resulted in a lot of bad patterns, inefficient code, badly written but popular libraries. Also, the indentation idiom and other restrictions resulted in a lot of convoluted APIs.There's also a lot of baggage from the pre multi-core CPU era (threading etc.).
I still think of it as a great glue language. If there are libraries that are fast and can run well, a good FFI or wrapper which Python can leverage will amplify the reach and usability of the library.
On the overall, a language that's older than the venerable Java which people are still using (and hence complaining about) speaks to its longevity. So, atleast by that definition, it is successful.
But when it comes to GUI toolkits, which of them are efficient? React Native, Tauri, Electron. I don't see a efficient one other than Native toolkits. Even they have their own problems.
PS: Loved your website's (https://ben.church/) messaging for different audiences. Especially the "My Wife" one. Gave me a good laugh. :)
Using a to-do list app as the first example to advertise a new app framework is absolutely wild in Q3 2026.
Is it more fashionable to build an AI harness?
We should go back to petstore examples.
A blog in 15 minutes would be great.
That's fine, but a blog doesn't seem technically more demanding or interesting than a to-do list
wasn't the original ruby on rails demonstrating how to create a blog? I think it was a call back to that 2004 era....
They didn't even show a prompt box with starry icon button!
Why?
It's one of the standard benchmarks for web frameworks.
No clue why it's being done here.
Specially one looking so bad.
I built a few Kivy apps years ago at an old job. It was a little clunky, but it got the job done. Haven’t heard of this framework yet, I wonder how compares in developer experience? Anyone have any experience with it?
The problem is I don’t want to use Python for everything that bad. If I’m going to reach for a cross platform toolkit these days, I’m personally going to reach for Tauri. Could be useful if you’re really married to Python I suppose.
Choosing to build an application around a framework whose top contributors are Claude and Copilot may have catastrophic consequences for your project, especially if it's a business.
Is there a downloadable sample somewhere? Would like to see how large a native build is.
Native build size depends on what you want in the app, like the app I'm currently working on is almost 300MB, but I've added a few custom extensions to it (charts, iroh, and more). Earliest APK I can find is 140MB. In this day and age I honestly wouldn't worry much about app size though given how much storage devices have.
Given the prices of storage and ram you should still worry about wasting user resources
Loving it. Been using in projects for a while now.
Interesting, looks like this is a framework built on Flutter.
Yeah, I have been doing a small poc for mobile, then did a web export (why not) and the entire web app is one giant <canvas> element.
I have never written web app with Flutter so this caught me by surprise.
Is this build on top of flutter?
And for web, does it generate plain HTML/CSS, the DOM tree, or just generate everything in a canvas?
It uses Flutter for UI and native services, but there's a full Python interpreter there.
I think it does mostly canvas, but that could just be due to my selected option back when I tried web with it (couple years ago).
kivy, which does the same thing, has been around for over 10 years. I built my thesis in it a few years ago. not recommended—too many limitations and build issues in practice. given that this one is less mature...I'm not optimistic.
All software has limitations, that's why we keep writing more software.
Kivy is great, and the contributors are friendlier than most. I particularly like it for Android, but it's definitely way up there in terms of "easy reliable multiplatform python framework".
It also gives you a ton of options for how you want to use it, more than one way to skin a cat philosophy.
I tried using Kivy some years ago and also found it pretty painful. Flet I've been using for a while now and find it a joy by comparison, and it's actively developed, with a release every couple months or so. With the stability of v1.0 I expect that to slow a bit though, as I'd say at least core Flet is feature complete.
Looks really interesting, but I notice that Bluetooth isn't in the supported services.
Sort of limits how useful it would be for me - Bluetooth is one of the only reasons I'd do a native app instead of PWA.
It should be supported, but if somehow it isn't, support can be added by creating an extension.
https://flet.dev/docs/extend/user-extensions/
Please no, python should be deprecated at this age, especially in the era of llm, horrible language from the performance to the dependencies to everything, can’t believe it got popular over perl back in the day
I don’t understand the points attempted to be made here.
> especially in the era of LLM
Using a tool to generate a product in a language that someone isn’t familiar with is not a good idea.
> horrible language from the performance…
Nor is it a good idea to choose a language strictly for its performance when requirements like portability and framework maturity are at the forefront.
> …to the dependencies…
Dependency management isn’t the greatest, but it’s also not awful for a deployed product. Managing dependencies as a developer with multiple projects that each have their own virtual environment may not be fun but it’s not exactly an impossible mess.
> …to everything
> can’t believe it got popular over Perl back in the dayAnd I’m sure people can’t believe that the iPod got more popular than the Zune, but sometimes convenience and taste are what drive decisions.
The things it focuses on makes it wildly popular, and will continue to make it so. So popular that quite a few have been using it as a wrapper for packages with a Rust core, for example. I personally think they should stick to all Rust because they're only polluting the ecosystem, making Python less usable for an increasing number of scenarios.
Performance isn’t important for any of the millions of things I use python for. I learned Perl first and gladly gave it up for syntax readability and easy of use over the years.
Pick the tool that’s right for you and the job, arguing against something based on your specific preferences should be seen as an argument without merit. I gave up Perl around the turn of the millennium, maybe it improved sense, but I really hated it back then-but I don’t go around badmouthing it and telling people to get rid of it.
Python is almost as ubiquitous as html, css, etc. It’s everywhere
I used it quite a bit for writing tools for applications like Maya and Blender as it's the only fully supported API surface. I take it it's pretty bad for anything more complex. I notice it's used quite a bit in science and math communities too.
It's not. OP just has a hate-on for Python. Python is widely used in many domains and has one of the richest ecosystems of packages.
I love Python,i have been writting Python since 2.2 era, Is great. Bit it's slow as hell, Django is slow, and the filters and custom shit to hit db on the template makes it slower. The parameters styles are too many and now instead of removing things they keep adding features, ok no Gil Is great but match? They should stop now. I hope i will never have to use custom cython modules again. I have even used Python in asterisk agi fastagi etc. But it's really slow and we should accept that
I don't really disagree with any of that and I have my own complaints about Python. Personally I would have been happy if they stopped at Python 2.7 but I also have numerous complaints about all of the programming languages I use heavily. There's no perfect language.
Popular and/or widespread does not mean good. Common misconception.
There is more than one axis (or two or three). One some axis popular and/or widespread is required for good. You can't have very large number of readily available libraries applicable to many domains without a language being popular and/or widespread.
What the heck? Python is a joy to program in and it's great for making small utilies, scripts, and even programs that don't require incredible performance. Perl is a pretty horrific-looking language.