Hacker News new | past | comments | ask | show | jobs | submit login
I've spent the last two years building a new email client (ivelope.com)
874 points by muszc-master 11 months ago | hide | past | web | favorite | 593 comments

I put my name on the waitlist, but instantly lost interest and confidence by: “Jump forward 5 steps in the line for every person you invite and get beta access sooner.”

Why? If the product is that good I’ll evangelize it. This is a desktop application, so I don’t see a big boost from a network effect. All this does makes me wonder if the product is more about building hype than value

You are not alone in this attitude, so don't take this personally, but I'm going to reply to you because you're the top comment. This is an incredibly destructive point of view. Promotion is essential to any software project, even open source, and in the vast majority of cases, word of mouth is not enough. This is an ethical, up-front, straightforward ask that costs you and anyone you might contact very little and is optional in any case. He's a solo developer. Cut him some slack.

But what am I endorsing? I haven't tried the product myself yet. It's not unethical, but it's also simply not something I'm prepared to do - I will not recommend something to anyone without having been able to evaluate it myself first.


In a world where publishing is essentially free, reputation is an extremely valuable commodity. The ask here is not trivial.

  reputation is an extremely valuable commodity
But how does pre-use endorsement have any actual value toward a positive reputation? Did the definition of "reputation" change when I wasn't watching?

Whenever anyone makes a recommendation you have to ask yourself: is this person making this recommendation because they have actually investigated the thing they are recommending and found it to have merit, or are they doing it simply because they are getting some personal benefit from making the recommendation. I hope I don't have to explain why a recommendation has much more value in the former case than the latter.

This may not matter much if the thing you're recommending is an email client. But it matters a lot if the thing you're recommending is, say, an investment in a startup company. It also matters a lot if you're, say, Amazon or Yelp or TripAdvisor and a big part of your stock in trade is an enormous volume of product recommendations.

Yes, it is trivial. You have a warped perspective of importance if you think giving the nod to a new mail app is some holy thing.

I tell my friends about new apps, startups, and projects all the time. None of them think I'm staking my reputation when I shitpost about some new thing in Slack.

I don't think the parent is claiming its a holy thing. But I certainly feel the same way.

My reputation is worth more to me, than trying to get higher up in a queue to a product i haven't tried. I don't share things with people lightly, and there are clearly a bunch of us out there.

Any certainly, nobody is advocating that our view of the world is the correct one, just that we hold that view.

This is an awesome debate and one of the reasons I love HN

We are different. If I recommend a piece of software to someone these days, it means it's truly exceptional and they should really check it out.

Apart from that, the e-mail form doesn't let me control what I'm sending.

Recommending a product you haven't reviewed is a form of lying. Some of us value our integrity.

Isn’t this true of all advertising, except in the rare cases where the publisher only accepts ads for products they endorsed?

How can we ever expect a reliable, non-garbage-dominate internet when it is funded by perverse incentives?

