7 ms·
My compute resources are not an all-you-can-eat buffet. I'm sick of inconsiderate developers writing software in wasteful frameworks that waste my electricity a
by tomc1985 9y ago
My compute resources are not an all-you-can-eat buffet. I'm sick of inconsiderate developers writing software in wasteful frameworks that waste my electricity and time.
You can make pretty x-platform apps in JavaFX, QT Quick, GTK, hell even Lazarus, and they don't eat CPU and memory like Electron does.
It is a shame that nearly every app released in the latter half of this decade is just wasteful Electron garbage. Don't forget your 300+mb needs to sit along side Slack's 300mb, Discord's 300mb, and so on... fuck even my Crashplan Backup client eats up three processes and another 300mb. It's inconsiderate as hell.
- SnowingXIV 9y agoWhile I somewhat agree, no one is forcing you to use this software and this holier than thou attitude is not constructive. You're free to use gnus, notmuch, mu4e, whatever million other variants if you're so concerned about your "precious" resources. This electron app that's been built has some neat features that a lot of people might find useful, like that search seems pretty cool.
- eridius 9y ago300mb? You're lucky. Slack is taking up 763mb for me right now, and it's not uncommon to see it cross the 1GB threshold.
- markbnj 9y agoPretty harsh lol. If you don't like electron apps then don't run them. It's hard to describe the actions of developers who use those frameworks as "inconsiderate" when they are a) providing the fruit of their labors for free; and b) not shoving it down your throat.
- tomc1985 9y agoElectron is becoming more difficult to avoid
- majewsky 9y agoExactly. Can't wait for my boss's reaction when I tell him I'm leaving Slack Enterprise.
- reaperducer 9y ago> If you don't like electron apps then don't run them. Done.
- cbhl 9y agoI really don't think the problem is Electron, or even JavaScript. I think the problem is Chrome, which the Electron runtime requires. Each separate Electron app has its own copy of Chromium in memory. (What happened to shared libs?) I see two ways you can help: (1) you can try to get memory-usage-reducing fixes into Chromium, or, (2) you can build an Electron-compatible runtime that uses less memory (maybe by transpiling it into code that runs on a native toolkit, and not having a static copy of that runtime per-app).
- tomc1985 9y agoSomeone posted a link to a new framework called Proton Native... that's a great step in the right direction
- misterbwong 9y agoI'm not grandparent but I tend to agree that it's NoBigDeal(TM). I'm no electron apologist but I don't understand why using electron is considered "inconsiderate". It seems like the developer(s) used the platform that they felt was best for this app. If the platform's issues overshadow the product's value, then that's a poor choice and the market will react by not using it. Is it inconsiderate for Ford to make a larger SUV because your garage doesn't have unlimited square footage and you only want to buy so much gas? Of course not. Why is this any different? You can decide not to buy the SUV just like you can decide not to download this application.
- tomc1985 9y agoThe way I see it, user's resources (and their experience related to these factors) aren't part of the calculus that goes into how most companies choose their platforms. To be fair, things have always been this way -- people have been writing good-but-bloated software in shitty frameworks since forever -- but I can't recall a time that one framework so bloated is so heavily in vogue. (edit: Flash, maybe? Though people mostly didn't try to write too many full apps in it. And Flash projects could be fairly CPU-efficient if effort was put into it, but way less effort than, say, MS with VS Code)
- reaperducer 9y agoI'm fortunate enough to work for a company that sees being thrifty with bandwidth and processing as very important. We have regular audits to find ways to make things lighter/faster, and therefore better. Occasionally "flashier" mandates from on high override those considerations, but so far it's been specific and rare. It's probably because our target audience isn't developers.
- tomc1985 9y agoFunny, following that logic one would think that developers would be the most picky about performance...
- 9y ago
- dokem 9y agoI think you are taking developers' choice in framework a bit too personally.
- tomc1985 9y agoAnd I think most users are far too tolerant of bad decisionmaking
- dumbfounder 9y agoThey aren't tolerant at all to decisions they think are bad, they are just tolerant to ones that you think are bad.
- Avamander 9y agoSo you're calling me not a potential user because I don't like the idea of something using 15% of my PCs memory, best case scenario.
- LyndsySimon 9y agoRespectfully, losing a single potential user is not indicative of "bad decisionmaking". It may very well have been an excellent decision, particularly if using Electron allowed them to support macOS and Windows out the door - thereby expanding their target audience significantly. I get why you don't like Electron apps. I share your position in that. I would expect that if Ivelope grows quickly enough to justify it, time will be spent on improving resource utilization. That could be through scrapping Electron or through optimizing within it - but either way, at this stage "time to market" and "speed of iteration" are much more important than resource utilization.
- saagarjha 9y ago> Respectfully, losing a single potential user is not indicative of "bad decisionmaking" It's not just one user that they've lost…
- mful 9y agoGod forbid someone spend thousands of hours building a free app in the tech stack they are familiar/productive with...how inconsiderate!
- saagarjha 9y agoIf their tech stack isn't appropriate for the job, then they shouldn't be using it for. We don't have people writing software for space probes in Python.
- sciurus 9y agoBut we do have people writing some of the most used email clients in the world using HTML and Javascript, so that's hardly a valid criticism in this case. https://emailclientmarketshare.com/ https://emailclientmarketshare.com/
- saagarjha 9y agoApple iPhone, Apple iPad, Outlook, Samsung Mail, and Google Android, together making up well over 70% of that list, are all native clients. Plus, the clients that aren't native are all web-browser based.
- sciurus 9y agoSo 30% of marketshare belongs to clients built on the browser technologies of HTML and Javascript, the same technologies you claim are "inappropriate" for the new client that we're discussing.
- haylem 9y agoYes, but: - we're not talking about space probes, - this is just one dev who thought "I want to write an email client" and make a tech choice based on his/her own proficiency with that stack and his/her project constraints (time, cost, quality, scope). It seems unfair to rant so much about it. If it's feature full and good and perf becomes an issue, consider it an MVP and a stack change is doable. If the thing blows, trash the MVP. Personally I'm far more worried about the first noted limitation about email forwarding with attachments not being available. I'd have wanted that before most of the showcased features, none of which I find particularly interesting. But I applaud the effort and the Polish, and the approach to build the tool that you want/need when. You can't find one. (Second worry would be: if it's not open source, please make so.)
- nobodyaccount 9y agoGet over yourself. I run multiple electron apps all day long without issue. > You can make pretty x-platform apps in JavaFX, QT Quick, GTK, hell even Lazarus, and they don't eat CPU and memory like Electron does. lol, if those are your idea of pretty... The reason Electron is popular is because those frameworks are, and have always been, garbage for garbage software.
- laumars 9y agoI would normally agree with you but I can actually see the point of Electron for email because you'd need a HTML renderer anyway to display emails (assuming you want the ability to view HTML emails, if not then you're better off with a console client and save yourself even more RAM :p) Plus Gmail and a few others big names in webmail require a HTTP client for authentication if you want to use their proprietary sync (granted there's also POP3 and IMAP. But while IMAP is good in a number of ways it's still far from perfect).
- luuio 9y agoWhat does rendering HTML or needing a HTTP client have to do with Electron? As far as I know, every single usable language comes with a HTTP client, and every single GUI framework has a "WebView" control or equivalent.
- laumars 9y agoWebView's are typically just WebKit / Blink / Trident / whatever embedded anyway. So if you're going to embed Blink then you've already lost any significant memory savings you'd hope to make by avoiding Electron in the first place. Thus you might as well write the whole thing in Blink / Electron from the outset as that will also give you massive developer productivity gains (which it will - such is the sad state of desktop application development these days). As for the HTTP client point; you can use a simple HTTP API (libcurl or whatever) to perform the webmail authentication but honestly you're in for a whole world of pain because it's really more than just a HTTP call. Ideally you'd want another webview for that as well. Oh how all those individual webviews are going to add significantly to your memory usage. You might as well consolidate them all into one...let's call that new WebView "Electron" shall we ;)
- rootlocus 9y agoThe way I see it, without the comfort of using Electron, many apps would simply not exist, because nobody would invest the considerably larger) time and effort. So it's not electron vs native, it's electron vs nothing.
- rebeccaskinner 9y agoGiven the choice I'll take the "nothing" option. Electron is gaining momentum and things that would have been written in a reasonable native framework are going to get sucked into it's ecosystem and we're all going to be worse off.