5 ms·

This is a judgement on cost, and you're advocating for cheap app development for you. But what about the cost for the users of your app? * Huge memory impact

This is a judgement on cost, and you're advocating for cheap app development for you. But what about the cost for the users of your app? * Huge memory impact for your app * Non-native look and feel (no, neither Vue nor anything else give a native app experience) * Possible security holes, as Electron is patched behind Chrome, and your app therefore behind Electron * and more. 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.) 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.

cultofmetatron 7y ago
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.
- ivanfon 7y ago
  > 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/ https://cancel.fm/ripcord/ [1] https://dev.cancel.fm/service_features https://dev.cancel.fm/service_features [2] https://github.com/diamondburned/gtkcord3 https://github.com/diamondburned/gtkcord3
- franga2000 7y ago
  > 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.
moring 7y ago
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.
- comex 7y ago
  > 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.
- _jal 7y ago
  > 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.
jka 7y ago
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.
- AnIdiotOnTheNet 7y ago
  > How many software applications from the 90s can you still use effectively on your laptop [...] I run Windows, so most of them.
- asjw 7y ago
  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
bobblywobbles 7y ago
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 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.
uk_programmer 7y ago
> 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.
threatofrain 7y ago
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.
autoconfig 7y ago
> 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.
- ubercow13 7y ago
  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.
  - autoconfig 7y ago
    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.
    - ubercow13 7y ago
      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.
alsetmusic 7y ago
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.

cultofmetatron 7y ago

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.

ivanfon 7y ago
> 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/ https://cancel.fm/ripcord/ [1] https://dev.cancel.fm/service_features https://dev.cancel.fm/service_features [2] https://github.com/diamondburned/gtkcord3 https://github.com/diamondburned/gtkcord3
franga2000 7y ago
> 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.

moring 7y ago

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.

comex 7y ago
> 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.
_jal 7y ago
> 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.

jka 7y ago

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.

AnIdiotOnTheNet 7y ago
> How many software applications from the 90s can you still use effectively on your laptop [...] I run Windows, so most of them.
asjw 7y ago
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

bobblywobbles 7y ago

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

uk_programmer 7y ago

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

threatofrain 7y ago

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.

autoconfig 7y ago

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

ubercow13 7y ago
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.
- autoconfig 7y ago
  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.
  - ubercow13 7y ago
    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.

alsetmusic 7y ago

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.