Hacker News new | ask | show | jobs
by newhere420 3356 days ago
> Electron applications are shite in comparison with proper native applications. They fail to integrate with the host platform, they are slow, they hog memory and drink power.

Are they though? The two applications that use the most energy on my Mac - by far - are Steam and Skype. Steam still has trouble with HiDPI and freezes when performing various UI interactions. The number of problems with Skype are uncountable.

I'm currently booted into Windows for work, looking at my current process stats, the top memory consumers are:

* Visual Studio (hodge podge of all kinds of things, 800MB)

* Chrome (215MB)

* Microsoft Intune (presumably native, 114MB)

* GitHub (.NET WPF application, 108MB)

* Explorer (native, 103MB)

* Search Indexer (native, 107MB)

* Lync (who knows, 98MB)

Meanwhile, the supposedly terrible Electron apps:

* Spotify - 58MB

* Slack - 93MB

* VS Code - 60MB

As far as interfaces go, Spotify, Slack and VS Code easily outclass GitHub, Visual Studio, Explorer and Lync in usability.

9 comments

Each Chrome (and Electron) app instance is a group of processes. You are probably just looking at the main process, while the bulk of RAM/CPU use comes from the renderer processes.

Here are stats on my (Linux) box:

* atom - ~500MiB (one window)

* slack - ~816MiB

* chrome - ~935MiB (two tabs + hangouts)

* google music electron app - ~500MiB

Nope, those figures were after adding up all the processes. What I have noticed in switching between platforms is that applications tend to report a far lower memory usage in Windows than on Linux or OS X.

Might just be an accounting difference. Forked process applications in particular are very difficult to account, because even their private/RSS may be COW from another process.

My figures exclude shared memory and are calculated as VmRss - Shared from /proc/<pid>/statm.

If you are using Windows 10, your missing Atom processes will be under Background Processes in Task Manager. For the sake of the argument, I just did a fresh install of Atom and this is what I see on the first run: https://i.imgur.com/0ZRSumF.png. ~220MiB (no files open, zero extensions).

That's really interesting! I have an up-to-date atom install that i've been adding plugins to for about a year now (up to like 50 or so), and has been running for at least 12 hours (windows 10), and currently has 7 ~500 line files open.

Adding up all the processes' (7 of them) private memory gets me 194mb.

I installed the 64-bit version, you might be using 32-bit.
No it looks like i'm running 1.15.0 x64.

It might just be a difference of platforms.

At least if one crashes it wont bring down the Chrome stack.
VS Code has way fewer features than Visual Studio, especially for C#/.NET development. VS Code is a minimalistic IDE, very useful, especially for javascript development where tooling is quite minimal anyways. But let's not think that VS Code outclasses visual studio.
VS Code is not an IDE in the classic sense of what IDE is - integrated development environment. It's a text editor with some debugging extensions. I don't think it is even comparable to Visual Studio at all.
That line is getting really blurry with both Atom and VSCode. Haven't used VSCode, but the only feature I recall missing in Atom right now is refactoring; and to be fair, last time I used a real IDE (XCode), I couldn't refactor there either.
For me, refactoring is something that is nice to have, certainly, but not what defines an IDE. The debugging and development facilities are what matter most.
A lot of that is available in "text editors" like Atom (and I assume VSCode). Of course, it depends on if someone wrote a plugin for your language of choice.
IMO it qualifies as an IDE for Typescript, and borderline with Javascript — slightly better than WebStorm in the former case and slightly worse in the latter — but not so much other languages.
I agree with you, but there doesn't really seem to be any native application that occupies the same space as VS Code or Atom. VSCode is not just a text editor like vim or Notepad++, as some people here imply. As you say, it's a miniature IDE. And it's far more comprehensive than Sublime Text.

For .NET Core + TypeScript, VS Code is almost feature parity with full blown VS, while being an awful lot faster. The only thing I find particularly lacking is debugging, but even that is coming along well.

I agree, I use VS Code because its the best choice I have for Typescript development on the Mac. However, I still miss Visual Studio while using it. The debugger especially wants to make me cry, though this might have more to do with Chrome than VS Code's front end for it.
> As far as interfaces go

You missed this qualifier in the parent comment.

You need to compare apples to apples:

The right benchmark for VSCode is not Visual Studio, but Notepad++ (5.9MB on my system right now).

The right benchmark for notepad++ is not visual studio. It's notepad2.

Notepad2 = 1792 kB.

P.S. Pay attention, this is kilobytes, not bytes :D

