Hacker News Reader

My laptop has about 32 gigs of ram so its less of a concern. That said, I find electron apps to be a huge drain on my Battery life.

As a developer, (with a lot of js experience) I sympathize with devs trying to build a product that works seamlessly crossplatform. Electron is a great value when you want to push out a product fast that serves a lot of users accross all devices and you have limited resources.

But I'm calling out slack specifically. you have millions in funding and profit. You can afford to hire a few more devs to make a polished native platform optimized version for each platform that is resource efficient. Slack runs on my desktop all day so having it run fast and not take up too many resources would be a huge win.

> But I'm calling out slack specifically...

I also don't understand this. What makes it even worse is that someone has already done this. I've been using Ripcord [0] for a few months for Discord and Slack, and it performs way better (it's native, written in Qt 5), and supports nearly all of those platform's features [1]. It is unfortunately proprietary (although I think the dev has open sourced the theming engine).

it doesn't look as beautiful (if you care about that), but it has most of the features. This is all done by 1 guy. Imagine what Slack and Discord could do themselves.

The real solution is to drop these proprietary solutions that don't respect their users. Unfortunately, while I love Matrix and Signal, the large majority of my social circle would never move to those.

Edit: I should also add, there's a very promising, open-source Discord client being developed called gtkcord3 [2], it's still very early in development, but it looks great and already supports the essential features, excluding voice chat.

[0] https://cancel.fm/ripcord/ [1] https://dev.cancel.fm/service_features [2] https://github.com/diamondburned/gtkcord3

> My laptop has about 32 gigs of ram

Mine has 8GB, and I'm a developer and photographer. A "normal" user won't even have that.

In the course of my "computer-janitorial duties" that the extended family expects from a relative who "works with computers", I have only seen >8GB in one teenager's gaming PC. All their laptops (some rather recent) have 4GB and low-power mobile chips. Skype, Spotify and Discord (in the background!) will bring their computer to a crawl. Add one or two Chrome tabs and all the computer is good for is a space heater.

Electron is a great value, true, but that's mostly because JS developers are plenty and therefore cheap. As a mostly web developer with little C++ experience, I was able to pick up QtQuick in a week and I've gotten actual user feedback saying they prefer that over the previous otherwise-identical Electron versions.

This is completely accurate.

I downloaded an app named Clicker for Netflix that was an Electron app. It wasn’t very bad, but it also wasn’t good. The dev rewrote it as a native Mac app. It kicks ass. It’s so much more responsive that it’s night and day different. It also gained a bunch of native controls (touchbar and such).

Building for the platform demonstrates that you care about your app and users.

Your concerns about security with regard to Electron apps is real. So much so that for the new project I'm working on, I spent a few months building https://github.com/reZach/secure-electron-template, which is an OSS secure electron template that fixes up the security holes so you don't have to worry about it.

> Electron is the solution when a developer values themselves over their customers. Now, you can make an argument for that, such as getting your minimum viable product out to market quickly. Over time, as the app develops, the attitude of happily giving your user lower UX quality and wasteful applications is harder and harder to justify ethically, though I admit that's only true if predicated on a foundation that you should respect your customer or have pride in your work.

You're entitled to hold this opinion but preaching it as if it is an objective truth and thereby disrespecting other developers is just obnoxious. Luckily the users can decide for themselves what is unethical or not. I have 5 electron apps open right now (Spotify, Slack, Figma, VS Code and Notion) and I find it absolutely absurd calling the devs unethical because of their choice. They have provided me with some fantastic value. Is it great that they take up ~100MB of memory each? No but it's not even close to as big of a problem as some devs try to make it out to be. 8 gigs of RAM is around 30 bucks. Get off your high horse.

The RAM thing is disingenous. Even on a desktop it could be more expensive than that to add more RAM, say if all your memory slots are populated. If you have a Macbook with soldered RAM, it could cost you a new laptop and thousands of dollars to get more RAM. But I guess Spotify is worth it.

Nowhere did I mention upgrading. The example was meant to give a general estimation of how much RAM costs and establish a frame of reference for statements like "huge memory impact". If RAM still cost say $100 per GB the situation would be entirely different.

I don't see how that's relevant. Upgrading is the point - previously the user's PC was sufficient, and now it is not as it is runing slow. Now the user has to buy a new computer. In the past they might have to do this to use the lastest games or such. Now it's necessary in order to run Spotify and Slack.

> Luckily the users can decide for themselves what is unethical or not

Do we? I run Slack and Spotify, but it's not like I have a choice since there's no native version for Linux.

Exactly.

I'll ignore the "obnoxious" and "Get off your high horse" comments. Despite your tone I think you have a good point that's worth addressing.

> Luckily the users can decide for themselves what is unethical or not. ... They have provided me with some fantastic value. Is it great that they take up ~100MB of memory each? No but it's not even close to as big of a problem as some devs try to make it out to be.

Right now I have Slack running on my Mac. The Slack processes and memory usage are:

* Slack Helper (Renderer): 384.5 MB

* Slack Helper (Renderer): 168.4 MB

* Slack: 134.2MB

That's a sum total of 687.1MB for a chat client.

Now, my memory resources are limited. Sure, I have virtual memory etc etc, but there are costs using anything paged out. Importantly, there are apps that I want to have memory available for: multiple virtual machines where taking several gigabytes is expected and a _good_ use of memory; image editors that genuinely require a lot of RAM. The key here is (a) resources are finite; (b) some apps genuinely need memory; (c) some apps are valued (by the user) in terms of memory higher than others. My machine is for me to use, not a third party to misuse or squander.

So why should I be happy with 687.1MB of _my_ memory used by a chat client, when a competent development team writing a native app could use a fraction of that and give me a better native user experience?

One point you may not have realised is that yes, memory has grown and is cheap, but the advantage of having more resources is to do more. I'll repeat that: _having more resources should allow us to do more_. Imagine that an app on my modern Nvidia graphics card with, say, 8GB of RAM used all that RAM and GPU power to achieve the graphics from my Riva TNT from 1999. Would you expect me to be happy with that, or would you expect me to not be impressed by the graphics apps using that card?

More, while memory is cheap for us, and many HN readers can probably drop thousands of USD on a new 16 or 32GB latest-model MBP, not everyone can. Many people use old computers, cheap computers, ones that cost $300 and come with 3GB of RAM and a 32-bit copy of Windows. Or they're using their laptop from 2011, because it still runs and money doesn't flow. They use those as best they can. And it's... privileged? I can't quite find the word, but I think we as developers should write our apps for them too.

There is also the matter of professional pride or self-respect. Could I, as a developer, be satisfied and feel I was doing a good job with my work on Slack? Did I "do it right", can I be proud of my work? Maybe, because it's useful and polished, but to feel I'd done a good job I'd have to have a very different set of values in terms of how I thought of my customers.

I use Slack because it's a team tool and they got to market with a cross-platform app early and/or with good marketing, and are now the default. Years later, they still use the same client. Someone in Slack HQ has made the decision that the improved user experience and respect for their user's resources is not worth the financial and support cost of developing a macOS native client. That's their prerogative, but you shouldn't expect me to like it. I'd have a lot more respect for Slack and Slack development (or management) team if they produced an app that 'Did It Right', that was built on the principle that the machine Slack runs on belongs to their customer, not to them.

> I'll ignore the "obnoxious" and "Get off your high horse" comments. Despite your tone I think you have a good point that's worth addressing.

You just blatantly declared a large number of developers as unethical for a technology choice so maybe learn to take it if you're gonna dish it out.

> That's a sum total of 687.1MB for a chat client.

I'll admit I was entirely wrong on the amount of memory here. Taking the renderers into account it's a lot more like you say. However the base footprint of Electron is less than 100 and the amount that gets used depends heavily on implementation details regardless of underlying framework.

> So why should I be happy with 687.1MB of _my_ memory used by a chat client, when a competent development team writing a native app could use a fraction of that and give me a better native user experience?

The fact that there is currently no other chat application implemented natively that brings you the same set of functionality should tell you something. This is the problem with reducing technology choices down to this narrow idea that only one thing matters. In reality there are many factors that comes into play such as the core competency of the employees you have at hand, team scalability, maintainability, time to market, etc. Slack may never have existed for all we know if they had to build it natively. You don't need to be happy about their product but you seem to be blindly assuming something better can be created with native technology when there is no evidence to support this case. Yes it can in theory, but in reality there are practical constraints.

> One point you may not have realised is that yes, memory has grown and is cheap, but the advantage of having more resources is to do more.

I'd argue we ARE doing more. That's the problem right there. People get so wound up about something like memory consumption that they forget the innovation that some of these apps have brought that perhaps justifies the extra cost. VS Code has IMO taken the place as the number 1 IDE. Would it have had the same improvement rate and rich ecosystem of add-ons if it wasn't using web tech? Probably not. Slack was a groundbreaking product when it came out. There has never been a product that offered the same feature set. Discord is another amazing piece of technology (I'd argue outperforms Slack). Again, you can claim all day long that these products would be better if they had UIs implemented from ground up in C++ or Objective-C but until someone actually does that the onus is on you to prove that it in practice can be done.