The distinction is that if I see a billboard (or magazine ad, or TV commercial) advertising a product I don't think that I have a relationship with the billboard and they know me pretty well and have my best interests at heart... so I don't think that if this particular billboard that knows me so well is promoting a product to me then it must be a pretty good product for me (especially because this billboard doesn't usually go out of their way to recommend products to me).

But if a friend of mine recommends a product to me, well, I do think all of those things.

Literally, nobody said to do that. Good lord, are you aware of nuance? You can make people aware of something that looks promising, without lying.

> You have a warped perspective of importance if you think giving the nod to a new mail app is some holy thing.

You're taking a needlessly confrontational stance here with insulting language, and people are responding to that.

and yet to make this comment you do it from an account created just for this purpose... why? to protect your reputation?

It's almost as if context matters

But you're not giving the nod to it -- you don't even know yet if it's any good or not -- you're only telling them about it because you've got something to gain yourself from doing so.

This is the essence of the crap filled internet. Everyone makes these local trade offs and before you know it we all lose. We are prisoners of the dilemma.

Yeah! Now you've got it! You're just telling people about something. It's not a big deal.

Spam is also "just telling people about something".

Imagine what the world would be like if everyone had the same attitude towards other people's attention and time as you do.

I'm sure this behaviour doesn't seem like a big deal to you because relatively few people are so inconsiderate.

> Yes, it is trivial.

Then why are you posting anonymously?

Then don’t refer anyone.

Or maybe only send to your friends who a new email client would interest?

Is “hey, saw this on HN, this looks interesting” really going to hurt your reputation?

He’s a dev trying to market, that’s all.

I was going to say this.

It's totally optional to invite more people, so if it goes against your ethical views, just don't.

Yeah, but by engaging in this behavior, the dev has convinced me this whole thing is click spam, so I’m done evaluating it before I even downloaded it.

Sure, put my reputation behind something I have never tried. That makes sense.

It's actually dangerous and unethical TO put my name behind this untested product. It's not open source, and I'm being asked to put my seal of trust and approval on their project. That's a hard no.

So don’t? The dev isn’t forcing you to give five referrals to sign up.

"Incredibly destructive"

Incredibly hyperbolic

Extremely redundant and reductive

Spam your friends and sites to jump forward in the line!

I agree with the premise, but please, do it after I tried it, not before. Otherwise it might as well be a smart e-mail harvesting thing. How do you know these days?

Top secret product built in stealth mode rarely achieves success.

Where are the boring products without dumb marketing techniques to generate hype, with actual things to show other than a waiting list?

It's simply a blocker to adoption. What's dropoff rate from people who land on it to people who actually go through with this request?

Well, you don't have to invite anyone to join the waiting list, it is totally optional.

I dislike tricks like this too, especially because in the end you're still going to get access to it. If a product is good enough, as you said, then I'll tell everyone about it. I think technical or non-business people see this kind of trick and perhaps don't think of the deeper consequences of it - it's not quite a dark pattern, though it feels manipulative.

I'm sorry if it came across as manipulative. One of the reasons for having it like this is also so it can give me a metric on who in the waiting list are most interested in the program. And of course also to offer an incentive to share it.

That is not a good metric. There's no way I would take part in that even if I were interested. It's just a big turn off.

Your first sentence isn't supported by your second and third. It is incredibly common to track not just interest but level of interest -- and lots of companies find it a valuable metric for marshalling their resources. Is this perhaps not the best way to get that metric? Now that can be a helpful question to ask and a good thing for this dev to think about, rather than outright dismissing the attempt.

I'm more just saying that I don't think people doing/not doing that action is a good indication of their interest level. My interest level could be an 8 out of 10, but there's no way I'm pestering my friends about it.

A different option I'd suggest that will likely provide higher engagement/response rate is putting some kind of a 1-to-5 star or 1-to-10 ranking - something quick for the user to click (or ignore) - simply asking them "How interested or excited are you about this product?"

Re: Incentive to share it - Just build a good to amazing product - which the comments and upvotes you have on HN are already significant proof of - and you'll get higher adoption in the long run with exponential growth, without adding friction of little tricks like this which will be relatively inconsequential in the long run, other than perhaps causing friction with early adopters who will get turned off by them.

That's a good idea, and in hindsight, you and the other commenters disliking the wording are correct. I just haven't received this feedback on the wording before, will change it!

An interesting question might be, what other ways could you allow people in the queue to jump up in position, without requiring them to share with others?

Maybe a quick survey with questions like, - what email client do you use now? - what is your favorite/least favorite feature of said client? - how often do you check your email? etc

I'm extremely interested.. Me sharing it with other people is a poor way of measuring my enthusiasm.. I'm not going to share it until I've tried it, so that I can vouch for its quality.

Noted. It was a poor choice of words / trick on my part it seems.

Don’t call it a trick. It isn’t a trick. It is a marketing ploy.

Trick is a synonym for trick.

Ahhh. Trick is a synonym for ploy.

I'd advise you to reword it as "Want to join as a beta user? Share".

Frame it as a reward not a punishment.

What deeper consequences are those?

A portion of people find that kind of tactic/trick to be manipulative, cause discomfort, which will add friction to adoption - why do that to anyone who might become an early adopter when you can avoid it? In another reply I go in a little more detail - https://news.ycombinator.com/item?id=16978849

I think that that one email app that got acquired by dropbox before even launching did this and I think people are just copying it.

Yeah, Mailbox app used this prior to it's Dropbox acquisition. Mailbox is now a dead product. RIP.

Why would Dropbox (note: not remotely an email service) acquire Mailbox and then kill it?

They paid a pretty penny too, $100 million to acquire Mailbox. As per the article from Wired (https://www.wired.com/2015/12/dropbox-kills-carousel-and-mai...) they said:

Although Mailbox could presumably fit into that strategy, Dropbox is instead focusing on its new Google Docs-style document editing and collaboration service Paper, which may gain some of the functionality of Mailbox. "As we deepened our focus on collaboration, we realized there’s only so much an email app can do to fundamentally fix email," a blog post credited to "the Mailbox team" reads. "We’ve come to believe that the best way for us to improve people’s productivity going forward is to streamline the workflows that generate so much email in the first place."


This answer makes the most sense, but is still sad

They probably saw something in their software to strip for Dropbox.

> Jump forward 5 steps in the line for every person you invite and get beta access sooner.

So what you're saying is that Viktor Hn just shot to the front of the line? Well played, Viktor.

Edit: Actually, based on the invite code, it's likely a specific code for HN. The Developer's name appears to be Viktor Jansson, I just assumed Hn was a last name. :)

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?

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.

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.


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.


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.

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.


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)

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

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

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

Wrong, since Electron apps NEVER sit still.

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

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.

This is from 2015. RAM prices remain artificially high.

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

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

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.

I don't think this puts enough emphasis on the fact that it is a local client and not a web service. I see some people here griping about Electron, but the privacy implications of being a local app are way more important than the performance of the framework used.

Seems to be a proprietary application so app privacy went out the window already.

Privacy is a spectrum. You can choose to be at one end of it, but not everyone shares your opinion. As a local app your data has a different legal status, and you actually have a lot of control over the execution compared to a web service. For instance, with outgoing firewall rules you could ensure that this is only talking to your email server.

It's still better than it would be if it was a normal web app hosted on his server.

Or, at least, it has the potential to be better.

You can audit the code of every Electron app, so why are you acting like it's full of spyware that you'll never be able to have privacy with?

Ever heard of minimized JavaScript[0]?

[0]: https://github.com/google/closure-compiler

Minified js isn't particularly hard to reverse engineer compared to tools that are geared towards actual obfuscation, and regardless, you don't even need to look at the code if all you care about is privacy. A look at the dev console's network tab should tell you all you need to know.

I've done obfuscated Javascript on a CTF. Only a few hundred lines and I can tell you, it's way easier to just write it new from scratch, especially if you have a product that you like and can just copy.

I’ve reversed and broken real-life products written in JS, Java, WebAssembly and native code.

Minified JS and obfuscated Java (DexGuard or ProGuard) are almost identical in complexity, you can restore the actual datatypes still, and you can even restore the rough outlines of where control structures were.

Obfuscated WebAssembly, NaCl or native code is much worse to work with, and often data structures and control structures are gone entirely.

I'd be very interested about your findings decompiling wasm. Do you have a blog, by chance?

From parent's HN profile:

Janne Koschinski, CompSci student. https://github.com/justJanne

