How is that different from all the other 20+ year old UI toolkits out there? What is so special here, other than “google”?
The more interesting question is "Why does Flutter exist?" Google is, after all, a business. What's the ROI? Here's my theory: Google is known to be developing a new operating system from scratch called Fuschia[1]. Many many OSes have died in the crib because there was no app ecosystem for them, and thus the cost of switching to the "new thing" was too high for users. How do you solve this problem? Maybe if you create a cross-platform app development framework that lets developers write for the two incumbents while also ensuring compatibility with your new OS...
[1] https://9to5google.com/2018/01/23/what-is-google-fuchsia-os/
I don't care much about Google but they did pretty good job with Flutter:
1. No special designer needed, you do everything in code. That means everyone can use their preferred editor.
2. Hot reload - you change something and it changes in the running app.
3. Headless testing - No need to own iOS/Android device to test iOS/Android UI.
4. Nice tooling - autocompletion, formatting, etc. Everything done via command line, with optional support for IDE.
5. Extensible - very easy to write your own widgets. There is nothing special about provided components.
6. Platform agnostic - "native look" of Qt/GTK is a lie, they still look off. To me it just triggers uncanny valley vibe. Not to mention that they implement native look from 5 years ago or more. And completely useless on mobiles. Flutter looks the same on every platform unless specified otherwise. Way less platform specific bugs.
All those things you mentioned are true of Xamarin.
qt uses actual native controls, so not sure what is a "lie" about it; if something is not behaving correctly, it's a bug, and you open an issue. GTK does look bad and out of place, I agree with that, bug so does Electron. If it's between GTK and Electron, I'll take a proper GTK application.
Looks the same = looks bad on all platforms.
Flutter is different. There's nothing even close to it when it comes to writing mobile apps.
Flutter takes the best ideas about UI toolkits, layouts and has the benefit of really good engineers (most are Chrome/WebKit veterans) working for a really long time to make a really good implementation of those ideas.
Hot reload of code is just one feature that is absolutely unique to Flutter, at least when comparing to alternatives viable today (I'm sure are smalltalk implementation that also allowed that but no-one is using them today).
It's still a beta product so skepticism is warranted but I can see the writing on the wall. 2 years from now it'll be crushing other technologies the way React/Vue is crushing in web space because Flutter is just So Much Better.
Your nonchalant mention of "Xamarin or whatever" means to me you have little experience with that.
You say that Flutter takes the best ideas of UI toolkits, but then say it's mostly web engine developers. So which one is it? Let me guess, they are using Flex as layout? So hardly the "best ideas". Edit: Yes, flex [0]
On the other hand, I don't need to use it to predict how bad quality apps will turn out to be. Just like Electron and React Native apps are bad, so will Flutter apps be, for the simple facts no native controls are used. (React "Native" is not native at all.) Even the best implementation (which Electron and React Native do not have) would still mean bad apps simply because they are not using native widgets.
You seem to only care about developer experience—which I disagree as well. I only care about user experience. User experience is king and developer experience is complimentary.
[0] https://github.com/flutter/flutter/blob/master/packages/flut...
You could live-reload Qt code for years (https://doc.qt.io/QtQmlLive/index.html)
Sure it would be the best to go fully native and hire 3 iOS + 3 Android devs, but who will do this when they can have 95% of the same with 2 flutter devs?
The usual fallacy. What you can do with 2 cross platform developers + 1 iOS + 1 Android, you can achieve with 1 iOS expert, 1 Android expert and one who can do both iOS and Android well enough.
> but who will do this
Anyone who wants quality apps. So basically not most start ups, I guess.
> can have 95% of the same with 2 flutter devs
False. Just like it's false with Electron and React Native. At most you have 75%, and that's the most simplest apps. At least with React Native, you can somewhat easily integrate native components. It's ridiculously hard with Flutter. (For example, see how long it took to integrate with MapKit.)
actually, no, it fetches info from the native themes to get the colors, fonts, etc.. right, but all the controls are rendered by Qt. It does a pretty good job at it - enough that even microsoft uses it for some windows apps such as OneDrive (https://forum.qt.io/topic/87898/microsoft-onedrive-sync-uses...)
On Mac, they use native widgets:
https://github.com/qt/qt/search?utf8=%E2%9C%93&q=qt_mac_nati...
It is painted here:
https://github.com/qt/qt/blob/0a2f2382541424726168804be2c90b...
This calls at some point QStyle::drawControl which ends up here on mac : https://github.com/qt/qt/blob/0a2f2382541424726168804be2c90b...
this ends up here in this big switch : https://github.com/qt/qt/blob/0a2f2382541424726168804be2c90b...
which leads us here, in the drawComboBox function where mostly everything is done by hand: https://github.com/qt/qt/blob/0a2f2382541424726168804be2c90b...
and also here: tadam, actually it just uses the "windows" (actually fairly generic and themeable) style for drawing : https://github.com/qt/qt/blob/0a2f2382541424726168804be2c90b...
See also this qt blog: http://blog.qt.io/blog/2017/02/06/native-look-feel/
sure, but that's not the same as using a NSComboBox directly, and that's not using Apple's layout engine (based on cassowary, wasn't it) either. Not that I think that this is a bad solution : it allows software with a strong identity to have fairly custom UIs that are consistent across platforms.