Hacker News new | past | comments | ask | show | jobs | submit login

> It is a huge productivity boost for programmers at the expense of making computers slow.

It's a productivity boost for web developers, who don't have to learn a new language, and for companies that can hire cheap web developers instead of more expensive desktop developers. It's not a productivity boost for someone who knows (or is willing to learn) .NET or Qt.




Users benefit from it too since the alternative to Electron often is not .NET or Qt but no app at all, especially on Linux.


As far as I'm concerned, I'd rather have no app at all (and use an alternative) than have an Electron app suck users away from the potential native alternative.


So don't use it and use the web version. A potential native app is of no interest to me compared to an actual full featured Electron app.


In some alternate reality, reasonable resource usage is considered a feature.

Meanwhile, in our universe, it's somehow considered reasonable to expend nearly six gigawatts (= 51 TWh per year) on a number-guessing game that will totally revolutionize global finance some day.


Resource usage in this reality will only become reasonable when there will be a noticeable penalty involved in unreasonable usage, but I guess it boils down to what you define as reasonable: If a noticeable penalty is measured by the end user then - sorry, enough users just don't care, which enables this technology to continue to gain popularity. If there was a law that companies need to pay a percentage of the energy their applications use then you'd quickly see everybody moving not only to native apps, but to the most efficient native apps.

In the meantime, the invisible hand is doing it's thing. Time will tell what it's thing will look like.


I think a brief look at the wiki page for 'Anthropocene' tells us exactly what the invisible hand is up to.


If the Electron app exists, there's a lot less incentive to write the native one.


See Slack. If Slack were still some plucky startup, I can understand it using Electron. But it's been around for a while now, and a more performant native application doesn't seem to be coming anytime soon.


Skype for a long time only had an outdated application on Linux. Now that MS converted it to Electron, it's available and regularly updated. The truth is, even for huge companies like Microsoft, the cost of doing a Linux-specific app is not worth it given the small user base, but with Electron they get this for free so they do it.

This is even more true for resource-limited open source projects, as cross-platform gui-based ones are difficult to get right, but Electron makes that easier.


Skype for a long time only had an outdated application on Linux. Now that MS converted it to Electron, it's available and regularly updated.

And now Mac users get the same terrible Electron app. The problem is that companies are not just making Electron apps for Linux users. They are replacing native well-integrated Mac and Windows applications by Electron apps (Skype) or do not consider writing native apps (Slack).

So, we had nicely integrated applications with Automator workflows, consistent shortcuts, consistent look and consistent feel. And we are replacing them by things that do not fit into the platform at all. No thanks.


Now I've heard it all - a company with a seven hundred billion dollar market cap can't afford it. Come on. They can absolutely afford to do native Windows / MacOS / Linux cross platform. They're lazy/don't want to.


> Now I've heard it all - a company with a seven hundred billion dollar market cap can't afford it. Come on. They can absolutely afford to do native Windows / MacOS / Linux cross platform. They're lazy/don't want to.

That’s a straw man argument. The parent said that Linux development might not be worth the cost. They didn’t say anything about the ability to pay.


So we, linux users, actively promoting alternatives for Skype, to increase cost of ignoring us.

«Team, M$ killed Skype for linux, I cannot use it anymore, let switch to something else, like Slack.»


They can afford it. They can also afford to put a man on the moon, but it isn't necessarily financially reasonable for them to do so. Think of Microsoft as a collection of teams, each team can't afford to spend "Microsoft" money on its project unless its strategically important. The fact that we don't have native app probably indicates that Microsoft thinks Skype is past its peak of popularity. Thinking of many competing products I understand why.


They can do it but if it's not profitable, they won't. It's not being lazy, it's being smart in the capitalist sense.


I'm fine with that, just call it like it is. This is what Microsoft truly thinks of developing a 1st class open-source solution - not worth their time because it's not profitable enough. So they'll give you a second class solution with the assumption you'd rather have that then nothing.


Skype used to have a small, snappy and useful app for Linux. Now that MS converted it to Electron, I no longer use it. Qt makes multiplatform apps trivial. Even I, as a hobbyist free software developer, can provide binaries for Linux, Windows and Mac.


A lot of people, myself included, actually preferred the Linux version of Skype.

But to be honest, I'd rather have no GUI app on Mac/Linux at all than have it basically be a requirement to waste resources on Slack or whatever other crap and to have developer energy tied up in an editor as shitty as Atom.


I'm working on a native client for Slack, Skype, Twitter etc.

It's only 90 KB (!)

https://eul.im


How you do this? Probably some of us could guess, but maybe will help people that only know electron :)


Cocoa on macOS, WinAPI on Windows, GTK on Linux.


Is this the one that uses OpenGL or something to render everything (ie nonnative text controls etc)?


Not any more. Now it uses native controls.


Oh nice, I need to check this out then!


Is it 90kb installer or complete app? Also what are using to build the interface?


It's the complete app. Cocoa on macos, WinAPI on Windows, GTK on Linux.


Nice joke. Repository is empty. Source archives are empty. Binary release for Linux: 404.


the dev is using github as a bug tracker, not as a place to host code. if thats’s a problem for you feel free not to download it


