It took my 2 minutes to find a laptop under $500 with 8GB of RAM. My 2011 asus laptop has 8GB RAM. I'm not going to build software with my 2005 Inspiron in mind. Don't expect people to cater to 10 year old machines.
Not everyone has $500 of disposable income, either. Not to mention that very few phones and netbooks (like Chromebooks) have more than 4GB of RAM (in fact, I'm not aware of any in either category except for the Chromebook Pixel line). Lots of people in the real world are stuck with hardware with 2GB of RAM (or less!).
I develop with those users in mind. I don't expect the average HN-reading programmer to do the same (I've long given up on that), but that doesn't mean it ain't a problem.
I also develop with users in mind, which is why I don't care how large my development environment is as long as it brings benefit to them. My original comment was a response to a person who rhetorically asked how big the node_modules folder was after installing a list of dev tools. I don't install my IDE on your phone/netbook, nor do I install my JS dev tools. Who cares how much disk space it eats up on my developer computer? I couldn't fill my disk space unless I spent a week downloading porn. My laptop cost comment was one about developer contributions, based on the belief that we were still talking about dev tools. I won't design my dev environment so that a developer with a 10 year old computer can work with me. Everything in here has been about developer workflow. The user isn't impacted by any of it. In fact, all it does is improve their experience. For an example, I have a hobby app I'm working on in node/angular2, which is an image editing platform.
$ du -sh my_app/
483MB my_app/
$ cd my_app && npm run build
$ du -sh my_app.tar.gz
3.7MB my_app.tar.gz
It unzips to 24MB, 20MB of which are the few node modules that don't play nice with my build system. Spinning it up, it takes ups 62 MB of RAM. I'd hardly consider that earth shattering to a user (the user doesn't download it anyway, it's an api deployed on a server). When I run it in dev mode, it takes up 400MB of RAM. I don't care, because that's what this computer exists for.
Memory is still the number 1 limit I have to deal with, every day. Both on my laptop, and on the server side. It remains highyl relevant exactly because of that kind of attitude.
The issue isn't a single tool. It is when you have a lot of them, and it all starts adding up.
> These are dev dependencies. If they are making it to your server, memory isn't the issue.
Yet you above suggested deploying them somewhere else. Which is exactly what I do because otherwise my laptop is constrained by the heap of bloated tools I depend on.
Not just memory footprint (which is still at least somewhat relevant, and if you've never tried to delete a node_modules folder from Windows explorer you're in for a treat. More Microsoft's fault, but still annoying), but the sheer amount of trust required for all the dependencies. Only one of those tons of dependencies needs to be subverted to do something awful to you. The attack surface is much larger than it is in other environments.
This is 2016 and devices have more memory, that's true. But ignoring memory efficiency is ignoring the basic principle of engineering and I see younger folks tend to ignore that more than olders. Having more memory available does not mean that reduced footprints are not better.
Sure, but I'm also not going to optimize dev dependencies. I care about the prod environment, but when one window of my IDE takes up 4x the memory of the app I'm actually developing, I just fail to find a reason to care about my local environment.
