Disk Space Isn't Meaningless

It's impossible to discuss Electron without the topic of space being brought up, and once that happens, you have to survive the talk about how storage is cheap today and space just doesn't matter anymore.

Here is why I think all that is bogus -- for bonus points, without any unironic use of the terms "engineering", "real programmers" and "web developers"

Every megabyte of code or assets counts towards more than just disk space. It also counts towards:

  • Startup time. Even in the age of SSDs and fast processors, when a runtime has to go through millions of lines of code just to get to a state where it can paint a pixel on the screen, you notice that.
  • Battery life. Every second spent rummaging through assets, paging stuff to and from disk, or executing overly abstracted code, is time that's spent draining the battery at a significant rate. You also find some of this time in places other than an application: in file indexers or antivirus software, for example, which also have to go through all that data.
  • Data traffic. This is especially problematic for urgent updates, like security or critical functionality fixes, which can't always be delayed.
  • Security and privacy. Even when normally unused, the code of a complex framework is still there, one function call away. The more of it there is, the more of it can be exploited.

Plus, disk space and fast Internet are not cheap for everyone. Chances are, if you're a developer who can afford to spend some time debating these things, the price of a new, high-performance SSD is peanuts for you.

It's not like that for everyone.

The jobs of many developers proverbially depend on not understanding this fact. Most of us don't have this excuse though, and we owe it both to our peers and to the users of our software to make this point.

I am not advocating for a native-only approach to application development. That's obviously silly in 2018 (2019 in 3, 2, 1...). But I am advocating for:

  • A more critical approach to disk space and complexity in web-based client-side applications. Yes, engineering is (also) the art of compromise, but not any compromise will do.
  • A more critical approach to technology selection -- including, yes, writing a native application as soon as it turns out to be the best thing for your customers.