I have never seen it used like that. I have always seen it used like parent said: to justify awful technical choices which hurt the user.
I have written performant high quality products in weird tech stacks where performance can be s bit tricky to get: Ruby, PL/PgSQL, Perl, etc. But it was done by a team who cared a lot about technology and their tech stack. Otherwise it would not have been possible to do.
This is a genuinely fascinating difference in perception to me. I don't remember ever hearing it used in the way you have. I've always heard it used to point out that devs often give more focus on what tools they use than they do on what actually matters to their customers.
I have often heard it used to create a (false) impression that the choice of tools does not affect things that matter to customers - effectively silencing valid concerns about the consequences of a particular technical choice. It is often framed in the way you suggest, but the actual context and the intended effect of the phrase are very different from that framing.
Would like to echo this. I've seen this used to justify extracting more value from the user rather than spending time doing things that you can't ship next week with a marketing announcement.
I've also seen it used when discussing solutions that aren't stack pure (for instance, whether to stick with the ORM or write a more performant pure SQL version that uses database-engine specific features)
Then you need to read more, because that's what it means. The tech stack doesn't matter. Only the quality of the product. That quality is defined by the user. Not you. Not your opinion. Not your belief. But the user of the product.
> which hurt the user.
This will self correct.
Horrible tech choices have lead to world class products that people love and cherish. The perfect tech choices have lead to things people laugh at and serve as a reminder that the tech stack doesn't matter, and in fact, may be a red flag.
"It's a basic tool that sits hidden in my tray 99.9% of the time and it should not use 500MB of memory when it's not doing anything" is part of product quality.
Using 500MB of memory while not doing anything isn’t really a problem. If RAM is scarce then it will get paged out and used by another app that is doing something.
And now more seriously ;) Swapping aint fun. Sure, if it needs to happen, its better that out of memory error or crash, but still. Its not excuse to baloon everything..
And here, is my memory stats, while writing reply:
Swapping is perfectly fine for the case where an app that has remained unused for a significant period of time starts being used again. It may even be faster than having the app manually release all of the memory it’s allocated and then manually reallocating it all again on user input (which is presumably what the alternative would be, if the complaint is only about the app’s memory usage when in an inactive state).
Free RAM is just RAM that’s doing nothing useful. Better to fill it with cached application states until you run out.
An application that genuinely uses less RAM at any point of its execution, whether that's measured by maximum RSS, average RSS, whatever, is still better. Then you can have more apps running at the same level of swapping. It's true that if you have a lot of free RAM, there's no need to split hairs. But what about when you don't have a lot? I was under the impression that computers should handle a billion Chrome tabs easily. Or like, y'know, workloads that people actually use that aren't always outlandish stress tests.
Sure, the ideal app uses no resources. But it really doesn’t matter how much allocated memory an app retains when in an unused state (if you’re running it on a modern multitasking OS). If there’s any memory pressure then those pages will get swapped out or compressed, and you won’t really notice because you’re not using the app.
It seems like you're saying that if the user acts in certain patterns, the OS will just take care of it. Isn't the point of computers and technology to make it so that users are less restricted and more empowered? If many people do actually notice performance issues particularly around usage of certain apps, then your recommended patterns are too narrow for practicality. You are talking about scenarios where there is no real pressure, the happy path, but that's not realistic.
I’m just saying that it would not make much difference if Electron reduced its idle memory usage. If you use an app infrequently, then it will get paged out and the memory it retains in its idle state will be available for other processes. If you use the app frequently then you care about active memory usage more than idle memory usage. Either way, there is not much to be gained by reducing idle memory usage. Any attempt to reduce it might just increase the wake up time of the app, which might then have to rebuild various data structures that could otherwise have been efficiently compressed or cached to disk by the OS.
You're still going off of a "happy path" mentality. The user decides when an app should be idle or active, not the OS. The OS therefore pages in and out with no grand scheme and may be out of sync with the user's next action. What of the time taken to page in an idle app's working set? Or, as I addressed from the start, what if the user wants many applications open and there is not much free memory? That means swapping becomes a necessity and not a luxury, performance drops, and user experience declines. I think there is plenty of, perhaps low-hanging is uncharitable, but not unreasonably high fruit to pick so that users can be more comfortable with whatever workload they desire. I don't think we're remotely pushing the limits of the technology here.
You seem to be thinking about memory usage in general and not specifically about memory usage in an idle state, which is what I’ve been talking about in this thread.
Otherwise, what exactly is the alternative you have in mind? Should Electron release allocations manually after a certain period of inactivity and then rebuild the relevant data structures when woken up again? For the reasons I gave above, I suspect that the result of that would be a reduction in overall performance, even if notional memory usage were reduced.
If you just say “Electron should use less RAM overall!” then you are not talking about the specific issue of memory usage in an idle state; you are talking about memory usage in general.
I am engaging with the arguments you are making; I don't think you are engaging with mine. Reread my previous comment. Application designers do not get the luxury of somehow having high memory usage in an idle state but being able to cut down memory usage in an active state. Your idea of the idle state seems to be that the entire system is idle. You are not considering what happens where there is load. The app designer does not decide when the application has the leeway to have high idle memory usage ("oh, Electron idle memory usage of 500MB is fine because swap so it's basically free").
> Free RAM is just RAM that’s doing nothing useful. Better to fill it with cached application states until you run out.
So you recognize that you are only cruising when there is plenty of free RAM. You're setting aside this magical scenario of the idle state, but really you are just being optimistic that users won't suddenly act and overload the system. You are excusing significant waste by saying it won't matter most of the time. Perhaps that's true with certain definitions (i.e. many people on most days don't make their computer thrash), but in practice people notice when they have a problem, and I want to minimize such problems. I am not saying we can do any of this perfectly, but I think there is legitimate room for improvement that you are ignoring. I think it's reasonable to say that, with modest engineering effort, we could make every (say) 800MB Electron app into a 600MB Electron app. If you were running three at once before, now you can run four with a comparable level of performance. I think that's a genuine improvement that isn't some gotcha to you or an unrealistic fantasy.
>Application designers do not get the luxury of somehow having high memory usage in an idle state but being able to cut down memory usage in an active state.
That may be so. However, in that case, it does not make sense to complain about an application using x amount of RAM while not in use, which is the complaint that I was responding to ("it should not use 500MB of memory when it's [sitting in my tray] and not doing anything"). It might make sense to complain about Electron's overall RAM usage. As far as I can tell, that's what you're doing. I don't really have an opinion on that as I'm not familiar with Electron's internals. So on that point there's really nothing for us to argue about.
>Your idea of the idle state seems to be that the entire system is idle.
I'm talking about the state where the application is not being used, not where the entire system is idle. In that state it is easy for the OS to reclaim any RAM the app is using for use by other apps.
Businesses need to learn that, like it or not, code quality and architecture quality is a part of product quality
You can have a super great product that makes a ton of money right now that has such poor build quality that you become too calcified to improve in a reasonable amount of time
This is why startups can outcompete incumbents sometimes
Suddenly there's a market shift and a startup can actually build your entire product and the new competitive edge in less time than it takes you to add just the new competitive edge, because your code and architecture has atrophied to the point it takes longer to update it than it would to rebuild from scratch
Maybe this isn't as common as I think, I don't know. But I am pretty sure it does happen
>You can have a super great product that makes a ton of money right now that has such poor build quality that you become too calcified to improve in a reasonable amount of time
While it's true that that can be partially due to tech debt, there are generally other factors as well. The more years you've had to accrue customers in various domains, the more years of decisions you have to maintain backwards compatibility with, the more regulatory regimes you conduct business under and build process around, the slower you're going to move compared to someone trying to move fast and break things.
> No, it means that product quality is all that matters
But it says that in such a roundabout way that non technical people use it as an argument for MBAs to dictate technical decisions in the name of moving fast and breaking things.
I don't know what technology was used to build the audio mixer that I got from Temu. I do know that it's a massive pile of garbage because I can hear it when I plug it in. The tech stack IS the product quality.
I feel like that's what it should mean, that quality is all that matters. But it's often used to excuse poor quality as well. Basically if you skinner box your app hard enough, you can get away with lower quality.
I don't think that's broadly true. The unfortunate truth about our profession is that there is no floor to how bad code can be while yet generating billions of dollars.
If it's making billions of dollars, somebody somewhere is getting a lot of what they want out of it. But it's possible that those people are actually the purchasing managers or advertisers rather than the users of the software. "Customers" probably would've been the more correct term. Or sometimes "shareholders".
As far as I can tell the article has been misinterpreted causing much lost hours by HN commenters. By saying users don't care about your tech stack, it is saying you should care about your tech stack, i.e it matters, presenting some bullet points on what to keep in mind when caring about your tech stack. Or to summarize, be methodological, not hype-following.
Agree the article is not clearly presented but it's crazy to see the gigantic threads here that seem to be based on a misunderstanding.
Well, the alternative and more charitable interpretation would be that you are more likely to build a better product in the stack you know well and enjoy.
I think when you get more concrete about what the statement is talking about, it becomes very hard to assert that they mean something else.
Like if you are skilled with, say, Ruby on Rails, you probably should just use that for your v1.0. The hypothetical better stack is often just a myth we tell ourselves as software engineers because we like to think that tech is everything when it's the product + launching that's everything.
No, it means that product quality is all that matters. The users don't care how you make it work, only that it works how they want it to.