3 ms·

I know this is kind of a tired comment but I wonder where desktop GUI toolkits went wrong to end up where "cross platform" has come to be a synonym for electron

I know this is kind of a tired comment but I wonder where desktop GUI toolkits went wrong to end up where "cross platform" has come to be a synonym for electron. I know if I was building a desktop program I would pick electron but what can real desktop toolkits change to fix this problem?

pjc50 7y ago
Largely they can't, other than having a Highlander situation where they fight each other until only one platform remains. Java went round this circle. First there was AWT: use the platform-native widgets. Of course, this results in your application looking different on every platform in hard-to-predict ways. So people wrote Swing: single non-native GUI that looks the same everywhere. Eventually people got fed up of the poor performance and non-nativeness of Swing, so they wrote SWT (used in Eclipse) which uses the native widgets again. If your application is native, then it looks different on different platforms - and you have to test and debug on all of them. If it's non-native, it can look the same on all platforms.
- tty2300 7y ago
  Looking different to the native apps isn't even the worst part. Its that a simple notes app is 300mb and after opening a few basic programs you have 10gb of ram used.
Crinus 7y ago
It might not be so much a toolkit problem as a language or environment or even knowledge problem: someone might not be interested in working with C or C++ or even in anything else they do not already know and if all they know is web stuff then Electron is the path of least resistance. Even if someone is interested in learning something, that doesn't mean they'd be interested in learning and making a project at the same time.
quickthrower2 7y ago
I think a React-native type thing for Windows/Mac/Linux would be a big help. I am not sure there is any incentive for anyone to create such a tool though? The problem with Electron is that it is good enough.

pjc50 7y ago

Largely they can't, other than having a Highlander situation where they fight each other until only one platform remains. Java went round this circle. First there was AWT: use the platform-native widgets. Of course, this results in your application looking different on every platform in hard-to-predict ways. So people wrote Swing: single non-native GUI that looks the same everywhere. Eventually people got fed up of the poor performance and non-nativeness of Swing, so they wrote SWT (used in Eclipse) which uses the native widgets again. If your application is native, then it looks different on different platforms - and you have to test and debug on all of them. If it's non-native, it can look the same on all platforms.

tty2300 7y ago
Looking different to the native apps isn't even the worst part. Its that a simple notes app is 300mb and after opening a few basic programs you have 10gb of ram used.

Crinus 7y ago

It might not be so much a toolkit problem as a language or environment or even knowledge problem: someone might not be interested in working with C or C++ or even in anything else they do not already know and if all they know is web stuff then Electron is the path of least resistance. Even if someone is interested in learning something, that doesn't mean they'd be interested in learning and making a project at the same time.

quickthrower2 7y ago

I think a React-native type thing for Windows/Mac/Linux would be a big help. I am not sure there is any incentive for anyone to create such a tool though? The problem with Electron is that it is good enough.