A large app in C++ with ATL (Active Template Library) or WTL (Windows Template Library) would have about the same size and speed as in C with plain Win32 API, leveraging the whole new level of abstractions, code reuse and developer productivity. The point is such things are possible, bloat is not inevitable.

Why endure such pain?

We already could use Turbo Pascal (OWL), Delphi (VCL) and C++ (VCL, MFC, OWL) on Windows 3.1 and deliver applications that could fit on a floppy.

Fltk can give you a static binary on every platform where simple GUIs are under 100KB.

Win32 isn't actually all that bad and getting simple GUI programs with icons under 10KB is completely doable.

Thinking that GUIs need to be 6 MB or painful is a complete false dichotomy.

Arguing about 10KB or 100KB applications on a comment page that's 40kb in size is somewhat silly.

It's _worth_ it to trade 1mb, 10mb or 100mb of app size in some cases. That's why you don't hand-craft your "simple 100kb guis" in assembly and have them only be 1kb. Exactly the same principle applies here.

Plus, realistically, users don't care. Not one bit. That's why Slack is out here capturing the market, while some other lightweight and exquisitely coded 10kb tool written in C isn't. Because they are shipping features the users want and iterating fast on their memory hungry and bloated platform, while the other one segfaults when there is an unencountered error.

> Plus, realistically, users don't care. Not one bit.

I disagree. I develop an audio workstation - https://ossia.io ; the total size is between 50 and 100 megabytes depending on the platforms. It uses Qt and LLVM and is itself around 500kloc so I'm already around the lower limits of what I can do.

My users, & much people on the internet keep comparing it in size to Reaper, another DAW where the binary is around 10 megabytes (https://www.reaper.fm/download.php) - but they wrote their own gui toolkit and language interpreter.

You might find this article interesting:

http://blog.johnnovak.net/2016/05/29/cross-platform-gui-trai...

well, I still think that Qt is the better solution, and so by an order of magnitude :-) it allowed me to write the software, which is being used in production in mac / linux / windows, while doing a ph.d. at the same time ; not sure I could have done the same with any of the other options in there (an older version was using JUCE but it was full of problems ; in particular JUCE's software renderer is much less efficient than QPainter). And for all of REAPER's goodness, it took decades before getting a linux version.

Oh yeah, I agree. It's a good one. Several folks in the comments called out the author for not bringing it up. Personally, I think the author had a bias where any solution had to be close to the size of the native, standalone app.

One thing I wondered about Qt is if there's a way to trim out anything an app doesn't use. Have you seen anything like that?

There's https://qtlite.com

Along with the following shell command :

    grep  --only-matching --no-filename -R 'include <Q.*>'  | cut -f2 -d' ' | sort | uniq

you can quickly see what must stay and what can go

The reason that it isn't silly is that people keep saying these larger sizes are necessary when anyone with some perspective and history in computers knows that it's ridiculous.

You can say users don't care about bloat and speed, but when they have an alternative that is clearly not the case. uTorrent destroyed the market share of other torrent clients by being lightning fast and tiny. Chrome captured market share off of being fast. IE originally killed Netscape because it 'loaded' much faster. Winamp won because it was fast and tiny. Google won because it loaded fast and the searches were fast. Google maps won because it was full screen and still faster than MapQuest. People hate the Reddit redesign because it is slow and bloated. People like hacker news' interface because it is fast. People upgrade their phones to see dramatic speed differences. A major advantage of apple is their faster CPUs.

When users have no choice, they put up with whatever bloated nonsense they have to. When they have a choice, they do actually go with interactivity and less latency.

You can be patronizing and pretend that it's archaic to care about well made software that doesn't take up 100x the resources it should need, but when someone wants software that gets out of their way, scales well, or runs on a low power platform, that 300 MB chat client isn't going to cut it.

I never said users don’t care about speed, and bloated binaries do not mean something is slower.

Also, iteration speed is something else users care about.