VCScode has, as much, taken the place of Emacs and VI.

An IDE? It still needs to catch up with Windows IDEs from the mid-90's, let alone what something like Visual Studio Professional is capable of.

> but until someone actually does that the onus is on you to prove that it in practice can be done.

It has been done, by a single developer, in their spare time: https://cancel.fm/ripcord/ .

It supports both Discord and Slack, is lighter, customizable and almost at feature parity with the official clients (except for a few things the dev refuses to do for philosophical reasons or whatever). If Slack hired this guy, I bet he'd be able to crush the official client within a month.

It'll take time for the landscape to develop, but I'd like to add some additional arguments for a web-based application stack.

Websites from the 1990s still render and function just fine in modern browsers. How many software applications from the 90s can you still use effectively on your laptop or smartphone?

If we collectively want to create and share data that will be accessible to older and younger generations, and build applications which stand the test of time, it'd help if the foundations we're building on (i.e. native SDKs, APIs, file formats, and platforms) stop shifting every few years.

I'd argue that even with the evolution of web/JS frameworks, the underlying HTML+JS+CSS stack remains more stable than most native development platforms (with the possible exception of the Win32 API which has been impressively maintained, and automake which has done great things to make Unix software portable).

Performance/memory impact is a good area to investigate further, as are any remaining areas where there's a gap between native and web-foundation user experiences. I totally agree with your criticisms there.

