"I just wish Google had built Flutter on a low level core that isn't tied to Dart, so it would be usable from other languages."
Exactly. Dart is a deal-breaker. I was tasked with choosing a cross-platform development solution, and rejected Flutter because nobody at my company (including me) knows Dart or has time to learn it. Nor would any contractors we were likely to find know it.
After quite a bit of research on other potential solutions, I determined (as did a crowded and lengthy thread in this forum) that Qt was the only viable one for now.
The recent proliferation of languages has been pretty annoying. Google should have at least used Kotlin. Alienating their own community of Android developers and making Flutter a pain in the ass to integrate into a development organization was dumb.
The other problem people cited with alleged cross-platform solutions is the need to write native code anyway if you need access to system/hardware resources (Bluetooth, USB, what have you).
I think that's pretty short-sighted. Dart is hardly an esoteric/niche language like Haskell or Futhark, anyone familiar with Java/Javascript/TypeScript should be able to pick it up in a day or so.
Flutter's performance issues, on the other hand, is a separate story.
Knowing nothing about Dart, I'd guess learning the language itself is not much of a task, but learning the libraries, build tools, and the whole ecosystem would take a while.
I don't think that's accurate. Seems like native apps have the best performance but Flutter comes a close second. React native on the other is much slower:
This has been a long-standing issue that has completely ruled out Flutter for us. E.g, the Flutterfolio idle login screen uses 14% CPU on my Mac. For a while it sounded like Google was saying that it can't be fixed. But I think they have done some work to address this issue. I'll be very interested in finding out whether it has been fixed in Flutter 3.
I think this might be a bit of an outlier honestly.
Reading the bug report my takeaways were the following:
1. Here is a specific issue we ran into which to be fair is unacceptable in terms of perf but a blinking cursor in an otherwise idle application has crazy high CPU usage numbers trying to run the animations associated with the blinking cursor.
2. They tried the same thing on Linux and CPU usage was 0% so already it appears this is more of a specific mac bug rather than some general widespread thing.
3. Further in the thread a number of potential solutions get mentioned and were under development including just writing a custom shader to handle the blinking cursor (so a solution looks possible)
They just made Mac desktop support stable as of less than 24 hours ago for the first time. None of this strikes me as that egregious. A whole number of major perf improvements have landed since then and it's not even clear if this is still an active problem in Flutter 3.
I think trying to extrapolate this one bug into some widespread disaster scenario is a mistake.
I don't know if there is a larger issue because this show stopping "outlier" has stopped me from exploring Flutter any further. I'll give it another try now that a new major version has been released.
The question in my mind is whether Flutter is consistently and significantly more resource efficient than web technologies for my particular use cases.
Hey there. I'm an engineer working on Flutter Desktop. We're definitely aware of the macOS cursor behaviour issue and are looking at ways we can fix it. We haven't landed anything (that I'm aware of) that should improve this for 3.0, but if it helps, it's something that's actively on our radar and we've discussed potential fixes for. One potential solution is to implement a custom shader [1].
While I understand this may be a dealbreaker issue for your use-case, we've been pretty busy getting a few higher-priority (overall) issues fixed (universal binary support, CJK text input, key event APIs, etc.) prior to 3.0, but we'll get to this.
Flutter and Dart seemed to have been internal tools built by engineers looking for an interesting project to spend their time on while at Google.
Kotlin swelled up around the limitations of Java 8 in outside organizations and took over the ecosystem so Android devs could be productive while Google was fighting with Oracle
Sure, I'm not trashing the language, because I know nothing about it.
Our whole dev team is C/C++, with random people who know Python and a few other things. I'm the only one who knows Swift. They're bright people and not hostile toward new ideas, but they're already overtaxed and can't cater to an outlier project written in a language no one knows and built on a framework no one knows.
Speaking from personal experience I found the process of using dart to be VERY painless. I'm mostly a web developer, but have taken some Java courses in college and have dabbled in a bit of C# outside of my normal PHP/JS work.
We decided to take on an app project at work. We had made one using nativescript-vue, but the experience left much to be desired and I wanted to look for alternatives.
A friend had talked favorably about Flutter so I decided to install and check it out. Within a few hours, I had a pretty good looking MVP of the app we were building (it was very basic to begin with). The experience developing a Flutter
app was really good.
It felt like I already knew the language from the get go. It worked pretty much as expected. I only had to google things like async/await because dart writes their functions like `(arg) async => expr` while javascript puts the async before the function `async arg => expr`.
YMMV if you're not using the languages which Dart draws inspiration from I guess. But I'dd be surprised if you feel you would need to spend significant amount of time learning Dart.
I really dislike C and C++, but I think your comment is needlessly hostile and insulting to C and C++ developers, and it doesn't add anything of value to this discussion. Please consider rewriting or deleting it.
I wrote extensive amount of Dart without even reading documentation and any prior Dart experience. Knowing dart is never an issue if you know basic Java/Php/JavaScript.
The only thing I really hated about Dart was poor enum support. Now that's fixed.
Exactly. Dart is a deal-breaker. I was tasked with choosing a cross-platform development solution, and rejected Flutter because nobody at my company (including me) knows Dart or has time to learn it. Nor would any contractors we were likely to find know it.
After quite a bit of research on other potential solutions, I determined (as did a crowded and lengthy thread in this forum) that Qt was the only viable one for now.
The recent proliferation of languages has been pretty annoying. Google should have at least used Kotlin. Alienating their own community of Android developers and making Flutter a pain in the ass to integrate into a development organization was dumb.
The other problem people cited with alleged cross-platform solutions is the need to write native code anyway if you need access to system/hardware resources (Bluetooth, USB, what have you).