The dev released source archive for Linux to compile code by yourself. Empty source archive.


This is not true. Nothing has been released for Linux yet.


This is true. Nothing has been released for Linux yet.


Luckily Slack has the IRC and XMPP bridges. can't imagine any other protocols with a wealth of highly performant clients to choose from.

Unlucky for me, my admins refuse to enable the bridges and also won't grant me an API key for use with the weechat slack plugin.

I hate Slack so much. Slow and miserable and unconfigurable and just crashes at least once a month.


Sadly, Slack also happily breaks the protocols in their bridges, e.g. producing invalid IRC usernames. So even though our Slack has the bridge enabled, I can't login to it since it wants me to put a dot in my nick.


If the Electron app exists, often the alternative is no app at all.


I would rather run something in wine or run nothing at all than have to run an electron app. It's that bad.


Well, I'm a Linux user and I strongly disagree. Looks like opinions are indeed like a certain posterior orifice.


How bad is it to run Electron apps on Linux?


Slack uses ~ 2 GB of Ram and ~ 10% CPU when idle. I used it for a short while but now I'm just leaving a Slack tab open in my browser. Its exactly the same functionality-wise.

Basically I'm fine with Electron apps but I have yet to find one that I need and can't be replaced by a browser tab.


Comments like this make me wonder what's going on exactly. Surely your browser tab should now be using ~2GB of Ram and ~10% CPU, since it's the browser, HTML and JS part of Electron that's causing all that?

To be honest though, since my VS Code instance is sitting at ~500 MB (all processes together) and 0%, I'd wager it's not actually Electron itself that's at fault. It probably is incredibly inefficient compared to pure native code, and probably makes it easy to write inefficient code, but still, that's quite heavy usage you're referring to.


My guess is that a lot of memory in the browser is shared.

Another commentor in this thread wrote that VS Code is incredible efficient for a Electron app.


That could certainly account for some of the memory usage. I'm still confused about why there would be a 10% cpu usage on one, and not on the browser version (especially if they are equivalent, or even share underlying code).

VS Code certainly is efficient for an Electron app, and I'm sure it's really hard to achieve that level of efficiency. To be honest though, I use it side by side with Visual Studio itself, and on many metrics, it eats its big brother for breakfast (e.g. [1])... and that is a native app. One can argue that it's apples and oranges, and that the two are not equivalent, but we have an interesting counterpoint. While I'm sure performance is heavily weighted in favour of native, it seems like it's certainly surmountable.

[1] https://twitter.com/id_aa_carmack/status/695013979807047680?...


My theory on Slack's ridiculous CPU use is animated graphics. If some of those are on the screen the CPU use is at least 10%.


My theory is that their code is shit. It shouldn't be surprising given that their Chief Architect wrote a Medium post (Oct 2016) in which he cited concurrency as one of the primary benefits of PHP, and advocated for "curl'ing to localhost" to achieve parallelism.


On my laptop running Slack Linux 3.0.5 with 3 workspaces & several dozen channels, it idles at 0% CPU and ~550MB RAM (see screenshot [1]).

[1] https://i.imgur.com/juQbGW7.png


Comparing it to similar native app like pidgin it is still about 10 times more.


With 10 times the features, it’s not at all unreasonable.


That's also roughly what I see on Windows for my Electron app [0]. 0% idle CPU and about 200MB of RAM. That's large but acceptable compared with other non-Electron apps running, like Sublime Text (170MB) or Thunderbird (320 MB).

[0] https://imgur.com/tMhEwtp.png


You have some choice native apps - Sublime is Python, which is rather horrible with memory usage and Thunderbird essentially embeds a browser just like Electron apps.

Compare VSCode or Atom with Emacs or Gvim for something more native.

To pick some apps off my desktop right now:

- Emacs with a pile of extensions, 22 MB

- SpeedCrunch, 13 MB

- SumatraPDF, 19 MB

- MS Word, 101 MB


Uhh sublime is written in C++ with it's own custom UI the toolkit iirc. It only uses python for scripting.


In my list of applications that are always active, Firefox and ConEmu are also over 500MB too. The exception is Total Commander (amazingly, still compatible with Windows 3.1), which is only 20MB but it's more the exception than the rule.


Haven't been using it since ~ 2 years. My data might be out of date.


If it's a .NET app on Linux, you just run Wine, and you're all set.


This is the weird elitist argument again. I've done my share of native UI development, and it's total pain compared to HTML/CSS/JS. The tools are crap, the compile cycles too long, the languages to restrictive, the APIs too ad-hoc, the layout engines too crappy, the technology support (eg. multimedia) lagging too many years etc etc.

The native libraries had decades to fix this mess, yet they're still by and large the same as decades ago. Will not miss them.


> It's not a productivity boost for someone who knows (or is willing to learn) .NET or Qt.

You do not understand what a productivity boost is if you think learning a totally new language and framework is a better choice than using the tools already available.

But also if your logic were correct, we'd all still be writing C.


.net or qt don't offer all of the beautiful ui experiences available for the web. The latest and greatest in ui tech is now on the web in the form of JS/React/css.


Yes they do, with XAML and Qt Quick respectively. On the desktop, I'd rather have the normal menu + toolbars layout though.




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

Search: