5 ms·
I know right. Real "developers" only write in assembly with a completely separate codebase for each target platform. No code review or source control either, be
by rco8786 9y ago
I know right. Real "developers" only write in assembly with a completely separate codebase for each target platform. No code review or source control either, because they're not lazy.
Actual issues aside (yes slack takes up way too much memory and it's due to the platform they chose which is hugely bloaty but will undoubtedly get smaller/faster over time just as everything does) why would you choose to attack the developers for building a tool that millions of people use with great success? They're not lazy. They used the best tools available to them to deliver their product and they're reaching the limits of said tools. Now they have to address those limits. This is exactly how software is supposed to work.
- Rjevski 9y agoI choose to attack those developers because they're taking an easy path knowing that it will end up in a bad product, yet they still do it. At the end of the day I don't care which technology is used as long as the end product is good, however a chat client that uses 1,5GB of memory is the total opposite of good. Come on, it's a f'ing chat client - a solved problem and existing implementations (look at any IRC client) take like 100MB's max. I would have no problems with Electron if they somehow managed to get the resource usage similar to a native app.
- deleted 9y ago[deleted]
- npizzolato 9y agoPerhaps the attitude of measuring the good-ness of a chat client solely on how much memory it uses is one of the main contributors to the rise in popularity of Slack and the decline in popularity of IRC. I personally don't care if my chat client uses more ram than its competitors if it's easier to use. Judging by the amount of people using Slack, I don't think I'm alone.
- kelnage 9y agoIf its a "solved problem" then why aren't users flocking to IRC over Slack? The answer is likely multifaceted, but part of it is undoubtedly the usability of the client - which may be resource intensive, but that was likely a trade off for speed/ease of development.
- frgtpsswrdlame 9y agoMarketing? IRC's not sexy like Slack is. Realistically, it's going to take what, 10 extra minutes for a dev to get IRC down versus Slack?
- rhizome 9y agoNIH Syndrome. You can't make a walled garden out of IRC.
- cuckcuckspruce 9y agoWhy can't you? You just don't connect your IRC server to any other server.
- rhizome 9y agoTrue, so maybe they're also hoping for patents or other ancillary NIH benefit.
- omaranto 9y agoWhy would people flock from Slack to IRC? IRC is much older, it's probably more like people sticking with IRC and not trying Slack. Which presumably is happening in large numbers.
- deleted 9y ago[deleted]
- dman 9y agoCan you give me some examples of platforms whose memory usage has meaningfully gone down over time?
- Rjevski 9y agoNope, but memory usage has increased in sync with how technology evolved - software that used to take X MB of memory now takes X*2 but at the same time your laptop now comes with 2x or 4x the memory it used to. However Electron takes this to a new extreme - the memory usage of an Electron app is like 15x of that of a native app, and yet I can't buy a Macbook with 100GB of RAM.
- dman 9y agoIts not even the RAM that annoys me the most about Electron - its the hit to the battery life.
- vintagedave 9y agoThere's an important realisation as a developer, or in fact as anyone whose work affects other people. Consider a bug or badly created feature that costs users ten seconds of their time. Let's assume a hundred thousand users, encountering that once a day, for a year. That's 4200 man-hours lost per year. Is it user-focused to allow that bug to remain? How do you judge the importance of your users' time? Slack - often Electron-based apps in general - are fast for the developers to create, but cause problems for the users. There are many more users than developers, and a good question is, is the value of users' time and money less than the developers, or the user's resources (such as memory) the developers' to freely use? Developers can't write their whole app in assembly, but at what point do the problems their choice of technology cause for users overbalance a reasonable standard of consideration for their users and user experience? An app with the problems Slack has is one that has largely prioritised the developer's time and resources over their users. So your "real developers" comment is a straw man ;) But you're close, I think: better is to consider the balance of value developers ascribe to themselves vs their users and what use of Electron, and app behaviour like this, says.
- pspeter3 9y agoShouldn't this trade off be born by the market? If Electron is such a problem for Slack, users should be switching away to better engineered alternatives.
- vintagedave 9y agoJust because Slack is useful enough people use it, doesn't meant the tradeoff they've made when developing indicates a high regard for their users' machines or experience.
- pspeter3 9y agoThat's fair. I wonder if users actually care in practice.
- vintagedave 9y ago