Hacker News Reader

Comment by cjbprime | Hacker News Reader

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.)

View on HN

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

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".

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

> 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

• 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.

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

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/

There are many screenshots here, I'm not sure which one do you mean. But do keep in mind that some of these screenshots (maybe even most of them) are 10, or 20, years old, so what seems non-native to you today might be just the way things used to look.

I really do mean basically every screenshot. But take ECMerge for example. If you switch back and forth between Linux (GTK?) and Win7, you'll see that for example the toolbar is exactly the same color on each. It doesn't integrate with the Windows environment at all. But surely Windows has a native toolbar widget? And possibly even a native icon theme that you could use instead of the GTK icons. And even if not, surely wxWidgets could choose the color of the toolbar based on the desktop theme, and not just fall back to the same default colors?

Or check "Game Develop". The primary interface is a kind of weird rip-off of the MS Office ribbon, but I assume this is a custom widget. There's also a tab interface though, and this doesn't work on either the Windows or GTK versions: it's weird and has a gradient background.

In general, small details like the padding, coloration, and borders drawn around widgets seem to be slightly off on most platforms with just about very wx based GUI I've seen.

ECMerge seems to use standard wxToolBar which is definitely a native control, so I don't know why it has the same background on all the screenshots. Perhaps they've explicitly changed it to make them more similar, I really can't say. But if you create a toolbar out of the box, it will look exactly the same as in any other native application. As for the icons, wx does provide a limited set of stock icons, but this will almost never be enough, so you need to either get high quality icons in the style of each platform you support, which is obviously difficult for an open source/free program, or use the same, typically Linux-style, icons everywhere just because this is what is there, for free.

The rest of the controls (ribbon, tabs) are indeed non-native and there are no native equivalents for them, so there is not much to say here.

Generally speaking, there shouldn't be any problem with the colours unless you change them explicitly, which is a bad idea for the native controls. Not sure what is wrong with the padding and borders.

> OTOH all the standard UI elements (buttons, checkboxes, text controls, date pickers, ...) are native

Well, let's verify that… https://i.imgur.com/uHfjoUs.png No, they're not.

> draggable/dockable tabs/panels […] You can't say they differ from native ones because there is just no native version

That sounds wrong. Why should they not be? Do you have any proof?

> Well, let's verify that… https://i.imgur.com/uHfjoUs.png No, they're not.

Sorry, I don't know what is this supposed to prove, but I can definitely assure you that all the mentioned controls, and many others, are exactly native controls under the 3 first tier platforms (MSW, GTK and macOS).

> Do you have any proof?

Proof of absence of something is hard to make, all I can say is that you can go through MSDN, GTK and Cocoa documentation to convince yourself.

Wxmp3gain is from more than 8 years ago, and (it seems) you're basing your judgment on a screenshot, which is not a very solid ground. Using a modern, live, application would be a good test (keeping in mind, that some widgets may not exist in a given O/S).

Regardless, since you're accusing a very old and widespread project of lying ("it uses the platform's native API rather than emulating the GUI" on their front page, versus "I submit that Wx implements its own non-native widgets."), you should directly ask on an official channel, and have an authoritative answer.

I mentioned look and feel, and testing out the absence of context menus. This should tell you that I am not judging on a screenshot, but from live applications. I made that screenshot yesterday, and the applications depend on 3.0.4 which is from 2018.

> since you're accusing a very old and widespread project of lying

http://enwp.org/Appeal_to_accomplishment Nice fallacy, don't think you can pull cheap tricks like that on HN.

But anyway, let them defend themselves; veritas liberabit vos. FWIW I don't think malicious or intentional lies are involved, although a mighty good explanation is required to square their claim against the evidence that it is plain to see.

It would have been more productive to spend the time to find a technical answer, rather than arguing for the sake of arguing. I did search, and the answer is at the bottom.

Note that one of the posters you've been arguing with ("VZ"; argument here: https://news.ycombinator.com/item?id=24259040), turned out to be the WxWidgets maintainer. According to the comment though, mentioning this constitutes a cheap trick <rolling eyes>.

Regardless, there is a very interesting concept in the explanation: using native widgets through WxWidgets (and possibly, widget toolkits in general) requires following specific guidelines. Failing to do so will make the widgets look bad, even if they're native.

  First of all: The "VZ" who wrote in the thread you linked, is Vadim Zeitlin, the
   core maintainer of wxWidgets. His word is the highest authority in the wxWidget
  s world.
  
  My 2 cents:
  
      are all the widgets provided by WxWidgets native?
  
  No. But if a native implementation of a control exists on a specific platform, i
  t will be used (i can't think of any exceptions right now, but it's possible the
  re are a few).
  
  Most widgets are native on all platforms, e.g. wxButton, wxTextCtrl, etc.
  
  Then there are widgets that are only native on some platforms. E.g. wxDataViewCt
  rl. Is has native implementations on OSX and GTK, but as no such control exists 
  under Windows, a generic implementation is used there.
  
  Then there are widgets that have no native implementations at all, e.g. wxGrid.
  
  In general, wxWidgets just gives you the toolset to develop crossplatform GUIs. 
  That doesn't guarantee it that they'll look good everywhere out of the box. This
   also requires "good" behavior of the developer. E.g. they should not use absolu
  te values of controls sizes and positions, but use wxSizers (the wxWidgets layou
  t system) instead. Lately they must also be prepared for high-dpi screens, good 
  support for that is only available in wxWidgets for a few weeks now.
  
  Also, many open source developers only develop on one platform and hardly ever o
  r never test on other platforms. Often they just don't want to invest more time 
  to make their application look good everywhere.
  
  Regarding https://imgur.com/LjDhPOv
  
  wxHexEditor uses wxAUI, this is not native anywhere. The window with the hexdisp
  lay could be custom drawn, there is no control that does this out of the box. Or
   it might be a wxGrid, hard to say.
  
  wxMP3gain looks fine to me
  
  easyMP3Gain seems to be one of the case where the developer just didn't care to 
  make it look good.

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

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.

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

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.

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).

Reply on news.ycombinator.com