So mentioning DOOM 1 VS webpage sizes reminded that up until not that long ago all of my software had to fit under 16MB (megabytes!) of RAM and didn't have much trouble at that.

We could fit a fully functional app in a couple of kilobytes (!!) on PalmOS but Android apps take dozens of megabytes like it's nothing.

I get that bigger resolutions means bigger art assets (unless you use vector art and you probably should) but with the exception of games and media.. why the heck is everything so heavy now days?

@polychrome I released an Android app with mostly vector assets yesterday. The Java libraries took most of the space.

@polychrome Adding to what @rysiek said.

As a developer, I have limited time (and incentive). I could implement something in say a 100 lines of code with 4 hours of effort or just import a 1MB library from which I might call one or two functions. This will end up increasing the size of the package that gets delivered to the end user, though there are some optimizations during the packaging process.

Same goes for Javascript libraries on the web.

(1/2)

Follow

@polychrome @rysiek

In some scripting languages like Ruby or Python, you install the libraries at the system level. This combined with a good package manager (e.g. apt on Debian) will keep the size of your software small, since it can share the libraries with others.

But not much difference in terms of size at runtime.

It's mostly a developer incentive issue more than framework or OS.

@rysiek @njoseph as a developer I am probably a bad example because I tend to avoid libraries and obsess about code optimization whenever possible. I just figured something has gone very weird since I did as I haven't done serious development in the past decade or so.

@njoseph @polychrome @rysiek And then there's Window's .NET assembly which keeps all versions of all "shared" libraries in the WinSxS folder...

Sign in to participate in the conversation
Mastodon

This is a general instance supporting toots in English and తెలుగు.

Hero image credit: Sean O'Brien (CC BY-NC-SA 3.0)