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.
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.
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.
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.
Also, iteration speed is something else users care about.
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.
http://blog.johnnovak.net/2016/05/29/cross-platform-gui-trai...
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?
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