Hacker News Reader

Comment by viraptor | Hacker News Reader

This way of thinking works as long as you have very few bloated apps.

It stops working once it affects literally everything. 1password? Few hundred MB (unless it goes crazy into few GB sometimes). Browser? A GB or so. Some electron apps? Another GB. It really adds up, but no single app will take responsibility because "what else are you going to use the memory for?"

View on HN

Where do you think the trade-off should be? For memory to go down, something else has to go up.

Why are you so sure that memory is the wrong place to put the trade-off?

I'm sure it's the wrong place to put the trade-off all the time on memory, because we already see that failing. Few people have the 16gb systems mentioned above. It's the reason ripcord (https://cancel.fm/ripcord/) can exist and charge money even though slack client is available for free.

I expect time-to-market is the trade-off in this case, but I'm not even sure about that. (For example ripcord is written by one person - how many web developers does slack have?)

It’s the wrong place to put the trade off because I highly doubt I’m receiving more value from Dropbox using 500MB as compared to 100MB. Unlike what VCs are telling Dropbox, I only want something to sync files from one computer to another and it most certainly is not the center of my workflow.

In my opinion, it reeks of lazy engineering brought about my PMs who want to turn Dropbox into something it isn’t.

The discussion is about dropbox, a background service that used to have much more reasonable memory use and for which has competitors using far less memory. A trade-off isn't necessary.

> For memory to go down, something else has to go up.

Like code quality and efficiency?

Reply on news.ycombinator.com