Current maintainer of QuasselDroid https://quasseldroid.info/ https://github.com/sandsmark/QuasselDroid

I don’t maintain a blog currently, sorry. And if I had one I doubt I’d be able to write interesting articles about this topic.

Generally I share such info on IRC, and then it gets just forgotten over time.

I agree with you. The discussion has somewhat de-railed off-topic into a discussion about Electron. While that is an interesting discussion, it is pretty off-topic.

Is it off topic though? This is HN after all.

My partner actually has the opposite pain-point:

She wants an e-mail client that stores attachments remotely, only downloading them as requested by by the client. Is there an e-mail service that does things this way?

Apple Mail has this as a setting, works with any IMAP provider.

This is what Ivelope is currently doing :) However there will be a setting for people who want to download all attachments as well.

Can't Thunderbird do that? I'd imagine most IMAP clients do this.

That’s a setting in outlook

Compared to web-based clients. But the best email client (MailMate) is already local.

Thanks for your interest in local email clients, more choice there is welcome!

In the description it is said one can file email with a key, by associating folders to keys. Keyboard operation is very important to me. However direct key/folder association doesn't scale to a large number of folders. Have you considered a feature like the "Nostalgy" extension for Thunderbird? [1]

With Nostalgy one type "s" to file/save an email, then a string which is matched to folder names. It's a bit like helm for emacs (except it's exact match, space is not interpreted as an "AND" like with helm). The commands are go/save/copy, and then string match. This scales very well. That could be an advanced feature, as for beginners the direct key/folder association is simpler. But I guess you will target advanced users too, and for them it may be an important feature.

[1] https://addons.mozilla.org/en-US/thunderbird/addon/nostalgy/

Claws mail had this by default. Thunderbird fortunately via the Nostalgy extension. It's been a lifesaver since claws mail never implemented HTML mail, forcing me to move to Thunderbird for 21st century text formatting ten years ago.

Sounds cool, will check it out!

This looks pretty cool, I'm really pleased to see people writing new email clients, and you've clearly worked very hard on this!

I have a bunch of questions that I couldn't find out from the website (but are obscure enough that I shouldn't expect to):

* Is this a purely native app, or an Electron / Javascript app? Personally I'm only interested in native apps & Electron would be a deal breaker - but I'm weird, most people won't care.

* What format are you using for email archives? Mbox, Maildir? Can I import my Thunderbird / Postbox Mbox archives of 21 years of email?

* Can I turn off threaded & conversation views?