Since many applications are built using web technology I'd expect the stack has developed (and will continue to develop) good resilience against security vulnerabilities.

Driving down developer costs seem to me like a beneficial goal and I don't necessarily think that criticizing a desire for low-cost tooling and application delivery is a positive standalone argument.

There may be a few developers who see themselves as more important than their users, but that will become apparent to users over time. Given low-cost development tools there can easily be alternative applications for people to switch to which better respect user needs and goals.

> How many software applications from the 90s can you still use effectively on your laptop [...]

I run Windows, so most of them.

That's only part of what keeps developer costs down.

First of all, unless you're on a Mac, every other system can run old applications from the ninetees

Secondly, web is a moving target, you spend less now (maybe) but rewrite every 6 months, even if you don't want to (that library is not updated anymore, now we use this one instead)

Last but not least, electron is not a stable platform, a native API is

What happens to software written today in a year?

Wil it still run the same?

I don't think it will honestly

So you have to bundle electron, for every app

Sounds not very smart to me

> Secondly, web is a moving target, you spend less now (maybe) but rewrite every 6 months...

Isn't this the point? A lot of these devs who support using web tech seem to only be concerned with writing apps, not maintaining them. They also seem to have a fixation on, "Ohh! Shiney!"

> If we collectively want to create and share data that will be accessible to older and younger generations, and build applications which stand the test of time, it'd help if the foundations we're building on (i.e. native SDKs, APIs, file formats, and platforms) stop shifting every few years.

Except everything requires a remote server nowadays which likely won't be there to "stand the test of time", so that point is moot..

The right trade off between business and customer is a business lead’s call IMO, even though it has a lot of software technicality to the decision.

Giving the most fitting (absolutely not the best) service to the customer is the job of whoever owns the interest in the business. Would a customer rather pay more for the features you talk about? The features are either free and easy and there’s no cost to pass around, or the customer is ultimately paying for it. Most people working on a product are just the sideshow to the intersection between business interests and customers.

> What you're asking is that to ease your job, you give your customers a non-native UX (subjectively "bad", but that judgement is something I think most HN readers would agree with); and you value their computer resources very little (ie you don't respect your users' computers and are happy to waste their computing memory and CPU.)

Frequently the "customer" is a client and not the end user of the app. Assuming that someone doesn't respect someone else's computer because they use a tech that you don't approve of is ludicrous.

> Electron is the solution when a developer values themselves over their customers.

Nope. When you have limited resources i.e. small development teams you have to choose where the effort is going to go. Cross platform tech like Electron allows you to deliver to more customers with (theorectically) less effort, which can be put into many other things that might benefit the customer e.g. cost savings or more features.

> Over time, as the app develops, the attitude of happily giving your user lower UX quality and wasteful applications is harder and harder to justify ethically, though I admit that's only true if predicated on a foundation that you should respect your customer or have pride in your work.

There is so much wrong here. The whole premise makes a lot of assumptions that may not be true. Any Engineering Discipline is about producing a product that adheres to a specific set of specifications. This frequently requires making decisions dependent on budget, technology etc. Unless you have an unlimited budget you will have to make a trade offs. Claiming someone is unethical or doesn't respect their customers / end user because they used a technology you dislike is quite pompous.

I'll try to counter your arguments, even though I share your sentiments against Electron:

* Huge memory impact for your app

The same is true for native macOS applications.

* Non-native look and feel (no, neither Vue nor anything else give a native app experience)

Agreed.

* Possible security holes, as Electron is patched behind Chrome, and your app therefore behind Electron

Security holes with respect to what kind of threat? That is, for an application that gets installed on a computer and runs with user privileges (), what is the kind of threat that could break Chrome/Electron but not a native macOS application?

() If we are talking about sandboxed applications, the thread could alternatively be the application breaking out of its sandbox. A different analysis is obviously needed here.

* (...) you value their computer resources very little (...)

This seems to contradict the suggestion to write a native c/c++ backend. Such a backend can easily optimize the performance-critical parts. Premature optimisation isn't the same as valueing your user's resources.

* Electron is the solution when a developer values themselves over their customers.

This is a false dichotomy. A developer who makes his/her life easier has more time to work on things that matter, including optimization.

> This seems to contradict the suggestion to write a native c/c++ backend.

I’d much rather use an app with a native UI and a JS backend (like React Native) than one with a web-view UI and a C++ backend.

After all, the problem isn’t JavaScript. JavaScript may be easy to abuse, but it can be a reasonably fast language if used well. The main problem, in terms of both usability and performance, is HTML rendering itself.

> what is the kind of threat that could break Chrome/Electron but not a native macOS application?

This isn't abstract; it isn't about whether Electron is theoretically vulnerable to more vulnerabilities than a native app. It is about Electron's history of CVEs.