|
First off, I was not talking about native vs non-native, I was talking about toolkits. native vs non-native is a different though related problem. > And why wouldn't a hybrid approach work? I.e. the majority of the code using the cross platform toolkit, and a small amount of code per platform using the native API. I literally said you could/should do that? Answering your actual question though. The issue is not "something can only be done" in X, it's a "is your app consistent with the platform it is on". And that's where "cross platform" apps are invariably annoying - none of the electron apps correctly do find on the Mac (this is largely because chrome/blink intentionally removed the correct logic from webkit and as these apps just do whatever blink does that's what we get). The problem is that cross platform toolkits (Qt, Wx, etc) primarily target windows so all the behaviors are geared to that platform. It is very obvious whenever you are using a Mac app that is written using a cross platform toolkit, as their are just many different little ways that things behave incorrectly - a death by a thousand cuts problem. Electron is just a special case of this: because your "app" is just a web page you don't have an actual ui toolkit, cross platform or otherwise, to handle all the usual UI behavior and have to reimplement it all yourself. That's a lot of work and very hard to get right, so generally electron apps don't even attempt to, but they're "popular" because there's literally no choice. People on Mac use discord, slack, teams, etc because there is no option - if your employer decides they're using slack or teams, that's what you have to use. The fact that the UI is janky, the cpu is high, basic key commands don't work, it doesn't handle drag and drop correctly, etc is not relevant: it's what you have to use. |