Hacker News Reader

Comment by tomc1985 | Hacker News Reader

tomc1985

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.

View on HN

I 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).

What 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.

WebView'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 ;)

I'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.

> I don't understand why using electron is considered "inconsiderate".

Because I chose my OS carefully and found that I like the way its native controls work. It has a number of features missing from other OSes and I want to use apps that integrate naturally with it. I have yet to find an electron app (or web app) that is 1/10th as good as a native app at fulfilling that desire. Electron apps feel like generic imitations of native apps. Yeah, they work, but everything is just off. Also, it comes from Google so I can only assume it's doing some sort of tracking of me and/or my machine resources. No thank you.

> Is it inconsiderate for Ford to make a larger SUV

It depends on which dimension they extend it and by how much. If they make it wider to where it doesn't fit in a lane on a normal road, then hell yes it's inconsiderate. That's essentially what electron does.

I'm an developer who's been using electron since it came out. At it's core electron is just a packaged NodeJS instance with a layer to access the OS API. The chrome as a GUI part does not have to be used. This makes electron a great way to distribute NodeJS apps. Instead of getting your users to install NodeJS and use the command line, you can give them an electron version of the app that works out of the box.

If you stick to using the GUI part minimally, it's easy to build very light weight applications with electron. I've been building my own music streaming server with electron and its gotten some traction since it's easier to install. The GUI layer is only used for editing config options, so the app typically runs with under 50mb of memory consumption: https://github.com/IrosTheBeggar/mStream/releases

If used smartly, electron is a powerful tool for developing desktop apps quickly. However thanks to modern frontend dev practices, it's easy to build a bloated pile of crap.

In the US, a Ford XL SUV will get killed by the DOT if it does fit in standard lane sizes, among other considerations. I am sure this is why there comparatively few brands of automobiles here

There is no such governing body for Electron, save for the nebulous "market"; nobody with any authority is forcing them (GitHub et al) to fix their shit or GTFO

> Also, it comes from Google so I can only assume it's doing some sort of tracking of me and/or my machine resources. No thank you.

Electron was developed by GitHub for their Atom editor, actually.

The 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)

I'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.

Funny, following that logic one would think that developers would be the most picky about performance...

Old developers. Seasoned developers. Developers who know what they're doing.

But the devs coming out of schools today (and half of HN) believe it's OK to build a skyscraper by stacking frameworks one upon the other.

I agree with you that efficient resource usage is pretty low on the priority list for a lot of development these days. I wish it wasn't too but that's a different discussion.

Electron being in vogue does definitely compound this issue but the benefits from using it (e.g. cross OS development on a familiar platform & language many devs already know) seem to outweigh the resource problem.

That's because the devs are not the ones to face the resource problem.

There are many devs that know regular desktop development as well; Electron lets the project manager hire cheaper and more expendable web devs, or the ability to pile the job on their existing web devs, for their otherwise expensive desktop work.

Do any major code bootcamps teach C#, C++, or Java? Or is it all just webtech?

I wrote a tiny app in flash / AS3 back in the day, a CAD floorplan viewer in a few hundred KB, including baked-in artwork and font. CPU and memory use was quite low. I never considered flash to be bloated or slow. The way most people used it made it bloated and slow, with heavy software-based vector animation, tons of video, and flex. Flex was very developer-friendly but also quite bloated, so I never used it.

I wonder if electron is a bit of the same deal, with the recommended way of using it optimizing for developer efficiency over resource efficiency.

I don't feel the developer used what they felt was best for this app. I feel they used what was best for them.

Assuming the best platform for an app was even something that you could objectively determine, why would you expect a solo developer to write an app in a platform that isn't the best for them?

To write something that's best for the customer, of course. The goal of development shouldn't be to build something that's easy for the developer but suboptimal for the customer.

This isn't open source, and the implication is that they plan on selling it. If so, then what's best for the customer should be paramount.

300mb? You're lucky. Slack is taking up 763mb for me right now, and it's not uncommon to see it cross the 1GB threshold.

God forbid someone spend thousands of hours building a free app in the tech stack they are familiar/productive with...how inconsiderate!

If 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.

Yes, 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.)

> if it's not open source, please make so

But 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/

Apple 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.

So 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.

But if NASA let startup hackers write their code, we would be!

As if all work, and all effort, performed anywhere, is inherently noble and good?

Do you praise the builder of that Brazilian skyscraper that caught fire and collapse for the thousands of hours that went into its construction?

I 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).

Someone posted a link to a new framework called Proton Native... that's a great step in the right direction

Pretty 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.

Electron is becoming more difficult to avoid

Exactly. Can't wait for my boss's reaction when I tell him I'm leaving Slack Enterprise.

> If you don't like electron apps then don't run them.

Done.

The 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.

Given 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.

While 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.

I think you are taking developers' choice in framework a bit too personally.

And I think most users are far too tolerant of bad decisionmaking

Respectfully, 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.

> Respectfully, losing a single potential user is not indicative of "bad decisionmaking"

It's not just one user that they've lost…

They aren't tolerant at all to decisions they think are bad, they are just tolerant to ones that you think are bad.

So 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.

Get 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.

Reply on news.ycombinator.com