To put this in perspective, I was talking this week to a developer who was essentially apologising to me for a new feature that was going to require insane amounts of memory. This is for a process to handle literally millions of users.
How much memory was it? 3G. Per "instance" of which we need 2... Again, for millions of people.
I think "team software engineering" plays a big part of this, if not even the main reason. When one developer is working on a program, the person tends to be able to keep track of program flow, memory usage in their head and know when things are about to go out of bound, memory shoots up, etc. When you have a whole team working on a huge piece of software, each person is working on one part of it at a time. If your feature grows memory usage by 100mb, it's not a big deal. 20 people doing that, memory usage just grew by 2gb. And then in modern software dev shops, you typically put devs on different features on a weekly basis. (unlike traditional, slow, non-agile development where a person owns a certain module/component and is the expert and works on it for years) When you move to a new feature, you need to pick up on all the details of how it works previously, and you build your stuff on top of it. You don't have context of the really nitty gritty details someone who wrote the original framework thought about. You're going to do something less than ideally efficient. Unfortunately, this is just the way modern team software engineering goes.
Or of course, you can still just say it's a Javascript problem and mock JS; which also has merits.
You're not wrong, but perhaps that's an indication that software companies should use language & environments which enable them to have fewer developers, and enable those developers to keep track of things like resource usage?
Whereas traditionally you would have an engineer responsible for part of the application as time goes by, making sure that it works better while maintaining quality.
Then don't freaking do that. There's no reason to make one huge app with thousands of features that justifies teams of dozens of devs instead of tools that do just one thing (and can be used in a modular way) correctly and nothing more.
Actually, there's one terrible reason: the bigger the app, the higher the wall around the garden and that serves as a justification for the price tag. It's the wrong way of doing things because business. It's exactly the same evil principle as the one which is at work when the sugar or the tobacco industry do their slightly questionable stuff.
Want inline pictures? Well, Textual has had that for a long time, irccloud's webUI too.
The amounts of memory that users are reporting for Slack are all several times higher than the entire RAM of the first computer I started using my MSNP client on.
I had to walk 10 miles to school in the snow! Barefoot! Uphill! Both ways!
or
GET OFF MY LAWN!