* Do you support POP3? (You only mention IMAP... I'm sure that would be fine, but I still have accounts configured via POP3.)

* Can I change priority of individual messages after they arrive? I sort my inbox by priority and then date-descending, not by date.

I'm a hardcore Postbox user and email is critical infrastructure for me, so I probably won't try it or switch anytime soon... but I'm always keeping an eye on powerful desktop email clients, in case I ever need to switch, or find something dependable that really blows away Postbox.

Well done! Looks very promising!

1. It's an Electron app, but it is built to use as little RAM as possible, when I run it on my old Macbook Air, it consumes only around 300mb of RAM maximum, which is less than what Finder consumes, and I consider everything over this limit to be a bug.

2. Currently not supporting Mbox/Maildir but downloading emails directly from the server, however an import of this is on the todo list

3. Re: turn off conversation view: not at this time. Do you prefer not having it in a conversation view?

4. No POP3 yet

5. I think you can achieve this using folders/labels in Ivelope

Thanks for the positive encouragement!

Edit: formatting

300MB of ram sounds like a lot to me. What are you storing in memory that is that large? If I dont use the app for 1 hour will it stop using the memory?

I'm sure that a client like Mutt would use much less but considering that many emails have embed HTML and would ideally use a modern web view to render correctly, how much overhead is there from from using Electron/chromium if you're going to load all of that anyway?

I couldn't find exact figures for MS Outlook but Office 365 seems to require 1Gb as a minimum.

A quick look at the Gmail tab I have open in Chrome seems to be taking roughly 390Mb so this would seem to be an improvement over that.

As a genuine question, what sort of size would you expect for an optimised native app with the same functionality?

For reference, when settled, Gmail in Firefox uses 200MB or a bit more, while FastMail uses around 10MB.

I’m tempted to make a FastMail Electron app just to demonstrate that Electron/HTML/CSS/JS doesn’t need to mean slow and heavy (it just normally does).

Later: OK, so on Windows a trivial Electron “just load https://www.fastmail.com/login (and then log in)” app uses ~230MB of RAM. Not what I was hoping for, though it doesn’t surprise me a great deal—Chrome is quite happy to use lots of memory. Interestingly, when I reduce it from 3000×2000 to 1600×1200 (device pixels, it’s a 2× display), it goes down to about 160MB after a bit, and minimised to 180MB or 120MB for the two window sizes. Still very snappy despite this memory usage, though, for FastMail is fast.

> Gmail in Firefox uses 200MB or a bit more, while FastMail uses around 10MB.

Yes, but that’s not a fair apples to apples comparison with his 300mb number. Your looking at the memory used for that tab, not the shared memory used by the browser across tabs. Open Firefox with no sites open and check your baseline memory usage. Add that to the numbers above for a direct comparison.

I sought only to compare Gmail with FastMail, to indicate that Gmail is a poor baseline for memory comparisons.

Fair point, I agree there!

How exactly will you cut the fat in Electron? What’s a hello world like?

I’m tempted to make a FastMail Electron app just to demonstrate that Electron/HTML/CSS/JS doesn’t need to mean slow and heavy (it just normally does).

See my update to the comment. Its memory footprint is greater than I expected. I shan’t pursue it any further at present, I was mostly just curious to get an initial feel for it. Taking it (or something like it) to a polished product is something I’d like to do, but I’ve got other, much more important things to do on FastMail and Topicbox, and I don’t think anyone else in the company feels strongly about it, so it’s unlikely to ever actually happen.

One avenue would be to use a different, more light-weight engine; https://github.com/zserge/webview, for example, can use the local platform’s engine, which is likely to be somewhere between a little and a lot more efficient than Electron/Chrome. Running FastMail with the MSHTML renderer via the Rust bindings for that (DPI scaling issues, but meh), it starts at about 60MB but is easy to get over 80MB with some use. Still quite a lot less than Electron/Chrome.

Maybe you can help me understand the outcry over Electron memory usage, especially on HH. I can't remember the last time I ran out of memory on my laptop or desktop unintentionally. Seems to me battery life and jank should be main areas of focus. You can have a 2GB if you cut CPU usage and typing latency.

Just because you "can" use a bunch of memory without issues now doesn't mean you "should" not make any attempts to cut resource usage whenever possible.

Of course you're right. But why does it seem like memory usage takes precedence over battery life and latency? I may be in the minority, but it seems to me a native app's key advantage over Electron is performance/watt and I don't see how reduced memory usage would help.

I've run out of memory a few times this week on my Linux VM at work, and also at home on the beater laptop I use in the living room. Those are both stuck at 4GB of RAM, though.

On my laptop with 16GB, it's certainly been at least a few months since I've done anything that made it hit swap.

I said "unintentionally" as a hedge for corner cases like VMs where you are likely aware of the limits. I probably should have been more clear. I also prefer native apps, which is why I still mostly use Sublime over Code despite the latter's advantages. But it's because of speed and battery life, not memory consumption. If we're going to make a case for native apps, lets at least focus on the biggest pain points, as the proliferation of Electron indicates we're not making an impact.

Battery life's something that I only rarely have to think about. All of my development has always been somewhere with convenient power. It irks me when the CPU's churning along on a process that should be near-idle, though.

> I said "unintentionally" as a hedge for corner cases like VMs where you are likely aware of the limits.

I was aware of the limited memory of the VM, but almost everything I run there is a text-mode application, so it usually doesn't matter. Honestly, I thought that Slack would fit easily in the free memory, but I'm logged into 3 teams, so it ate more than I expected. And it's a spinning rust drive; swapping sucks, and it slows down the host OS at the same time.

It's an avoidable situation; just run Slack under the host's Windows, instead of in the Linux VM. But it remains the case, in my uses, that memory has caused more issues than CPU, and that CPU has caused more issues than battery drain. I don't know why everyone else focuses on memory so much...I perceive my own issues as kind of a corner case.

That's it? My Gmail tabs used to take 2GB (the last time I checked, years ago).

Actually, that was just from just loading Gmail and letting it idle, a couple of weeks back, not actually using it. A year and a half ago, I recall it being more like 125MB, up towards 150MB as it was used. Gmail hasn’t really changed since then, but the Hangouts widget (which is pretty heavy!) might have, and the browser definitely has (I blame it for most of the increase). I haven’t actually used Gmail since around that time.

For reference, I’m using the explicit/window-objects/top(…) figure from about:memory. This is not an accurate representation of the full footprint, but is close enough.

> considering that many emails have embed HTML and would ideally use a modern web view to render correctly

It might be me, but i prefer them to be rendered incorrectly in a text-only view :-P. I use email since the 90s and so far i do not think i can come up with any case where the HTML in an email was actually useful and not used for fluff (which i do not mind but can do without), branding (which i do not care at all about) or -way way more often- advertisement.

Also almost all HTML mails i've seen come in text-only version too and any useful bits are attachments anyway.

My Outlook (2016) client is using ~300MB right now while displaying a full HTML spam mail (taking one for the team, guys). I wouldn't say I'm a heavy user, but there's shared calendars and mailboxes, OneNote integration, task list etc.

Concur, my Outlook (2016/365) is currently using 250Mb. That's with 4 mailboxes open, and a heavy HTML email displayed in the reading pane.

Outlook is using 46MB for me at the moment. I don't have a particularly large inbox though.

Outlook is using less than 220MB for me right now, and that's fairly standard. It seems to be fairly optimized.

My Claws Mail currently uses 56M, multiple IMAP accounts configured, a few thousand mails, just visited all accounts before measuring. I disabled HTML display, though (most HTML is either spam or newsletter fluff in my experience). Claws is GTK2.

Most of this comes from overhead in Chromium, which currently (the version used by Ivelope) suffers from a few bugs which increases memory usage. I think this will drastically go down as time progresses and new updates of Chromium becomes available

not intended to be a hostile ask here, but do you know any specific bugs to check out?

As a past (very minor) contributor to chromium+webkit I'm curious if there's anything one can do to help, but I haven't kept up with their status in a long time.

Specifically the image bug, as another commenter linked to: http://seenaburns.com/debugging-electron-memory-usage/

Is this even considered a bug by the Chromium team (i.e. is there any indication of plans to fix it, or is this just the image cache working as intended)?

It's a 10 year old project and memory usage has always been fairly high, I don't see any indication of a major focus on reducing it anytime soon.

I don't hate Electron apps or anything, but the ones I already have open are using up enough of my memory that there isn't much left to run more of them. I really do hope this improves in the future though. If not I may just have to buy more RAM.

Why in this day and age are electron apps this big? What happened to memory management? Is this a faulty aspect of JS or electron itself?

Electron is basically Google Chrome. High memory use has nothing to do with JS.



That's just the base cost of using electron (along with the associated CPU usage). It's terrifying but you get that much usage even if you're not storing anything in memory.

Well that's just not accurate. With our Electron app, the main process consumes 40mb of RAM, with each window using 30mb of RAM, so if you have a windowed app, thats a minimum of under 70mb of RAM (results will differ, our app is quite large).

Yeah, this is realistic. I wish people would stop perpetuating the myth that "That's just how Electron is". It's perfectly possible to write Electron apps that don't automatically hog half a gig of RAM.

That's news to me, and people who make electron stuff tell me they can't get it down below a few hundred mb of memory usage. Can you point me to some resources about reducing that?

I'm curious too! I found one interesting article about Electron eating memory with images: http://seenaburns.com/debugging-electron-memory-usage/

Are there any examples of Electron apps that don't do that, though? I've never seen one that didn't like to eat at least a few hundred MB, and most of them seem at least somewhat leaky, too.

How are you measuring the RAM usage?

Thunderbird takes 425mo of my ram right now.

I switched from Thunderbird to Gmail because of that; it was quite bad on my laptop. It often started swapping requiring very long waits or a reboot to get back to work.

For comparison, my Thunderbird install with over 60k messages stored locally hits about 220MB.

Ask native thunderbird developers, why Thunderbird take 400 MB of RAM, only after start the programm.

Because Thunderbird is not actually native, it uses Electron's precursor XUL.

> Do you prefer not having it in a conversation view?

I strongly prefer to disable conversation view, because the time (recency) and time interval (frequency) are obscured, at least from the inbox view of most readers.

There is a big difference to me between a thread with 10 emails in one morning, versus one with 9 emails over a week, followed by one this morning.

Awesome app man.

150-300MB seems more than acceptable for a local email client. A pedantic, vocal minority may be over-represented in this thread (it IS HN after all).

IMO Electron apps present significant advantages that justify its negligible cost, eg skinnable with CSS, inspected live with a web inspector, cross platform etc.

> eg skinnable with CSS, inspected live with a web inspector, cross platform etc.

All of these have been possible with Qt circa 2006. (There is no inspector out-of-the-box, but KDAB made one that could be injected via LD_PRELOAD.)

Those are all advantages for the developer. I don't see anything that the user gets for the cost.

More features, faster. My gripe is that I pay 1000 euros for a laptop that will be for 50% consumed by 2 (sometimes even just Slack alone, don't worry) 'because it's convenient for the developer' created apps. The amount of money lost here is staggering ofcourse, but why would devs care as they are not on paying for that. I can totally understand it for a one person shop or an understaffed (underfunded) startup, but companies like Slack are just screwing their users here. Then again, if most of them don't mind that, who are we to complain; it seems to be where we are going. I began taking two laptops; a cheapo chromebook with chromeos to run slack, discord etc in the browser and another one to dev on. Works fine and I don't need to grind my teeth every time I look at top (there is no top as I just run chromeos for ease of use).

I think SyneRyder means what format are you storing emails on disk? If a user uses your email client to download all their pop3 email, is it available in a nice format on disk for whatever reason (backups/file recovery/migration to another client)? Or is it locked up in a custom file format.

>* I think SyneRyder means what format are you storing emails on disk?*

Yup, that's what I wanted to know. Since Thunderbird & Postbox both used the same Mbox Unix format for my 20 year email archive saved on disk, it was very easy to switch between them. And since it's an industry standard, I'm reasonably confident I could export/migrate it to a new email client when I have to - or find someone who has written software to do it.

Recent version of Postbox switched to the Maildir format, which is still, from what I've seen, not production ready in Thunderbird.

Currently it is not a standard format so right now there is no easy import/export - however this is a feature that is coming.

I still have nightmares about Outlook's non-standard format from 15 years ago.

What is the reason you do not store in a standard format?

Consider Dovecot's mdbox maybe?

> It's an Electron app, but it is built to use as little RAM as possible, when I run it on my old Macbook Air, it consumes only around 300mb of RAM maximum

I feel bad but you have already lost me there :/

That is maximum, normal is around 130 - 170 mb

I think the point is that it's better to have something using the native widgets of your OS if possible. It carries much less footprint and it integrates with your OS much more nicely in the end. Webapps running in Electron is just becoming too commonplace.

That also means building a separate UI for every supported OS, which isn't usually feasible for a single developer.

Just an fyi, it looks like you need to include the www for the link to load.

Qt also isn't truly native (it renders its own UI components) and shares many of Electron's drawbacks, so it's only marginally better (and means you have to learn an entirely new platform if you're already familiar with web dev).

> marginally better

Not in terms of resources (CPU/RAM). It's way better than Electron.

I've done it.

I didn't say it's impossible (I've also done it), but for something that's not a full-time job/project, it's a lot of extra work that could be avoided by simply using Electron, especially if you are already familiar with web development but don't have any experience with any of the native platforms.

But the poster did say this was a full-time project.

And I don't believe that only having experience in web development is a good enough excuse for shoehorning web dev things everywhere else.

You're right, I missed the OP saying that. But I still disagree: prior experience with a platform is a great reason for using it. Maybe not for a company with lots of resources, like Slack or Microsoft, but definitely for a small team or individual developer. Any time you would have spent learning a new development platform can instead be spent building new features!

How much RAM does your mail client use?

I use notmuch with Emacs - so very little.

Before that I used mutt - also very little.

Does that support HTML email and images? If not, it seems like a different domain entirely. Other people in this thread have posted Thunderbird numbers and they're in the ballpark. After all, it is rendered in Gecko similarly to how ivelope is rendered in Electron.

Not directly. You can configure w3m to display HTML email, and it does a nice job within the constraints of text mode. Most normal mail, even with tables, renders well. If you get something really crazy you can pipe the message to a graphical web browser to view.

Native Emacs in a GUI can also show inline images (but not when running in a terminal, obviously).

Remote images in email is an anti-feature[0]. And if the images are attached to the email, why not just use an image viewer? Does your email client support video playback?

[0]: https://senglehardt.com/papers/pets18_email_tracking.pdf

That's fine, but there's no point comparing RAM usage between completely different apps like video players and email clients.

Because sometimes discussion centers in and around the images, as in discussion of analysis figures.

Given that it's an Electron app, is there a chance that we could get a Linux build at some point in the future?

Great work by the way!

Yes, multiple people have requested a Linux version and it is coming in the future!

> only around 300mb of RAM maximum

For a email client that is still more than I ever would accept. Do you hold all conversations in the RAM for searchability or something?

Nope, most is Chromium overhead and a bug that the Chromium team are working on. (300mb is maximum, when it's just running and doesn't run into any of the bugs it consumes around 170mb on my computer) I expect Chromium to use less and less memory as time progresses, so RAM will probably decrease in the future.

How much RAM does your current mail client use?

Inbox seems to use about 200mb right now. However this is within Chrome and runs several additional plugins.

When I use mutt I doubt it goes over 20mb.


But then it is mutt running inside a screen session in an xterm.

Screen is using 4m, and the largest xterm open is using 2.4m. So even adding in screen and xterm overhead that's still only 34.4mb.

Some more questions, as I don't see them addressed on the site:

1. Is there an extension architecture, that I might be able to write my own extensions?

2. Can I edit the "From" address on outgoing mail, and will it remember my preferred "From" address on a per-recipient basis?

3. Does it have extensive keyboard shortcut support, or does it require a mouse?

4. Does it work well with both of the Linux clipboards, the standard system one and the X-provided middle-click one? (Other Electron apps, such as Postman, do not)

1) No extension architecture right now. Do you have anything in mind you'd like to build?

2) Not at the moment, but it supports multiple email accounts at once and you'll be able to move emails effortlessly between accounts in the near future.

