What is this ridiculous obsession with executable size? How much time did this author spend chasing down alternatives to a measly 120MB? If they're working on art project then fair enough, but if they're working on a useful program then surely anything else they could have done with that time would have brought more value to end users than shaving off 3 cents' worth of disk space.
Cross-Platform GUI Toolkit Trainwreck (2016)
11–20 of 177 posts
Re: Cross-Platform GUI Toolkit Trainwreck (2016)
#12Wonder how the author didn't come across Qt or wxWidgets in his research?
He jokingly mentions Qt in the caption of the final picture.
I guess since he excludes GTK2 at the beginning for size concerns, wxWidgets and Qt would fall into the same category.
Re: Cross-Platform GUI Toolkit Trainwreck (2016)
#13What is this ridiculous obsession with executable size? How much time did this author spend chasing down alternatives to a measly 120MB? If they're working on art project then fair enough, but if they're working on a useful program then surely anything else they could have done with that time would have brought more value to end users than shaving off 3 cents' worth of disk space.
This sort of "who cares" thinking gives us lazy bloatware like Electron.
Re: Cross-Platform GUI Toolkit Trainwreck (2016)
#14Earlier quoted context omitted.
By personal experience, wxWindows is "OK", but it's not a panacea. There are a ton of little quirks that will burn you when doing cross-platform development simply because native controls do not behave in the same way. HiDpi is a major pain with wxWindows (but then again, the way HiDpi is managed is a pain irrespective of the toolkit). But if you do some forms and basic UI controls, wxWindows does the job egregiously…
Why does electron have broken text rendering? Surely the Chrome browser’s tendering does a good job? Or do you mean something like “it doesn’t match system defaults”?
Not matching system settings (not just defaults, but the setting, i set the settings for a reason) is broken!
Re: Cross-Platform GUI Toolkit Trainwreck (2016)
#15What is this ridiculous obsession with executable size? How much time did this author spend chasing down alternatives to a measly 120MB? If they're working on art project then fair enough, but if they're working on a useful program then surely anything else they could have done with that time would have brought more value to end users than shaving off 3 cents' worth of disk space.
This sort of "who cares" thinking gives us lazy bloatware like Electron.
AKA useful software that actually does something users want, rather than some kind of ascetic practice exercise. Yes, yes it does.
Re: Cross-Platform GUI Toolkit Trainwreck (2016)
#16Wonder how the author didn't come across Qt or wxWidgets in his research?
He jokingly mentions Qt in the caption of the final picture. I guess since he excludes GTK2 at the beginning for size concerns, wxWidgets and Qt would fall into the same category.
> He jokingly mentions Qt in the caption of the final picture.
well, he can keep joking and I can keep shipping Qt apps and everyone's happy
Re: Cross-Platform GUI Toolkit Trainwreck (2016)
#17What is this ridiculous obsession with executable size? How much time did this author spend chasing down alternatives to a measly 120MB? If they're working on art project then fair enough, but if they're working on a useful program then surely anything else they could have done with that time would have brought more value to end users than shaving off 3 cents' worth of disk space.
[deleted]
Re: Cross-Platform GUI Toolkit Trainwreck (2016)
#18Earlier quoted context omitted.
By personal experience, wxWindows is "OK", but it's not a panacea. There are a ton of little quirks that will burn you when doing cross-platform development simply because native controls do not behave in the same way. HiDpi is a major pain with wxWindows (but then again, the way HiDpi is managed is a pain irrespective of the toolkit). But if you do some forms and basic UI controls, wxWindows does the job egregiously…
Why does electron have broken text rendering? Surely the Chrome browser’s tendering does a good job? Or do you mean something like “it doesn’t match system defaults”?
> Surely the Chrome browser’s tendering does a good job?
it has always looked terrible to me when comparing to other desktop apps. All the fonts look more blurry.
Re: Cross-Platform GUI Toolkit Trainwreck (2016)
#19Earlier quoted context omitted.
This sort of "who cares" thinking gives us lazy bloatware like Electron.
AKA useful software that actually does something users want, rather than some kind of ascetic practice exercise. Yes, yes it does.
Well, not really. I hate on Electron not because of its size on disk, but its runtime memory footprint. Things like Skype in the background using 500MB, an Autodesk update notifier sitting silently in the tray using 350MB etc. all add up to a few GB of main memory you suddenly don't have. And these numbers are real, by the way.
Re: Cross-Platform GUI Toolkit Trainwreck (2016)
#20What is this ridiculous obsession with executable size? How much time did this author spend chasing down alternatives to a measly 120MB? If they're working on art project then fair enough, but if they're working on a useful program then surely anything else they could have done with that time would have brought more value to end users than shaving off 3 cents' worth of disk space.
[deleted]
> If personal storage units were given away for free, you might argue that it doesn't make sense to organize your stuff, or remove stuff you don't need anymore, and you would be wrong. The least important reason to consider is to conserve disk and bandwidth; the most important is to reduce risk by reducing surface area. Small, sleek and efficient is mostly about reducing cognitive load, even if it had it's roots in mechanical resource conservation.
I agree with that much, but using GTK+ in the normal way for your language has a much lower cognitive load than any proposed alternative.
> BTW I work on a project that made this same argument years ago, writ large, for the CI system they built. "Size doesn't matter; just throw more money at instances; its cheaper than spending dev resources to make it efficient." So, now we have a development pipeline that uses more EC2 instances than production, by a factor of about 100. The build no longer runs well on (very fast) dev machines, and takes 30 minutes even on xlarge instances. The build is enormous, complex, and slow, and it was allowed to get that way because someone made the same argument you are making against a strawman.
That's a textbook slippery slope fallacy. If and when resource consumption becomes a significant issue for your use case, take measures to address that. Size absolutely can matter. But 120mb does not matter.