
Ask HN: What happened to binary sizes? - Tanegashima
Graphical Win 9x applications installer download sizes:<p>* WinAmp 2.666 = 2.1MB<p>* Opera 6.0 = 3.2MB<p>* mIRC 6.0 = 1.1MB<p>* WinZip 8.0 = 1.2MB<p>You get the idea, why today&#x27;s binaries themselves are so big, and the App bundles ridiculously big too?<p>I see that myself, I compile simple Apps and I see the executable size, and I don&#x27;t know how I could program so many megabytes!
======
vinayan3
Well all of those examples were apps with a single target architecture, win32
or win16.

These days apps have to compile for multiple architectures especially on
Android. Those are all packaged up together. Not only that these days you have
multiple sizes for image assets for various pixel densities. On top of it all
these days people rely on a lot of external libraries which may or may not be
on a phone or system. You can't depend on shared linking like when developing
for Windows back in the day.

Not to mention, fonts. Apps these days package up fonts and send them along
too.

[Edited for more content]

~~~
Tanegashima
Case: eBay for iOS

.app package: 112.9MB

Excluding all the frameworks, all the graphical resources, etc.

The binary is a whopping 30.7MB

Okay that it has armv7 and armv8, then again, it's already 15 megabyte per
architecture.

And the App is really simple, specially compared to a fully featured web
browser like Opera!

~~~
vinayan3
It takes a bit of engineering to cut binary sizes down. It depends on how much
they care and the cost they incur by having larger binaries. With building
mobile apps you get a prebuilt XCode project and it takes a lot of effort to
tinker with it to reduce binary size.

~~~
Tanegashima
I understand that.

But how could the executables? You know, the machine code, get so big.

And I'm comparing installers with just the app!

~~~
vinayan3
The machine code can be so big because people put huge strings as constants.
As I mentioned cutting down binary size comes from working on the code and
understand how the complier translate it into machine codes. The compiler
could unravel a loop, inline functions, etc... The compiler is making
decisions about binary size vs speed for you. There are ways to tell it not to
do that.

------
akoster
One app that keeps my faith in native binary apps is Telegram. Its iOS app is
usually around 40MB and keeps compatibility with old iOS versions down to iOS
6 (as of v3.18). The desktop Qt app is also around 40MB uncompressed. On iOS,
from using the app, most of the controls seem to be native and it uses minimal
custom font/image resources and outside of the code to draw Qt widgets, it
seems to be a similar situation on Windows. On macOS, the native (non-Qt) app
clocks in at 15MB [0], which was recently re-written in Swift, likely also
using mostly APIs native to the OS. Of course, not every developer has time to
devote to craft such customized software to each platform, but in these cases
Telegram does restore my faith that highly-efficient binaries can be built for
desktop apps in 2017.

[0]
[https://itunes.apple.com/us/app/telegram/id747648890](https://itunes.apple.com/us/app/telegram/id747648890)

------
overint
A lot of modern desktop apps these days tend to run in electron or similar and
require the overhead of large libraries/components (chromium for electron). A
lot the bloat seems to come unnecessary duplication of resources, but since
storage space and bandwidth is no longer as much of a premium I don't think
it's much of an issue anymore.

~~~
inetknght
It _is_ still a premium, just not to the users that these apps typically
target.

I, for one, like being able to install Linux on a 4GiB thumb drive. If your
app doesn't work with command line parameters without a GUI and can't be
installed in spare space on a 4GiB drive then your app probably doesn't target
me _at all_.

Note that there are a TON of apps that _do_ fit well within those
requirements.

------
tonyedgecombe
Bandwidth, memory and disk space are all cheap so it doesn't make much sense
to optimise them.

~~~
inetknght
The resources are cheap to developers and big-name business. The resources are
still _not_ cheap to everyone else. Small businesses generally suffer pretty
badly while the poor suffer the most. I know several poor families who have
computers from ages ago (if any) because that's all they can afford. The
computer still works for now, but it takes _minutes_ for them to do anything,
even browsing certain popular websites.

I know tons of people at small businesses who work with or on machines that
are considered "new". But these new computers are as cheap as possible. $250
for a computer is amazing. Disk space is the greatest (maybe 500GB, but it's a
spindle disk). RAM is starved (lucky if there's 4GB). CPU is typically, at
best, a Core i3, and probably more like a Celeron, Pentium, or often AMD.

The real irony? Despite having a poor-man's CPU, its utilization is usually
really low because of the amount of swapping that occurs to a spindle disk.
Having superlarge pretty fancy apps (that, honestly, business users don't
_care_ about for productivity) really kills the user experience. That's, of
course, assuming that the app doesn't have other shortcomings. Bugs and
counter-intuitiveness really hinders things too, particularly when certain
problems only show up when things run slow.

First thing I recommend to them is to invest in an SSD and some more RAM. But
the $100 for that is often out of the reach of these people.

So, to reiterate: cheap resources _to you_ doesn't mean your desired audience
also considers these to cheap too.

~~~
nevon
But to be crass, does your business really care about those users? Depending
on your business model and target audience, spending a bunch of resources to
optimize your app in order to capture more low-income users might not make
economical sense.

Even if you would like to spend that time trying to optimize your application,
my experience is that it's very difficult to get the mandate to do anything
beyond spending a few hours on it when you could be spending that time making
some new sellable feature.

