Hacker News Reader

Comment by rco8786 | Hacker News Reader

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.

View on HN

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

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

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

Marketing? 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?

NIH Syndrome. You can't make a walled garden out of IRC.

Why can't you? You just don't connect your IRC server to any other server.

True, so maybe they're also hoping for patents or other ancillary NIH benefit.

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

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

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

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

That's fair. I wonder if users actually care in practice.

The other side to the market question is that this tradeoff may be why they're big in the market - because it allowed them to get to market quickly. So they made the trade-off knowingly, and for a reason that makes sense.

The question then becomes, once established, do they improve the app?

Yeah, I think that's a key question as well.

I'm seeing lots of people around me just giving up on Slack and switching to Telegram. It's not a shining example of good engineering, but it's still noticeably leaner and faster.

I haven't used Telegram in a professional setting but seems like a good solution. I'm hoping Matrix/Riot takes off and the open protocol enables a native experience.

This is literally the same argument people were making when the JVM came out.

But is it a true argument or a false argument? That's what matters.

What matters is that it's an argument against progress. It's an argument of good vs perfect.

Can you give me some examples of platforms whose memory usage has meaningfully gone down over time?

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

Its not even the RAM that annoys me the most about Electron - its the hit to the battery life.

Reply on news.ycombinator.com