> I don't understand this claim at all. Qt (or GTK) let's you "escape out" to the "native" toolkit on Windows or macOS as needed.
You're kind of fighting against Qt or GTK when you do that. Qt and GTK have their own widgets. React Native is more of a framework that uses native toolkits to begin with, so it starts out with much better alignment with platform expectations, and has better interoperability with platform features.
> There are not multiple "native toolkits" on Windows or macOS.
I'm confused by this comment. I don't know what kind of point you are trying to make here, or what you are responding to.
> So basically, you're denying that it's possible to do excellent cross-platform apps at all. OK. I'm not sure I agree with that, but it's a position.
Yeah, let's dial the "it's a position" condescension back one or two notches.
When I said, "Different platforms are just slightly too different from each other to make it work well," the "it" refers to cross-platform toolkits like GTK and Qt, which provide their own widgets. This explains why so many people use Electron and just embed a web browser (let's say "fuck it" and make one UI inside a big window), or choose to use something like React Native. Maybe I'm drawing too fine a line here--I think of Qt and GTK as cross-platform toolkits, I think of React Native as a framework without the toolkit parts, and I think of Electron as some kind of cross-platform box that you can something inside. I'd rather not talk about the definition of "toolkit" or "framework" because the definitions are not material.
Qt is a big honking mess, and GTK is worse. Speaking as someone who has written apps using both, and fixed UI problems in people's open-source Qt and GTK projects.
> This explains why so many people use Electron and just embed a web browser
I would wager there are 100x the number of Qt/GTK apps than there are electron apps. That number could go up or down by an order of magnitude, and the older widget-based toolkits would still be ahead. So ... I don't think that citing numbers of developers doing X or Y is helpful here.
> React Native is more of a framework that uses native toolkits to begin with, so it starts out with much better alignment with platform expectations
More similar to WxWidgets then, which uses native widgets but wraps them in lowest common denominator API. For one reason or another WxWidgets hasn't been as successful as one might expect.
Anyway, as I've noted elsewhere in this thread, the majority of creative apps (including Logic) barely use any of the native toolkit within their main windows. Almost all DAWs, drawing programs and image editors just treat their windows as a big 2D drawing surface, and do their thing without regard for UI/UX widgets or rules designed around productivity/business/system utility apps. The "native" aspect kicks in only when they interact with the rest of the desktop environment, and they vary quite a bit in how native they go (they also keep changing this; Logic has gone back and forth with using the native file browser vs. an app-specific one several times over its life, and in different contexts within the app).
This also has implications for the extent to which Qt/GTK/etc. toolkits impact the UX. If someone writes a widget-heavy app, then the toolkit design & implementation will have a strong impact. If the widgets are limited to some toolbar at the top, it doesn't really make a lot of difference as long as the devs get system tray/notification right, and don't screw with window management.
> I would wager there are 100x the number of Qt/GTK apps than there are electron apps. That number could go up or down by an order of magnitude, and the older widget-based toolkits would still be ahead. So ... I don't think that citing numbers of developers doing X or Y is helpful here.
If making the comparison is not helpful, then why make the comparison in the first place? I was just observing that "many" developers made the choice to use Electron; I am not trying to compare numbers of developers here.
> More similar to WxWidgets then, which uses native widgets but wraps them in lowest common denominator API. For one reason or another WxWidgets hasn't been as successful as one might expect.
Yeah, although I think WxWidgets abstracts too much.
Maybe I can frame it this way--I'm not really against cross-platform toolkits in the first place, and I'm not complaining about cross-platform toolkits on a conceptual level. I do think that apps made with cross-platform toolkits often have UX problems and I think part of the reason is because the underlying platforms are too different. Those differences are both (edit: fix) technical differences and differences of conventions / expectations.
React Native seems to have less abstraction. Maybe that's just my subjective thoughts on it.
> Anyway, as I've noted elsewhere in this thread, the majority of creative apps (including Logic) barely use any of the native toolkit within their main windows.
Sure, if you focus narrowly on the main content of the main window, you'll see less of the native toolkit being used. But that's only one part of the app, and it's still built to match platform expectations, in a way that is not easily abstracted out by cross-platform toolkits.
Logic is a bit of a funny example because Apple has a separate set of "pro" widgets they use for their creative apps, like Logic and Final Cut. You can see that, for example, Logic has a decent number of .nib files, which means that it's making use of the native toolkit, even if it's not everywhere.
Finally took a look, and this appears to be mobile only. Certainly covers one definition of cross-platform, but a little different than the other toolkits we've discussed.
Nope, React Native does support targeting Windows and macOS (and, though with less love, Linux) and even Web, tvOS, Android TV, and more. It’s just that iOS and Android are the only official Meta-maintained ones.
The macOS and Windows implementations are solid, being maintained by Microsoft, and are even used in small corners of Microsoft Word and other flagship apps.
Some further digging does reveal the non-mobile stuff but sheesh, that is so easy to miss. Incredibly obvious to conclude that it would not be relevant. And indeed, even where they mention the macOS & Windows targets, no mention of Linux.
You're kind of fighting against Qt or GTK when you do that. Qt and GTK have their own widgets. React Native is more of a framework that uses native toolkits to begin with, so it starts out with much better alignment with platform expectations, and has better interoperability with platform features.
> There are not multiple "native toolkits" on Windows or macOS.
I'm confused by this comment. I don't know what kind of point you are trying to make here, or what you are responding to.
> So basically, you're denying that it's possible to do excellent cross-platform apps at all. OK. I'm not sure I agree with that, but it's a position.
Yeah, let's dial the "it's a position" condescension back one or two notches.
When I said, "Different platforms are just slightly too different from each other to make it work well," the "it" refers to cross-platform toolkits like GTK and Qt, which provide their own widgets. This explains why so many people use Electron and just embed a web browser (let's say "fuck it" and make one UI inside a big window), or choose to use something like React Native. Maybe I'm drawing too fine a line here--I think of Qt and GTK as cross-platform toolkits, I think of React Native as a framework without the toolkit parts, and I think of Electron as some kind of cross-platform box that you can something inside. I'd rather not talk about the definition of "toolkit" or "framework" because the definitions are not material.
Qt is a big honking mess, and GTK is worse. Speaking as someone who has written apps using both, and fixed UI problems in people's open-source Qt and GTK projects.