But it's impossible to do a real apples-to-apples comparison, because I use Atom more like an IDE than I ever did with notepad++, and Atom has magnitudes more features for me than notepad++ ever did and most likely ever will.

I don't care about the difference of 175mb of ram between the 2 as one of them (atom) is infinitely more useful for me than the other (notepad++)

> * Spotify - 58MB

Maybe for one of the processes, but on Windows Spotify needs at least three processes usually to run (five if you count the Web Helper and Crash Service which are probably native code). On my machine the three main Spotify.exe processes take up at least 170MB of RAM, often more. Although I wasn't aware they were using Electron as their app has a standard, native Windows menu bar.

Another one for your list: Nylas Mail.

We straight up would have not shipped it without Electron and the CPU it uses to sync is on-par with apps like Apple Mail & Thunderbird.

Nylas Mail

> Nylas Mail - The best free email app | Nylas - The best free email app

What exactly makes it "best"? It looks to offer nothing more than other "best" mail apps.

Hard to answer your question without hijacking the thread, but here goes:

• It's got pretty much all the power features out there like Snoozing, Open Tracking, Send Later, Reminders, Enriched Contacts (i.e. Rapportive), Unified Inbox, Swipe Actions, Templates, etc.

• It's open source and super easy to extend with JavaScript plugins. Developer have made dozens of themes and some cool plugins including PGP, Unsubscribe, Translation, Todoist, Trello, Markdown, etc.

• It's cross-platform for Mac, Windows & Linux with custom UI styles for each.

• It works with all mail providers including Gmail, Yahoo, iCloud, Outlook and even vanilla IMAP and on-prem Exchange servers.

• It syncs your data directly (not via a cloud service) for speed and security.

• It works offline, so you can use it on a plane or when you don't have WiFi.

• It's open source GPL available on GitHub with >20k stars: https://github.com/nylas/nylas-mail

• It's free.

It's also still improving and has over 800 GitHub issues and we would love help from anyone who wants to make email better! :)

There are other comments in here comparing react-native to Electron. Do you know if you could build Nylas Mail at the same pace with react-native? Will the binary size/RAM usage drop significantly on react-native?
I haven't yet seen a substantial desktop app built with React Native and afaik neither FB nor GitHub is investing in React Native for desktop so generally this is hard to say. React Native is more of a framework whereas Electron is a runtime-- much different goals though both are super cool and I'm enthusiastic about the future of both!
I'm holding off my downvote to see if i can get a straight answer out of you. Nylas Mail bills itself as the best email app. Them's strong words, but maybe you're worth the claim? Let's see!

I see from screenshots that Nylas has folders and labels. Can i use either of these in the following fashion?

- i can have a tree structure of them

- an email can be in two separate folders/labels at the same time

- folders/labels can be configured to learn which emails to automatically sort into themselves, based on the email contents, by dragging and dropping the email into or out of them

Ball's in your court.

E: Bonus round! In this screenshot there's only 6 emails in the list: https://www.nylas.com/static/img/nylas-mail/hero_graphic_mac... Is there a way to get a list of emails where each line is actually only a line of text tall?

Some quick answers

• If by "tree structure" you mean a folder hierarchy, yep that's supported. I think we have a current bug with dragging nested subfolders but we're working on a fix. (Surprisingly >99% of users have a flat hierarchy.)

• A thread can certainly be in two separate folders (e.g. Inbox and Sent) but an individual message can't be in two folders at once. In that situation there are two copies on the actual mail server. For Gmail/Gsuite this is possible via labels where any thread can have an arbitrary number of labels. We support both systems.

• "labels can be configured to learn which emails to automatically sort into themselves, based on the email contents" -- this is a really cool idea and something we've talked about internally. AFAIK there is no cross-platform mail client that does this today beyond things like manual Gmail filters. It could also be an interesting plugin that anyone could build on NM. We have a Slack chat room where folks discuss stuff like this if you're interested: http://slack-invite.nylas.com/

• And for your bonus round (haha) yes there are 2 different ways to configure the UI. One of them is 3-pane with a reading mode like Outlook, and the other is 2-pane that navigates like Gmail. http://i.imgur.com/Lt0x7O4.png

Also in 3-pane if you make the message list wide enough it will switch into the compact version: http://i.imgur.com/SaGp9eV.png

(Obviously it will show your real mail data. We have a "screenshot mode" for sharing stuff like this without revealing sensitive information.)

That's worth upvotes for the effort alone, thanks. :)