3) Yes, it has extensive keyboard shortcut support

4) It hasn't been released for Linux yet, but once it will, I'll make sure to try to address this issue.

> 1) No extension architecture right now. Do you have anything in mind you'd like to build?

Not yet, but I assure you that I will! Especially if the answer to the next question is negative...

> 2) Not at the moment, but it supports multiple email accounts at once and you'll be able to move emails effortlessly between accounts in the near future.

I have literally thousands of "accounts" as I have a catch-all domain that I've been using since 2001. I need the ability to edit the "From" address, minimum. And if I'm going to use the email client regularly, then it needs to remember the "From" address to use on a per-recipient basis. That is what extensions are for!

> 3) Yes, it has extensive keyboard shortcut support


> 4) It hasn't been released for Linux yet, but once it will, I'll make sure to try to address this issue.

You are welcome to contact me for testing. muszc-master splat dotancohen spot com.

From what I can tell, Electrino is a dead project. Looks like someone picked up the idea and is making another called Quark (https://github.com/jscherer92/Quark) though.

Sounds very interesting, although Ivelope interacts a lot with the OS, and a lot of the Electron API would need to be added.


>many people won't use them, mostly for the technical reasons

I really don't think that's true outside of the HN echo chamber. Like OP, I am using a Macbook Air which is hardly a supercomputer and vscode runs perfectly fine on it.

There is almost universal hatred of the Slack app in our client relations department, due to performace. All use Mac laptops or Windows desktops, none of them know the term "Electron".

I wonder why people run slack stand-alone. I run it as a pinned tab in my browser and with browser notifications it works great. Very few issues running it this way and performance seems good.

I have Chrome users for browsing, personal email, work email and Slack. I had Slack in a separate Chrome window, in a pinned tab. I noticed that changing to my communications space was slow. By eliminating windows one-by-one, I discovered, the culprit was the Slack pinned tab. I tried the Slack standalone app instead, and that slowness is gone. I can't explain why, but the standalone native app may actually perform better. I think it's worth checking out.

I've gone back and forth between in-browser and stand-alone, but as my number of Slack teams grows, browser tabs get considerably less appealing. (I have five I monitor regularly and four more I don't care much about.)

