3 ms·

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 use

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.

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

autoconfig 7y ago

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

pjmlp 7y ago
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.