4 ms·

It's not ridiculous. We write off executable size as something that's irrelevant in an age where you can get a 4 TB drive for (what most of the HN audience woul

by alxlaz 8y ago

It's not ridiculous. We write off executable size as something that's irrelevant in an age where you can get a 4 TB drive for (what most of the HN audience would consider) peanuts, but it's not just disk space budget that's affected. Larger executables also mean: - Longer start-up times (ridiculous things in 2019: a) SSD prices, b) the fact that it takes longer for an Electron todo app to load off a high-speed SSD than it took for basically the same application to load off my old Amiga's floppy drive) - Fewer applications that you can run at the same time, higher chance of disk thrashing when resuming from suspend (bloated frameworks still have to make it to RAM, which yes, is also cheap and abundant, but load up a few VMs and see how abundant it seems then) - Additional bandwidth used for delivering application updates - Higher battery consumption if you use antivirus software and the like, because all those bits still need to be looked at. - Sometimes it's just security theater, but not always -- a complex framework still has an attack surface even if your application doesn't use all of it. These things save way more than a few cents' worth of disk space.

lmm 8y ago
Sure. However long it takes to read 120mb off a disk (most likely less, if the application is only using some of the GTK dlls). 120mb of RAM. 120mb more to read when restoring from suspend. 120mb extra data use over your home internet connection. (I'm not going to talk about antivirus time because if you're using antivirus in 2019 you deserve whatever happens to you). It's still all irrelevant. Put a monetary or human-time value on it and compare to the cost of the application, or the development time, or a single crashing bug. Our programming culture's priorities are so far skewed from whats' actually important.
- xfer 8y ago
  All that multiplied by the number of customers. If you don't value your customers, then they are all "irrelevant". > Our programming culture's priorities are so far skewed from whats' actually important. Indeed, that's why there are so many electron based bloatware being developed.
  - lmm 8y ago
    All development effort is multiplied by number of customers though. Like, if you put that time and effort into developing a new useful feature, the value of that is multiplied by number of customers too.
    - badsectoracula 8y ago
      xfer means to multiply the cost of the wasted resources by the number of customers, since it is they who will have to waste those resources, not you. On the other hand the resources spent to implement the new useful feature will only be used by you, not your customers, so you do not get to multiply that.
