6 ms·

The way I see it: if you had infinite time and money then you would build a native app for each platform you care about, and when you choose e.g. Electron inste

The way I see it: if you had infinite time and money then you would build a native app for each platform you care about, and when you choose e.g. Electron instead you're making a tradeoff because of your available resources. When people criticize Electron, I don't think they're saying "given your capacity, you should have picked a different and better point on the tradeoff curve". I think they're just mad that you had the requirements you had and didn't get to apply more resources than you had access to. 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. (I would probably use Electron on a small budget, Qt on a medium budget, and native apps on a large budget.)

dvfjsdhgfv 6y ago
> 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/
sys_64738 6y ago
If it wasn’t electron then it’d be some other behemoth FW to fill the void. It’s what we get when computing power is so great. Eventually a bloated, lumbersome, massively layered code base runs functionally OK that it becomes acceptable and universal. As somebody who started writing 6502 assembly and appreciated the elegance (still do), the success of things of bloat like electron is soul crushing.
JamesSwift 6y ago
If I had infinite money I would use something like Xamarin.Native (aka Xamarin.iOS/Xamarin.Android aka Xamarin.Traditional aka Xamarin) to write a 90% shared codebase and develop my own UI dsl with the rest in native code. Codesharing for everything but the UI is a _huge_ maintenance win. The mechanism that Xamarin uses to do its cross platform means that you don't pay much of a performance cost to achieve this, because its mostly just a binding layer to native code (NOTE: not talking about Xamarin.Forms here).
mamcx 6y ago
I say the opposite: Build with "mediocre-first" cross platforms (all of them are mediocre) is long term the MORE costly option. With native UI, eventually the development will stop. With cross-platform, you will, FOREVER, try to catch up. P.D: i have used more than +12 main languages and as many or more UI toolkits. The native UIs are running even close to a DECADE without nothing of significance on maintain. The rest? is rewrite, recode or workaround....
- cjbprime 6y ago
  That's not the opposite of my point -- you're just rephrasing it. If I can buy a cheap roof for $2k but have to replace it every year, or an expensive roof for $15k that will last 50 years, then LONG TERM the cheap roof is the more costly option. But if I only have $2k instead of $15k, I'm not wrong to buy a cheap roof. Yelling at me about the long term costs of the cheap roof is missing the point. You're just saying that you're disappointed by my lack of $15k.
  - mamcx 6y ago
    Thats a fair point, just thinking that most think are in the second scenario (by pressures that also make cut testing, planning, etc) but really are in the first one. This happens a lot, because some of the "advice" in this industry is for "startups that if not ship something like now will die", when the majority of the work is not that disposable...

dvfjsdhgfv 6y ago

> 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/

sys_64738 6y ago

If it wasn’t electron then it’d be some other behemoth FW to fill the void. It’s what we get when computing power is so great. Eventually a bloated, lumbersome, massively layered code base runs functionally OK that it becomes acceptable and universal. As somebody who started writing 6502 assembly and appreciated the elegance (still do), the success of things of bloat like electron is soul crushing.

JamesSwift 6y ago

If I had infinite money I would use something like Xamarin.Native (aka Xamarin.iOS/Xamarin.Android aka Xamarin.Traditional aka Xamarin) to write a 90% shared codebase and develop my own UI dsl with the rest in native code. Codesharing for everything but the UI is a _huge_ maintenance win. The mechanism that Xamarin uses to do its cross platform means that you don't pay much of a performance cost to achieve this, because its mostly just a binding layer to native code (NOTE: not talking about Xamarin.Forms here).

mamcx 6y ago

I say the opposite: Build with "mediocre-first" cross platforms (all of them are mediocre) is long term the MORE costly option. With native UI, eventually the development will stop. With cross-platform, you will, FOREVER, try to catch up. P.D: i have used more than +12 main languages and as many or more UI toolkits. The native UIs are running even close to a DECADE without nothing of significance on maintain. The rest? is rewrite, recode or workaround....

cjbprime 6y ago
That's not the opposite of my point -- you're just rephrasing it. If I can buy a cheap roof for $2k but have to replace it every year, or an expensive roof for $15k that will last 50 years, then LONG TERM the cheap roof is the more costly option. But if I only have $2k instead of $15k, I'm not wrong to buy a cheap roof. Yelling at me about the long term costs of the cheap roof is missing the point. You're just saying that you're disappointed by my lack of $15k.
- mamcx 6y ago
  Thats a fair point, just thinking that most think are in the second scenario (by pressures that also make cut testing, planning, etc) but really are in the first one. This happens a lot, because some of the "advice" in this industry is for "startups that if not ship something like now will die", when the majority of the work is not that disposable...