It doesn't do too well: http://oldweb.today/
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...
Character encoding issues, nexpected tags, big images all quickly lead to crashes.
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.
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.
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.)
That's only for graphics programming, mind you; the GPGPU interface is pretty directly representative of the GPU's internal RISC execution strategy.
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.
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.
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.
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.
[1] https://productforums.google.com/forum/#!topic/chrome/KRGYQb...
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!