> Surprisingly >99% of users have a flat hierarchy

You tend to end up with it only after really long-term usage. All the folders with sub-folders i have got them after they got too big to be just one, e.g. "Perl coding stuff" has several subs, "Shopping", "Clients", "Computer Game Emails", etc. Some clients have additional subs. All started out as a singular one though.

> threads, not singular mails

Ok, fair enough.

> labels auto-learning by drag&drop ... AFAIK there is no cross-platform mail client that does this today beyond things like manual Gmail filters

Opera M2 does it extremely well since ~2000. Google Inbox does it ... eh. Mobile and PC, none, right. The filtering is honestly super easy to implement. It's a bayesian filter. In older email clients those were used to filter out spam. Opera M2 simply gives each folder one (user-configurable) and runs all the filters on each mail that comes in.

And to be fully honest here, i still use Opera 12 as my main browser, along with its mail client and don't see myself jumping ship ... anytime really since for me the combination of mail client and browser is key. However to respect an email client i expect it to be a feature match to Opera M2 at least.

Not interested in Slack. If you had an IRC channel tough i wouldn't need to sacrifice a chicken and a CPU core. :)

> UI

Ok, that looks fine. I personally prefer to have the email below the mail list, but that's not a huge thing. Maybe an option to consider. Screenshot mode is cute. :)

You can actually join the chat via IRC/XMPP. No chicken sacrifice required! :P https://get.slack.help/hc/en-us/articles/201727913-Connect-t...

I haven't tried Opera M2-- I'll check it out. Might be a fun hackathon project to train a Bayesian filter on every folder and auto-suggest routing at least.

There was a big IBM Research study a few years ago that showed it's dramatically more efficient to search email versus categorizing messages into folders. Here's a link to the full paper: http://people.ucsc.edu/~swhittak/papers/chi2011_refinding_em...

Mac is a third class ports for these software. They never got optimized like on windows. Not a fair comparison.

With electron, every OS is a third class port.

http://imgur.com/a/Ofyei

Chrome kills me. :(

Stop using it. Both Firefox and Edge have come a long way. I recently dropped Chrome and have not looked back.
For me (I open a lot of tabs), Chrome is unusable without 'The Great Suspender' extension
Most of the Electron apps use multiple processes so you'll want to add up all their instances.
And simply adding up all the processes will count all the shared memory multiple times (which will greatly inflate the "final number" to much larger than it really is)
Steam always used a HTML renderer, even in its 2006 first incarnation. Nowadays it uses the same CEF (chrome library) as electron uses.

So Steam was one of the first "Electron" apps. A very first one was Windows Explorer as of Shell update that came with Internet Explorer for Windows 95 (included by default in Win98). All the sidebars of Explorer were HTML based.

No, VGUI is not HTML.

Here's a fun one. Start Steam with `-dev` and hit F7. Widget factory VGUI edition!

Oh also, https://developer.valvesoftware.com/wiki/VGUI_Documentation

Have I talked about VGUI? No.

Valve used a very ubscure/niche HTML render engine initially for Steam (2006). The company/website behind that isn't online anymore. An older version of the Wiki had some brief info, but all these info vanished.

Stop spewing bullshit.

Here's an old revision from 2005 by a Valve employee confirming Steam used VGUI back then.

https://developer.valvesoftware.com/w/index.php?title=VGUI_D...

It talks about the Steam overlay. Parts of the Steam application were always HTML. First the little known HTML renderer from a defunct company, than Trident and later CEF.

search for HTML: http://www.plastic-warfare.com/SteamUIGray.zip

Funny how the old things stay online. Notice also the cyber cafés menu entry. http://www.steampowered.com/status/game_stats.html

>A very first one was Windows Explorer as of Shell update that came with Internet Explorer for Windows 95 (included by default in Win98). All the sidebars of Explorer were HTML based.

That's a stretch; X/SG/HTML user interface APIs are not the same as a whole browser with Javascript VM, full networking and security stack, full-featured/standards-compliant (X)HTML/CSS rendering engine plus support for legacy features, UI assets, multimedia support, sandboxing, resource caching/persistence, and so on.

Win95 with shell update up to Windows Me and 2000 had the full trident engine (same as IE 3-5.5) in the Shell (Active Desktop, Explorer bars, etc.). Windows ME/2000 can play audio and video previews in the side bar (all HTML based).

Also WinXP used a forked Trident engine with some removed features for "Software" dialog and various other features (Windows Help, etc).