Can't you build something "to use as little RAM as possible, given that it's using Electron"?


This conversation seems more analogous:

"I raise elephants, but they are bred to be as small as possible."

"They're _either_ elephants, _or_ bred to be as small as possible."

I'll accept that! Thank you for the perspective.

That is a tough question but if presented to me in the context of this thread I would probably respond, that it is a poor analogy.

Why do we have to make this complicated? The creator is using Electron, and within that given framework putting focus on RAM optimization. Moving on.

Programs do a lot more than they used to. Even though they solve similar problems as their predecessors. 300MB is perfectly fine for a modern app when computer team is measured in GB.

> For an application that deals with primarily with downloading, uploading, and displaying text.

Emails have become much more than that. They can contain almost everything a webpage can.

Most browsers use a ton more ram than 300 MB.

I call the F150 pickup I drive small. It is compared to the F350’s and semi that I’ve also driven.

In absolute terms it may be big. But for an electron app it’s probably not too bad.

Telegram is not an Electron app. It's a Qt app written in C++.

At least on Mac you can get the telegram app, or something called Telegram Desktop, which is Electron-based

If you mean this, it's written in C++ https://desktop.telegram.org/

If you mean this, it's written in Swift https://macos.telegram.org/

Telegram is not an electron app. It's native C++ and QT

The official telegram desktop client is Qt.

>FWIW I use the Telegram client which is an Electron app

What OS are you using Telegram in?

CentOS 7.3

_o_ 11 months ago [flagged]

