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.
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.
There are developers who care about product and not about tech. They build things that just barely work.
There are developers who care about both. They build the stuff people remember.
> What truly makes a difference for users is your attention to the product and their needs.
> Learn to distinguish between tech choices that are interesting to you and those that are genuinely valuable for your product and your users.
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.
Pointer-oriented languages as a rule give a 2x memory-size multiplier to everything, though higher is possible depending on how dynamic they are.
I suspect that the DOM and JS runtimes add a significant multiplier to the UI memory cost.
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:
Commit: 288.13M (1%); Free Memory: 15.43G (96%)
Free RAM is just RAM that’s doing nothing useful. Better to fill it with cached application states until you run out.
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.
> 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.
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.
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
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.
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.
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.
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.
(Yes, for real. I've once witnessed this being said out loud and used to justify specific tech stack choice.)