Hacker News Reader

Comment by dhruvb14 | Hacker News Reader

I find it crazy that everyone is harping on Electron instead of the cool features that this clearly has that most clients do not. Demo looked pretty polished dude. Don't let the typical HN crowd rain on your parade. The fact that you posted an actual product out to the public is more than most can say.

Also: If you can't spare Max 300MB ram and you are complaining on HN wtf computer do you use?

View on HN

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.

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.

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.

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

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.

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

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

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

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

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.

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

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.

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…

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.

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.

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 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?

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.

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

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.

Half of Hackernews is discussion about six figure tech salaries, the other half is complaints about 300mb (aka ~$2) ram being to expensive for an app.

https://www.anandtech.com/show/9864/price-of-ddr4-memory-dro...

and what about people who use electron apps that aren't silicon valley programmers?

They can't properly voice their complaints because they don't know why their software is terrible; just that it is terrible.

Yup, but we're all running these apps on laptops, which have a fixed amount of RAM that is sometimes impossible to increase (looking at you, Apple)

To be fair, RAM is much more expensive to upgrade on MacBooks and other premium laptops.

There are, in fact, people who are not SV software developers.

What if all your RAM slots are taken, or your laptop cannot upgrade RAM at all?

This is from 2015. RAM prices remain artificially high.

> Half of Hackernews is discussion about six figure tech salaries, the other half is complaints about 300mb (aka ~$2) ram being to expensive for an app.

Slashdot got like this eventually. Slashdot was tech site full of luddites complaining about anything new. Worse, slashdot stopped becoming relevant. When the top comment on an article about increased hard drive space was "why does all this stuff take so much space? bloat!! lazy developers!!!".... it's pretty lame.

300mb of ram is nothing. Your OS will swap the software out when you aren't using it and it will be no big deal. People need to stop micromanaging their computer and go do more productive things with their time....

> Your OS will swap the software out when you aren't using it

Wrong, since Electron apps NEVER sit still.

> People need to stop micromanaging their computer

You're so wrong. This hogging literally causes micromanagement. I have to start closing browser tabs and maybe at some point my IDE or a few open files so that just Slack or Discord or some other piece of horrendously bloated software could hog up another half a gigabyte of RAM. When Eight gigabytes stop being enough because of some chat applications it's not okay. Calling people that think software can actually use resources meaningfully "luddites" is counterproductive and damaging to the entire PC ecosystem, RAM and disk space are limited resources on most PCs and people do not want and should not have to spend more just to run a few chat applications.

I see where you are coming from. My main work laptop has 24GB (recently refreshed; the previous one had 16GB), so I can trivially spare 300MB, if I want. That said ... I work on open source Linux virtualization (KVM-based), and I fiercely guard my laptop's memory. Why? Allow me to tell my "corner case" scenario.

I have a couple of development virtual machines (VMs), and build containers running on my laptop. They help me with a range of tasks (some are memory intensive). Further, I configure nested virtualization, which lets me setup two level-1 guests (A and B), and inturn run a level-2 guest (C) in either of them. Now I can test live migration of VM C between A and B. So I really try my best to stay away from memory-hogging applications.

That's one of the reasons why 4-ish years ago I ditched Thunderbird, which was hogging memory, and switched to the venerable mutt e-mail client. (Also ditched HexChat for irssi.) FWIW, switching to mutt was one of the best decisions I made for my productivity -- I spend a lot of time wrangling high-volume technical mailing lists; it's unalloyed joy to use mutt on a daily basis (especially if you deal with e-mail based patch workflow).

Granted, it might be a niche scenario. I just wanted to call out that there are damn good reasons to conserve memory.

Have you considered getting a dedicated server for this !?

MS Outlook, the heavyweight in the ring with every conceivable feature, has been running on my machine for days and is currently using 168MB.

every conceivable feature, a UI that leaves me with no idea how to use any of them.

I have no problems with the UI. Then again, I've been using versions for a decade.

It's not about WTF computer do you use, it's about being wasteful. I've been using Outlook and Skype for Business on my machine all day and they're using less than 160MB together.

Wastefulness is not cool.

What kind of computer an I using? I'm using a work computer that needs RAM for the actual work I do. If one auxiliary program used 300MB that would not be a big deal. But we're talking about electron MVP after electron MVP after electron MVP endlessly. Memory hogging electron MVP's are being released at 100x the speed of my computer's RAM growth. I bought a high RAM computer because I already need it for work, not because I want to fill it with Electron MVPs.

Thanks for your feedback!

For this, for Slack, for VS Code, for half a dozen other Electron apps because devs simply are not willing to take the time and effort to learn other languages.

Reply on news.ycombinator.com