Oh its electron :( Sorry not for me, please rather make a roundcube replacement out of it.

> Electron would be a deal breaker

You say that like HTML emails don't exist. If the client has to embed a web view anyway...

An small library for viewing static HTML is nothing compared to a virtual machine and dynamic rendering engine constantly causing unnecessarily high demand on memory, CPU and battery.

I'm an extreme niche, so I recognize that an email client that intends to be used by the general population would need it, but why would I even want to see HTML emails? Those are 105% of the time just marketing bullshit. Emails are either in plaintext with friends/families/clients/people or have a single link that I can copy/paste to verify an account on a website. As it stands, I never download images in my emails anyway. A few sites have tried serving the account verification code as an image and I just won't validate my account if that's the case.

Designed emails using HTML are used by marketing teams - not by people. I don't care to read emails from marketing teams "as intended to be viewed". Show me the email and let me read an email that's just a bunch of plaintext markup.

My laptop has a limited amount of memory, CPU time and battery life.

So... you make it a point not to read html emails on it?

FWIW, I can read HTML e-mails just fine via mutt in an SSH session. One doesn't need Chrome or Firefox to read them.

Could you go into a little more detail about this setup?

Not GP, but there are browsers that can render and dump HTML to plain text, like Lynx. You can of course also run remote X programs, but that seems a bit clunky.

You're not wrong on electron: this tech allow devs to be lazy and we all know that when we are allowed to be lazy, most of the time we are.

That said, electron can have a small fingerprint if the dev team is carefull/good enough, and is hte best option when your app have to be able to read HTML (and copy HTML formatted string). To me, an email client is a good way to use electron for an app.

Re: lazy: some would call that get more stuff done faster and cheaper.

I prefer to use the word "efficient"!

Or for advanced situations "selectively efficient" - using something other than Electron for an app that is intended to be cross-platform because [insert-alternative-here] is smaller/faster/other may be an example of premature optimisation and using something else (especially where that involves learning something else) could mean trading off elsewhere.

"this tech allow devs to be lazy"

Not just Electron but Sciter too in that sense.

"electron can have a small fingerprint if the dev team is carefull/good enough"

Only to some extent. You will have two separate process (at least) in any case and so two sets of the same system libraries loaded in them, IPC between them, etc.

Main task of browser engine is to provide safe browsing experience. Presenting HTML is only second its task and so browser based UI will always be sub-optimal (at best).

And let's not forget that thunderbird ui itself is rendered using gecko.

Every recent new app I can remember installing in the last year is Electron. Native UI is dead. It's more work and all it really buys you is the privilege of being tied forever to one platform or having to code your UI multiple times. The effort of writing your UI three times to use three different proprietary UIs would be better spent optimizing Electron for less resource use.

In the long term web will totally replace desktop UI. This could have been avoided if Apple, MS, and Linux would have agreed on a common desktop UI API 5-10 years ago but the ship sailed.

Or you use qt. Which is cross plateform, native, fast and open source.

Ask yourself why more people don't use Qt:

(1) With web technologies you can write once and run everywhere including mobile to some extent. Writing a UI multiple times is monumentally expensive. Even huge companies don't like to do this, let alone indie efforts and startups. If Slack with its billion dollars doesn't do it what does that say?

(2) The ecosystem is far more active. The web is the largest open source ecosystem in history. There is code to do literally everything and an embarrassment of riches when it comes to libraries, frameworks, connectors, etc.

(3) Qt isn't that much less bloated than Electron, especially when you start styling it and get dynamic.

(4) Long build times mean that I have to wait a lot longer between dev/test. UI development tends to be a whole lot of iterative hack-test-hack-test. With web tech it's literally edit-refresh, which is much faster than edit-make-wait-launch.

(5) To make Qt look good you have to start styling and using its weird surprisingly web-like stylesheets, which takes you out of pure native mode and into a hybrid rendering mode. At that point I'm halfway to browser rendering.

(6) If you code UIs with web tech you also get the web, meaning your app could be run remotely in a browser as well as locally. This is the networked app promise of X11, Citrix, etc., and you get it for free.

Electron is popular because it delivers a ton of value in terms of cross-platform compatibility, reduced effort, rapid development, consistency, and ecosystem. Performance and memory use problems can be fixed.

I have been watching this project:


It's a genuinely lightweight wrapper that looks really promising. Trouble is everyone I show it to says "ugly" as their first comment. Everyone wants styled apps today with polished UIs and that takes you down a path that looks increasingly like CSS whether you like it or not. I also have this strong feeling that if I wrote with it I'd be rewriting in 5 years after desktop UIs are abandoned in favor of 100% web technology everywhere. Of course web UIs shift a lot too. Maybe the fate with UIs is to rewrite every 5 years no matter what.

> Writing a UI multiple times is monumentally expensive.

I'm confused by this statement. The point of Qt is that you write the UI once. Your controller back-end might have platform-related pragmas, but not the UI.

> If Slack with its billion dollars doesn't do it what does that say?

When you give programmers freedom to choose what makes life easy for them, end-user experience suffers?

I really think all dev companies should have a lab of 'consumer-grade' laptops with 4GB of RAM and 20Mbit/sec networking. And QC shouldn't let anything ship until it runs adequately on those. Particularly for a company like Slack that is targetting corporate users, the bulk of whom aren't software architects with 2017 MBPs ( who make the choice ) but small-cogs with a five-year-old Dell.

You're right about my first statement. Was a bit of a thinko in that it's talking more about the conditions that lead people to choose Electron in general than responding to Qt specifically.

As others have pointed out in this thread: Qt is not really that much lighter than the web. It draws its own controls and even has css-like styling. I remember Qt apps being relatively slow on small machines... maybe not quite as slow as Electron but the latter could be tuned and improved and made competitive IMHO.

Your main point is valid, but you shouldn't be focusing your anger at Electron or at programmers for choosing it. You should be focusing your anger at desktop vendors for refusing to offer a better way to develop cross-platform apps in favor of an ultimately foot-blasting quest for platform lock-in. By refusing to play with each other desktop vendors have doomed all their platforms to obsolescence and abandonment.

> To make Qt look good you have to start styling and using its weird surprisingly web-like stylesheets, which takes you out of pure native mode and into a hybrid rendering mode.

Note that Qt does not have a pure native mode, it always draws its own controls - it just has a very good imitation of the native controls (especially on Windows).

"Qt isn't that much less bloated than Electron, especially when you start styling it and get dynamic."

Given how many smart people are working to make the browser techs as efficient as possible, and the way that things like QT get "bloated" as soon as they start trying to do what browsers do, I've pretty much arrived at the idea that once you have images and an engine that can reflow text and load fonts and so on, and you want this rather complicated functionality to perform at a reasonable level, you're looking at browser levels of resource consumption no matter what you do.

I mean, if you start working the math on what it looks like to have a bitmap of the screen in memory (which you may not literally have as a single flat plane, but we've got character caches, images, and all sorts of other things that add up to that pretty quickly, if not surpass it entirely very quickly), on a high-resolution display, a bit of extra memory left over from packing those resources, the dynamic scripting language space, the other support modules, various other bits of uncompressed media even if it's just windowed... you've gotten into the hundreds of megabytes pretty easily there. Maybe you could keep this below 100MB with a lot of work, but in a world where a single uncompressed 4K full-color image/framebuffer is running you at least 24 MB (for RGB, 32MB for RGBA), 10-50MB just isn't going to be an option.

I've got an emacs here with a couple dozen source code buffers loaded and it's running at about 60MB resident. That's a mere 1/5th of the Slack usage that everyone is incensed about, and while emacs can do a lot of things, it's still taking a pretty substantial capabilities hit vs. Electron to get that small.

Yes, I know emacs can have a web browser in it and such. And if I use eww to load news.ycombinator.com, emacs resident usage just jumped 15MB for what is, frankly, a terrible rendering. It isn't even rendering my jerf.org terribly well, which in modern terms is basically built by rubbing two sticks together and sending the resulting sparks down the wire. That's what 15MB on top of the already-loaded emacs bought me.

I agree with that to some extend, but the fact is, except for some very specific cases like vscode, I not only don't need "styling and dynamic", but I don't want it to be.

My OS has UI semantics. I want most of the apps to work the same everywhere. Your app is not special. Stop reinventing a "visual identity". Give me congruency and features.

"I agree with that to some extend, but the fact is, except for some very specific cases like vscode, I not only don't need "styling and dynamic", but I don't want it to be."

Actually, I'm not referring to things like colors or fonts. What I'm referring to is the fact that had the web-browser style layout algorithms not been already invented by web browsers, they would have been invented by the inexorable progression of the pressures and features in desktop toolkits by now. If the people using web toolkits want to be able to lay things out without having to laboriously bundle things into horizontal and vertical scaling groups and specify flexing ratios and all the other crappy layout mechanisms used in desktop toolkits since they first came out, but to use a simple (to use, not implement), powerful HTML-esque layout mechanism, you're going to pay for that on the resource consumption.

And the people writing these programs want that, and will use toolkits that offer that, and if that's bothering you, well, spend some time writing this stuff yourself and you'll stop being bothered, you'll happily spend 100MB of the user's RAM to make the pain end. As neat as it is in some ways, and as much as it has been made to sing and dance over the last 50 years, that style of layout really stinks to use.

> you'll happily spend 100MB of the user's RAM to make the pain end.

And users, at least the savvy ones who hang out here, are saying that this RAM isn't ours to spend. Is there no way that we could spend more resources on our dev machines instead, at build time, to take a piece of code that was pleasant to write and convert it into something that's frugal with resources on the user's machine? C++ and Rust promise abstractions with zero runtime cost compared to the best that you could hand-code. I wonder if the same can be applied to multi-platform GUI toolkits, perhaps through compile-time metaprogramming.

I totally agree.

Modern UIs with support for themes, complex interactions, multiple screen and pixel formats, and every language spoken by Homo Sapiens since Gobekli Tepi was built are large and complex. It's not avoidable. That is the problem domain. If you're doing less than that you'll regret it when more and more users start requesting features you don't have or complaining that your product doesn't look right on X or with X language/font/etc. That's my problem with all these ultralight immediate mode UI libs like nuklear. It's like going back to MS-DOS or CP/M and saying "wow that's simple and fast!" Yeah but it lacks a lot of stuff you will need.

The web's rendering layer isn't perfect but it's better than many alternatives and isn't going anywhere, so putting a lot of effort into making it more efficient and robust is very logical.

> Modern UIs with support for themes, complex interactions, [...]

And don't forget accessibility. That's the part that makes me want to scream whenever I see a new lightweight UI toolkit on HN.

> Trouble is everyone I show [libui] to says "ugly" as their first comment. Everyone wants styled apps today with polished UIs

I don't think I'll ever understand this. What about consistency between apps? Sticking to the OS's native widgets and style will get you that. Do people really like it when each app has its own look?

Of course, I'm no judge of aesthetics. Being visually impaired, my idea of a perfect UI is something with high contrast and large text.

Nr. 1 implies that they (or their users) don't care about efficiency. It doesn't tell us anything about native cross platform development being expensive.

> Every recent new app I can remember installing in the last year is Electron. Native UI is dead.

In terms of Electron, I have installed: Slack and VS Code (although I later uninstalled VS Code, and will have to put Slack on a machine with more memory than the VM it's in now).

I can usually spare the memory, at least on my non-crap machines, but I haven't really had the need to.

One could have used e.g Qt.

> Electron would be a deal breaker - but I'm weird

Guess I'm weird too.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact