Hacker News Reader

Comment by wtbob | Hacker News Reader

So, Netscape Atlas was 6 megabytes in June 1996; Firefox for Windows 64-bit is 45.2 megabytes today (I picked the Windows download because it sounds like this guy was using Windows back then); that means the size has multiplied by 7.5 over the last twenty years, for an annual increase of about 10½%. That's — not terribly great, actually.

OTOH, according to http://www.jcmit.com/diskprice.htm disk prices have been dropping by almost a third every year, with the result that the cost of a Firefox install in 2016 is less than 1/500th the cost of a Netscape install in 1996. That's pretty awesome!

View on HN

I would like to think that after 20 years of effort, Netscape actually does more than 7.5 times as much stuff as it did in 1996. Assuming the original version even runs anymore, you should fire it up and see how it compares to a modern web browser.

> Assuming the original version even runs anymore, you should fire it up and see how it compares to a modern web browser.

It doesn't do too well: http://oldweb.today/

Wonderful link - thanks!

Found this alarmingly prescient piece on the BBC site from 2000:

http://news.bbc.co.uk/1/hi/sci/tech/874419.stm

'The next generation of mobile phones will make it much easier for the police to carry out covert surveillance of citizens, say civil liberty campaigners.'

Hmm, I wonder how that will play out...

Absolutely fascinating site, thanks! I felt incredibly nostalgic loading Netscape on Mac OS and using those squidgy grey menus. Wow do I suddenly feel old and miss those old simple machines (the OS version is 7.5.5).

The last time i tested old browsers it was impossible to view anything. The main problem is the Host field isn't sent by a lot of browsers from that time, and sites won't respond.

Character encoding issues, nexpected tags, big images all quickly lead to crashes.

> I would like to think that after 20 years of effort, Netscape actually does more than 7.5 times as much stuff as it did in 1996.

Does it though? In 1996 it included a mail client, a news client and a gopher client along with its HTTP & FTP clients. It even had JavaScript back then (I'm just going to take a moment to lament that JavaScript could have been Scheme — I don't even like Scheme as a language for programs, but as a language for web pages and web apps it would have been plenty good enough, even excellent!). It displayed images; it displayed HTML.

Honestly, 1996 was a pretty good year for browsers.

>I would like to think that after 20 years of effort, Netscape actually does more than 7.5 times as much stuff as it did in 1996.

This is precisely the problem the article is about. Why should one application grow 7.5 responsibilities instead of those being in separate applications? It's simply poor design, and now we're stuck with it.

To some extent, the 7.5 times (stuck with this arbitrary figure now …) more things that it does are not necessarily externalisable bloat—it hasn't grown an e-mail client (I think?)—but rather a response to the increasing demands of modern web pages. Offloading, say, JavaScript processing (a not-insignificant part of modern browser code, I think) to a separate application is surely possible, but also surely pointless.

I would assume that most of the logic for what Netscape did was embedded in the Netscape binary, while most modern browser features are 1% browser binary code, and 99% calls into the huge iceberg of OS-provided libraries.

Compare, for example, how VRML worked (entirely software rendering, all the code inside the browser) to how WebGL works (an API to talk to the OS graphics driver, which in turn is just a very fat API on top of the very CISC instruction set of a GPU.)

Not true. To keep things compatible and minimize platform bugs, browsers embed a lot. Firefox has it's own jpeg, png, video codec and spelling libraries built-in. Try compiling it sometime. It takes forever.

Why do you say that the GPU has a "very CISC instruction set"? The RISC/CISC divide is a somewhat historical notion, and GPUs don't really seem to fall in either camp to me (separate load/store + tons of GPRs + VLIW = RISC-like, transcendental functions + texture fetch with interpolation = CISC-like).

I was taking a bit of poetic license there; what I meant is that the ABI that the GPU presents to the CPU contains a number of high-level instructions that must be further decoded within the GPU, in the same way that modern "CISC-presenting" processors decode CISC ops into RISC μops.

That's only for graphics programming, mind you; the GPGPU interface is pretty directly representative of the GPU's internal RISC execution strategy.

How much of that is purely graphical and other resources though? Like the hi res image on the opening page, all the icons, translations etc.

I saw someone do a similar analysis recently about how bloated vim had become but it was mostly documentation (plus translations) and stuff like that, not vim itself.

Even graphical resources are probably not stored as optimally as they could be, given what the demoscene can do in a 4 kilobyte binary... one of my pet peeves is gradients, simple shapes, or even completely flat regions of colour(!) stored as bitmaps. I've seen apps with multiple sizes of the same simple --- as in completely linear --- gradient stored as uncompressed bitmaps.

I some someone do a similar thing about how bloated vim had become but it was mostly documentation (plus translations) and stuff like that, not vim itself.

Which then begs the question, "I only need the English version. Why am I forced to download a dozen other languages I'll never read or even knew existed?"

That also reminds me of a few programs I've come across that inexplicably let you dynamically change their UI language to one of around a dozen choices (and all the language names were in English too...) If I remember correctly, it was something simple like a file converter or downloader where most of the UI was icons anyway, and around 90% of the installer package's size was these resource files. Just... why.

> I've seen apps with multiple sizes of the same simple --- as in completely linear --- gradient stored as uncompressed bitmaps.

Android required this at one point for different resolutions. I'd be surprised if the svg proccessing used more time and battery (not to mention space) than loading uncompressed images from disk.

> Which then begs the question, "I only need the English version. Why am I forced to download a dozen other languages I'll never read or even knew existed?"

I guess that's down to the limitations of various app stores/package managers. All the windows deployment options are awful enough that that I'd bundle everything too. I'm not aware of app stores that allow dependencies or optional packages. Billions of dollars flow through these stores but they're still more limited than apt.

Packages managers (apt, chocolaty, etc) can do it but would still need a few tweaks to do it well.

At least in pacman, you have to download the entire archive (because the packager's GPG signature goes over the full archive file), but you can set the NoExtract option e.g. to avoid the translations from being extracted: https://github.com/majewsky/system-configuration/blob/master...

Which then begs the question, "I only need the English version. Why am I forced to download a dozen other languages I'll never read or even knew existed?"

Because packagers don't have the patience to split them up. LibreOffice on Debian & derivatives, for example, has a different package for each localization plus a different package for the Help files in each language.

Chrome for Windows on the other hand is 405MB, which is quite an astonishing difference.

Chrome for Windows also doesn't remove the prior version when updating [1], so you typically have at least two versions on disk.

[1] https://productforums.google.com/forum/#!topic/chrome/KRGYQb...

Installed? Or the installer?

Installed. I'm not counting the update files it keeps on disk either.

the original builds of Phoenix were 8MB. Firefox (the later evolution of Blake Ross' project) ballooned to 45.2MB.

Reply on news.ycombinator.com