VS Code might be using close to 1GB with nothing loaded, but it doesn't go much higher with stuff loaded, at least not that I've noticed. I do have 16GB because that's what you get in a laptop these days, and I'm always running at least three Electron apps concurrently, a browser with about 200 open tabs, and then another one or two browser with a few tabs each (plus an email client, and of course, agents and compilers running in the background). The only time I notice an issue is when a program leaks memory.
But again, I try not to look at numbers unless I know exactly what their effect is, and I rarely if ever notice any ill effects caused by well-behaving Electron apps, and unless I notice an actual problem I try not to look at numbers, because they can lead you down the wrong path and distract you from what actually matters. Overall RAM in particular, especially when combined with low-CPU (which makes swapping cheap), is a very misleading metric because it's not easily translatable to value without lots of other pertinent information (such as how many copies of the program the average user is expected to run concurrently, how many other programs the user is expected to run and what the CPU utilisation is).
In the nineties and early oughts, I, like many other developers, obviously focused a lot on reducing RAM because it mattered a lot under the conditions back then. Over the years, it started mattering less and less, to the point that you need a very clear justification to optimise it (in fact, you need a clear justification to optimise anything, or you'd end up wasting your time on optimising the wrong thing at the expense of the right thing). These days, I too often see developers trying to reduce RAM without being able to point at an actual (not hypothetical) user-experience problem they're solving.
No, that's not the conclusion. If using models costs you, say, $10 an hour, and a GB of RAM costs you, say, $0.0001 an hour, then clearly you shouldn't spend your time on reducing the insignificant cost if you want your work to deliver the most value to users.
But again, "less RAM" is more or less meaningful whether you're reducing the RAM usage from, say, 5% to 1% or from 80% to 40%. The latter is more valuable even though it's a lower relative reduction. That's because what the users care about is in what conditions they reach 100% of either CPU or RAM, and the second 2x reduction, therefore, offers more value than the first 5x one. This is similar to how a 10% discount on a car offers far more value than a 99% discount on a pack of chewing gum. This is still the case if you're buying 100 packs, but maybe not 10,000, and the same goes for software: it may also matter how many copies of the app the user is expected to run concurrently. The point is that you can't assign a value to a 10x reduction if that's all you know.
> I'm entertaining this nonsense because I want to clarify, that I use a 20 year old web gui and it consistently eats 8 gigs of ram in Webkit because it uses CSS to update the forms.
And I'm entertaining this nonsense because you're clearly not a very experienced engineer and you may learn something. In the ninetees, when nearly all GUI apps were written in C or C++, we had plenty of examples where a C++ GUI app consumed 50% RAM. That doesn't mean that C++ is worthless, only that some software has serious resource bugs, and it sounds like that web page you're referring to is a case of that. Most web-based GUI apps today do not consume a higher portion of RAM than their C++ counterparts did 30 years ago. Today's browser-based MS Word consumes less (relative) RAM than the C++ version did in 1998, and it certainly has a far smaller negative impact on concurrently using other apps on the machine.
And, of course, there are buggy/leaky programs now just as there were then. It's silly to say that the existence of such programs means that the approach is bad, because that would apply to any sufficiently-popular language or toolkit.
Anyway, our job is to offer the most value to our users, and reducing RAM consumption by 3% or even 5% (of available RAM) is usually not where you'd find much value.