For every sufficiently successful single-language ecosystem, there will be people trying to use a different language, turning it into a multi-language ecosystem.
Also, for every sufficiently successful multi-language ecosystem, there will be people trying to get it to support one more language.
Why though? Flutter was built for Dart and, while not my favourite language, it does that job very well. When the major drawback of all multi-platform frameworks tends to be performance, how does using a much slower, non-compiled language improve things?
I have some confusion how a dynamically typed interpreted language that allows nulls interfaces with something that expects types, null safety, and ultimately is compiled.
I think that is poorly worded. Reading the docs (https://flet.dev/docs/publish), much like Flutter, this compiles to an IPA for your own app that you can deploy.
I think they are referring to the Flet app shell that is the native shim for Flutter and Python.
Probs less of a don't use dart motivation and more of a "here's another option if you're a python dev". Especially since nobody seems in love with the current state of desktop UI frameworks for Python.
Also potentially a move to make Flutter more of a cross language standard for interfaces to oppose electron?
Not just new language to learn, but also new toolchain to become familiar with and library ecosystem to get a grip on. Longtime devs of any language have a grab bag of go-to tools and libraries for a variety of situations and it’s not fun to have to give that all up.
It’s really in the best interest for any UI toolkit project with goals of mass adoption to be as language agnostic as is reasonably possible, or at minimum reasonable to write C bindings for so the community can then build their own bindings to other languages without too much fuss. A lot of devs aren’t going to switch languages for a UI toolkit unless it checks every box imaginable — think something as capable as AppKit/UIKit or Qt Widgets — and most newer UI toolkits (including Flutter) don’t come anywhere close to that.
you have a large app using a bunch of python libraries and now you want to add a GUI to it and you like flutter. what, e.g., is the dart equivalent of networkx?
All these multi-platform kits are getting fatiguing. Electron, sciter, neutralino, proton native...there are hundreds of others, and now Flet. Reminds me of the Google/Apple app stores, where there are 100+ solutions for the same problem, and all of them suck.
I wonder if we really did a good thing by building this "app culture" where everything needs a little "app" as a way of extracting a little more money from people. Although "app" means application, the word "app" is apt because it signifies the commercialization of applications into advertisements-as-a-program, in the same way that YouTube transformed videos into advertisements-as-a-video.
But your statement is presupposing a world where the "sea of bad things to good things" has no flexibility in how it works. I am proposing that the current method where software is developed to go after microprofits through advertising and trivial functionality, and on a closed, corporation run platform, IS A BAD THING.
I disagree. Every time someone contributes to something, it evolves the ecosystem that in turn molds the social atmosphere around it. And I was more referring to our support of Apple and Google that in turn created the system that supports so many app frameworks.
my issue with these hacks is that the moment you want to do something not already implemented, you have to now learn not only how to do it on the original platform but also figure out how to hack it into the hack. e.g. keep screen on, Bluetooth, gps, etc.
For every sufficiently successful single-language ecosystem, there will be people trying to use a different language, turning it into a multi-language ecosystem.
Also, for every sufficiently successful multi-language ecosystem, there will be people trying to get it to support one more language.
Why though? Flutter was built for Dart and, while not my favourite language, it does that job very well. When the major drawback of all multi-platform frameworks tends to be performance, how does using a much slower, non-compiled language improve things?
There are lots of Python libraries out there. There might be some with no Dart equivalent?
But if you don’t care about using them, maybe it’s not that compelling.
Isn't that is what dart ffi is for?
It looks like it’s for interop with C rather than Python. I see there is a python_python_ffi package, though?
https://github.com/IVLIVS-III/dart_python_ffi/
I have some confusion how a dynamically typed interpreted language that allows nulls interfaces with something that expects types, null safety, and ultimately is compiled.
“View via iOS Flet app” is not “enables developers to easily build realtime web, _mobile_ and desktop apps in Python.”
I think that is poorly worded. Reading the docs (https://flet.dev/docs/publish), much like Flutter, this compiles to an IPA for your own app that you can deploy.
I think they are referring to the Flet app shell that is the native shim for Flutter and Python.
Ah, thanks!
[flagged]
Probs less of a don't use dart motivation and more of a "here's another option if you're a python dev". Especially since nobody seems in love with the current state of desktop UI frameworks for Python.
Also potentially a move to make Flutter more of a cross language standard for interfaces to oppose electron?
It doesn't matter if it's any easy language, a new language to learn is a new language to learn.
Same reason why NodeJs exists, you can use what you already know.
Not just new language to learn, but also new toolchain to become familiar with and library ecosystem to get a grip on. Longtime devs of any language have a grab bag of go-to tools and libraries for a variety of situations and it’s not fun to have to give that all up.
It’s really in the best interest for any UI toolkit project with goals of mass adoption to be as language agnostic as is reasonably possible, or at minimum reasonable to write C bindings for so the community can then build their own bindings to other languages without too much fuss. A lot of devs aren’t going to switch languages for a UI toolkit unless it checks every box imaginable — think something as capable as AppKit/UIKit or Qt Widgets — and most newer UI toolkits (including Flutter) don’t come anywhere close to that.
you have a large app using a bunch of python libraries and now you want to add a GUI to it and you like flutter. what, e.g., is the dart equivalent of networkx?
All these multi-platform kits are getting fatiguing. Electron, sciter, neutralino, proton native...there are hundreds of others, and now Flet. Reminds me of the Google/Apple app stores, where there are 100+ solutions for the same problem, and all of them suck.
I wonder if we really did a good thing by building this "app culture" where everything needs a little "app" as a way of extracting a little more money from people. Although "app" means application, the word "app" is apt because it signifies the commercialization of applications into advertisements-as-a-program, in the same way that YouTube transformed videos into advertisements-as-a-video.
What a mess.
All of the good things you know came from a sea of bad things. There does not exist a world where only "perfectly designed" products and tools exist.
But your statement is presupposing a world where the "sea of bad things to good things" has no flexibility in how it works. I am proposing that the current method where software is developed to go after microprofits through advertising and trivial functionality, and on a closed, corporation run platform, IS A BAD THING.
Your comment has gone on a complete tangent that makes 0 sense. This is open source software. People decided to build this and give it away for free.
I disagree. Every time someone contributes to something, it evolves the ecosystem that in turn molds the social atmosphere around it. And I was more referring to our support of Apple and Google that in turn created the system that supports so many app frameworks.
my issue with these hacks is that the moment you want to do something not already implemented, you have to now learn not only how to do it on the original platform but also figure out how to hack it into the hack. e.g. keep screen on, Bluetooth, gps, etc.