> Terminals aren’t using more resources, they are just going slow
"Going slow* is using resources. Clock cycles are a resource.
> No doubt theres bloat around, but I think you don’t understand web browser allocation strategies.
Using a web rendering engine to render a text editor is still bloated and inefficient. It doesn't matter if web browsers are intrinsically expensive - building a text editor using webtech is the incorrect design decision.
> You also lack justification for calling memory use idiocy if you aren’t running out of memory.
It should be obvious that the people here aren't complaining about applications that take a trivial amount of memory. In 2021, nobody cares about a text editor that consumes 8 MB of memory. People are complaining about applications that do take up a significant amount of memory and cause you to run out.
Mozilla's Firefox hardware report[1] says that just under 25% of Firefox users have only 4 GB of installed RAM. If running on Windows, probably half of that is consumed by the operating system. Suddenly, a 400 MB Electron app is consuming a full fifth of your available memory. That's a real problem, especially for folks that either (1) don't have much money and can't afford a newer machine or (2) want to try to conserve the environment by not spuriously buying new hardware when the old stuff should work.
> As long as there is free memory in the system, it’s fair game, and does not represent inefficiency.
Maybe by your definition of "inefficiency". Most of the people in this thread are (apparently) using it to mean "using significantly more resources to provide functionality than are intrinsically necessary". This is a much more reasonable definition given that you don't actually know how many resources the user has.
> "Going slow* is using resources. Clock cycles are a resource.
This is not true for terminals, nor in general. You can, and terminals do, go slow without consuming more clock cycles. Latency in terminal rendering, not throughput, is the main reason for them feeling slow. In other words, delays in the system are the bottleneck, not compute.
> People are complaining about applications that do take up a significant amount of memory and cause you to run out.
People are complaining about memory usage without understanding why it's used or what it's being used for. Nobody yet has complained about running out of memory, I haven't seen any relevant discussion about virtual memory, memory compression, nor about what browsers actually do when they run low on memory. Turns out, surprise!, browsers can fit many more tabs than you think if you had blindly assumed that the amount of memory your process manager reports will scale linearly until you run out... that's not how it works.
The point is, web is everywhere and nobody has to explicitly install anything to use a website - especially important for the less techy people that have no clue about "6 MMU wait states". So the browser is absolutely the right platform to build a (rich) text editor e.g. as a component of a web app. Is it an easy task? No, not really. We still have a half dead IE, Safari and the other browsers are far from perfect. Is that efficient? No. There is a ton of cruft and perhaps the best thing is to draw into a canvas and just not use most of it all (for better performance in the end). So you are basically pushing pixels from JavaScript (ok, or WebAssembly) in the end, if you want the best performance. Then you reimplement all the work that was already done at least 3 times before by OS, Browser and some library/ toolkit/ framework authors. You have to reimplement e.g translation using your own dictionaries, because you cannot easily work with the translator of the browser or the operating system (that's why browsers bring their own). You write a least a slightly different CSS for every browser family. You handle stuff like Content Security Policy differently. This is like every second thing, that you have to reimplement or make platform specific adjustments to make it work somewhat well. That's totally insane. In all this, absolute performance is just really hard to achieve. Do you expect people to ship apps for like 5 different platforms using perhaps 4 considerably different tech stacks or using 1 but then still adjusting for each platform again/ hacking it to look native and not get banned by an app store?
The problem is, people don't take responsibility for their work and almost nobody simplifies stuff. Stuff just somehow works but most of it just isn't solid or it isn't compatible or it is extremely (over)complicated. The next guy using it as a dependency has all these problems on top of the problems of his or her own with the problem at hand. This tree is multiple levels deep. Your pyramid is built on stuff that hundreds of smart engineers basically overlooked/ ignored for decades. Meltdown and friends is just one example, there are HW bugs, there are management engines, there is the OS, the libraries, other software/ daemons/ services, bad APIs, old APIs, deprecated APIs, functionality split between old and new API, bug ridden runtime, inconsistent behaviours of a markup language processing and styling implementation etc. pp.
We all need to get our act together and the harsh reality is, most of us just don't know everything and there isn't time to know everything. We need basic stuff to really just work and be as simple as possible given the problem domain, else we will not progress without gigantic investments.
"Going slow* is using resources. Clock cycles are a resource.
> No doubt theres bloat around, but I think you don’t understand web browser allocation strategies.
Using a web rendering engine to render a text editor is still bloated and inefficient. It doesn't matter if web browsers are intrinsically expensive - building a text editor using webtech is the incorrect design decision.
> You also lack justification for calling memory use idiocy if you aren’t running out of memory.
It should be obvious that the people here aren't complaining about applications that take a trivial amount of memory. In 2021, nobody cares about a text editor that consumes 8 MB of memory. People are complaining about applications that do take up a significant amount of memory and cause you to run out.
Mozilla's Firefox hardware report[1] says that just under 25% of Firefox users have only 4 GB of installed RAM. If running on Windows, probably half of that is consumed by the operating system. Suddenly, a 400 MB Electron app is consuming a full fifth of your available memory. That's a real problem, especially for folks that either (1) don't have much money and can't afford a newer machine or (2) want to try to conserve the environment by not spuriously buying new hardware when the old stuff should work.
> As long as there is free memory in the system, it’s fair game, and does not represent inefficiency.
Maybe by your definition of "inefficiency". Most of the people in this thread are (apparently) using it to mean "using significantly more resources to provide functionality than are intrinsically necessary". This is a much more reasonable definition given that you don't actually know how many resources the user has.
[1] https://data.firefox.com/dashboard/hardware