- alxlaz 8y ago
  > I'm not going to talk about antivirus time because if you're using antivirus in 2019 you deserve whatever happens to you If you develop enterprise applications (which many Electron applications are, in fact :-) ), you really have to talk about antivirus time. It's not something you can wish away. And it's not something that you should ascribe to customers being irrational, either. If malware compromises your users' data and it turns out you're not running antivirus software on your computers you're gonna pay way more than you'll ever save by using a big fancy framework. Sure, it's a bad idea (in strictly technical terms) but you can't just go to your customers with a straight face and ask them to stop running antivirus software because it's 2019. > Put a monetary or human-time value on it and compare to the cost of the application, or the development time, or a single crashing bug You say it as if these were independent, but they're not. Debugging performance issues (the critical kind, that make customers yell at you and utter words like "money" and "back") in Electron applications is a mini-project in and of itself. Complex frameworks (I'm not picking on Electron in particular) are cool to quickly develop against, but not cool to troubleshoot, and once you start going off the beaten path, it's not as fun. Of course, sometimes it's a justified choice, I'm not in the "Real Programmers don't use Electron" camp. But the non-technical aspect of this engineering choice is slippery, as non-technical aspects always are. Sometimes it's the right choice in terms of organization expertise and whatnot, but sometimes it just appeases executive impatience, at the expense of customer experience.
  - lmm 8y ago
    > Debugging performance issues (the critical kind, that make customers yell at you and utter words like "money" and "back") in Electron applications is a mini-project in and of itself. Complex frameworks (I'm not picking on Electron in particular) are cool to quickly develop against, but not cool to troubleshoot, and once you start going off the beaten path, it's not as fun. You can do a lot of debugging and performance tuning in the amount of time it takes to write a custom non-framework GUI. But you're right that it's much less fun for the programmer, which I suspect is the real motivation here.
  - AnIdiotOnTheNet 8y ago
    > If you develop enterprise applications (which many Electron applications are, in fact :-) ), you really have to talk about antivirus time. It's not something you can wish away. In enterprise applications you totally can just wish AV away by turning it off. It's useless at best and mostly serves to just gum up the works and slow things down without providing tangible benefit. There are much better ways to handle security in an org.

by alxlaz 8y ago

lmm 8y ago

Sure. However long it takes to read 120mb off a disk (most likely less, if the application is only using some of the GTK dlls). 120mb of RAM. 120mb more to read when restoring from suspend. 120mb extra data use over your home internet connection. (I'm not going to talk about antivirus time because if you're using antivirus in 2019 you deserve whatever happens to you). It's still all irrelevant. Put a monetary or human-time value on it and compare to the cost of the application, or the development time, or a single crashing bug. Our programming culture's priorities are so far skewed from whats' actually important.

xfer 8y ago
All that multiplied by the number of customers. If you don't value your customers, then they are all "irrelevant". > Our programming culture's priorities are so far skewed from whats' actually important. Indeed, that's why there are so many electron based bloatware being developed.
- lmm 8y ago
  All development effort is multiplied by number of customers though. Like, if you put that time and effort into developing a new useful feature, the value of that is multiplied by number of customers too.
  - badsectoracula 8y ago
    xfer means to multiply the cost of the wasted resources by the number of customers, since it is they who will have to waste those resources, not you. On the other hand the resources spent to implement the new useful feature will only be used by you, not your customers, so you do not get to multiply that.
alxlaz 8y ago
> I'm not going to talk about antivirus time because if you're using antivirus in 2019 you deserve whatever happens to you If you develop enterprise applications (which many Electron applications are, in fact :-) ), you really have to talk about antivirus time. It's not something you can wish away. And it's not something that you should ascribe to customers being irrational, either. If malware compromises your users' data and it turns out you're not running antivirus software on your computers you're gonna pay way more than you'll ever save by using a big fancy framework. Sure, it's a bad idea (in strictly technical terms) but you can't just go to your customers with a straight face and ask them to stop running antivirus software because it's 2019. > Put a monetary or human-time value on it and compare to the cost of the application, or the development time, or a single crashing bug You say it as if these were independent, but they're not. Debugging performance issues (the critical kind, that make customers yell at you and utter words like "money" and "back") in Electron applications is a mini-project in and of itself. Complex frameworks (I'm not picking on Electron in particular) are cool to quickly develop against, but not cool to troubleshoot, and once you start going off the beaten path, it's not as fun. Of course, sometimes it's a justified choice, I'm not in the "Real Programmers don't use Electron" camp. But the non-technical aspect of this engineering choice is slippery, as non-technical aspects always are. Sometimes it's the right choice in terms of organization expertise and whatnot, but sometimes it just appeases executive impatience, at the expense of customer experience.
- lmm 8y ago
  > Debugging performance issues (the critical kind, that make customers yell at you and utter words like "money" and "back") in Electron applications is a mini-project in and of itself. Complex frameworks (I'm not picking on Electron in particular) are cool to quickly develop against, but not cool to troubleshoot, and once you start going off the beaten path, it's not as fun. You can do a lot of debugging and performance tuning in the amount of time it takes to write a custom non-framework GUI. But you're right that it's much less fun for the programmer, which I suspect is the real motivation here.
- AnIdiotOnTheNet 8y ago
  > If you develop enterprise applications (which many Electron applications are, in fact :-) ), you really have to talk about antivirus time. It's not something you can wish away. In enterprise applications you totally can just wish AV away by turning it off. It's useless at best and mostly serves to just gum up the works and slow things down without providing tangible benefit. There are much better ways to handle security in an org.