4 ms·

> So, at first it sounds like they're making a technical argument against anyone who would choose to use Electron, but I think what they're actually doing is in

> So, at first it sounds like they're making a technical argument against anyone who would choose to use Electron, but I think what they're actually doing is instead expressing some kind of economic disappointment in your situation. This is a fair assessment. Still, this disappoinment is worth expressing as it makes it clear the current situation (lack of high-quality, mature, cross-platform toolkit using native widgets) is frustrating. You shouldn't be choosing between spending a lot of resources doing things right and spending a reasonable amount producing an inneficient monster that drains your users' system resources.

TeMPOraL 6y ago
That's the gist of it. However, I feel the assessment often flies in the face of Parkinson's law. Economics of software development are funny - particularly if software is a part of a bigger company, there's enough inefficiency in both software teams and the greater organization, that Electron vs. 3x native shell + shared core could not be a noticeable difference in terms overall resource expenditure. The particularly annoying part about economics here is the "limited oxygen" nature of software products. If you and I both develop a software tool, but I decide to rush it with Electron while you take it slow with native app per platform, I get to (assuming the tool is a-ok) "suck the oxygen out of the space" by releasing first, and you may lose the motivation/market to create the better tool. Which is to say, "good today" may be better than "perfect next week", but the big reason why software products suck so badly is that "shitty today" is considered better than "good tomorrow".
pizza234 6y ago
> lack of high-quality, mature, cross-platform toolkit using native widgets AFAIK, this is not correct, as WxWidgets fits the requirements (it's almost 30 years old, cross-platform and native). I'm curious though, since I haven't extensively developded GUI applications, which are the pratical tradeoffs against a non-native toolkit like Qt.
- bmn__ 6y ago
  > WxWidgets … native I don't buy it, something doesn't add up. The look and feel is somewhat out of place, one can tell with one glance it's not native. https://i.imgur.com/LjDhPOv.png https://i.imgur.com/LjDhPOv.png • The scrollbars are too narrow and have only a down arrow at the bottom instead of a combined up and down arrow. • The font size is wrong in some places in the hex editor. • The tab in the tab bar is crooked, not rectangular, and lacks a close button. • The text has too cramped kerning, most noticable in the word "File". • The underline for key shortcuts is placed too high. • The ribbing in the lower-right corner is larger. • Contrast around the menu bar is too harsh. • The icon bar does not lock (context menu), and always displays a grabber. • Menu bar and icon bar do not have a context menu. • The ribbing on the left-right split bar is different. • The MDI panel only has a close button but not a detach button. There's a obtrusive gradient in the panel title. • The progress bar does not have the stripe pattern. I submit that Wx implements its own non-native widgets.
  - VZ 6y ago
    > I submit that Wx implements its own non-native widgets. It does for the widgets that have no native equivalent, such as draggable/dockable tabs/panels that you show. You can't say they differ from native ones because there is just no native version, on any platform. OTOH all the standard UI elements (buttons, checkboxes, text controls, date pickers, ...) are native and not only they look natively, but also behave natively, which is pretty important and different from Qt.
    - bscphil 6y ago
      Not the person you responded to, but can you explain why if they're using native widgets, every single example application here [1] looks horribly integrated into the desktop? Is wx just really hard to use and every developer screws it up? Does wx use the native widgets correctly but screw up things like padding and highlights? Is the subset of widgets that are supported on every platform too limited, so everyone is forced to use non-native widgets (which apparently always look bad in wx)? PoEdit comes the closest to looking genuinely native, but the MacOS implementation is clearly flawed. [1] https://www.wxwidgets.org/about/screenshots/ https://www.wxwidgets.org/about/screenshots/

TeMPOraL 6y ago

That's the gist of it. However, I feel the assessment often flies in the face of Parkinson's law. Economics of software development are funny - particularly if software is a part of a bigger company, there's enough inefficiency in both software teams and the greater organization, that Electron vs. 3x native shell + shared core could not be a noticeable difference in terms overall resource expenditure. The particularly annoying part about economics here is the "limited oxygen" nature of software products. If you and I both develop a software tool, but I decide to rush it with Electron while you take it slow with native app per platform, I get to (assuming the tool is a-ok) "suck the oxygen out of the space" by releasing first, and you may lose the motivation/market to create the better tool. Which is to say, "good today" may be better than "perfect next week", but the big reason why software products suck so badly is that "shitty today" is considered better than "good tomorrow".

pizza234 6y ago

> lack of high-quality, mature, cross-platform toolkit using native widgets AFAIK, this is not correct, as WxWidgets fits the requirements (it's almost 30 years old, cross-platform and native). I'm curious though, since I haven't extensively developded GUI applications, which are the pratical tradeoffs against a non-native toolkit like Qt.

bmn__ 6y ago
> WxWidgets … native I don't buy it, something doesn't add up. The look and feel is somewhat out of place, one can tell with one glance it's not native. https://i.imgur.com/LjDhPOv.png https://i.imgur.com/LjDhPOv.png • The scrollbars are too narrow and have only a down arrow at the bottom instead of a combined up and down arrow. • The font size is wrong in some places in the hex editor. • The tab in the tab bar is crooked, not rectangular, and lacks a close button. • The text has too cramped kerning, most noticable in the word "File". • The underline for key shortcuts is placed too high. • The ribbing in the lower-right corner is larger. • Contrast around the menu bar is too harsh. • The icon bar does not lock (context menu), and always displays a grabber. • Menu bar and icon bar do not have a context menu. • The ribbing on the left-right split bar is different. • The MDI panel only has a close button but not a detach button. There's a obtrusive gradient in the panel title. • The progress bar does not have the stripe pattern. I submit that Wx implements its own non-native widgets.
- VZ 6y ago
  > I submit that Wx implements its own non-native widgets. It does for the widgets that have no native equivalent, such as draggable/dockable tabs/panels that you show. You can't say they differ from native ones because there is just no native version, on any platform. OTOH all the standard UI elements (buttons, checkboxes, text controls, date pickers, ...) are native and not only they look natively, but also behave natively, which is pretty important and different from Qt.
  - bscphil 6y ago
    Not the person you responded to, but can you explain why if they're using native widgets, every single example application here [1] looks horribly integrated into the desktop? Is wx just really hard to use and every developer screws it up? Does wx use the native widgets correctly but screw up things like padding and highlights? Is the subset of widgets that are supported on every platform too limited, so everyone is forced to use non-native widgets (which apparently always look bad in wx)? PoEdit comes the closest to looking genuinely native, but the MacOS implementation is clearly flawed. [1] https://www.wxwidgets.org/about/screenshots/ https://www.wxwidgets.org/about/screenshots/