Hacker News Reader

Comment by thdrdt | Hacker News Reader

I recently had to upgrade my RAM because I have Spotify and Slack open all the time. Today RAM is cheap but it is crazy those programs take up so much resources.

Another program I use a lot is Blender (3D software). Compared to Spotify and Slack it is a crazy complicated program with loads of complicated functionalities. But it starts in a blink and only uses resources when it needs to (calculations and your 3D model).

So I absolutely agree with you.

I also think it has to do with the fact that older programmers now more about the cost of resources than younger programmers do. We used computers without harddisk and KBs of RAM. I always have this in my mind while programming.

The younger programmers may be right that resources don't matter much because they are cheap and available. But now I had to upgrade my RAM.

View on HN

It really surprised me when I downloaded Godot only to get a 32MB binary. Snappy as hell.

Web apps masquerading as desktop apps are terribly slow and it's a surprise we've got so used to it. My slack client takes a few seconds to launch, then it has a loading screen, and quite often it will refresh itself (blanking out the screen and doing a full-blown re-render) without warning. This is before it starts spinning the fans when trying to scroll up a thread, and all of the other awkward and inconsistent pieces of UI thrown in there. Never mind having to download a 500MB package just to use a glorified IRC client.

I'm really enjoying writing code outside of the browser realm where I can care a lot more about resource usage, using languages and tools that help achieve that.

It's interesting to compare Ripcord[0] to Slack. Ripcord is a third-party desktop client for Slack and Discord. It has something like 80% of features of the official Slack client and a simpler UI (arguably better, more information-dense), but it's also a good two orders of magnitude lighter and snappier. And it also handles Discord at the same time.

[0] - https://cancel.fm/ripcord/

and is written by a single person, in Qt

I wish so much that 3rd party clients weren't directly against the TOS of Discord. I sorta miss the old days where it seemed like anyone could hook up to MSN/Yahoo/AIM.

I wish that too. More than that, I keep wondering whether there could be a way to force companies to interop, because right now you generally can't, without getting into some sort of business relationship with these companies. That's the problem with services - they take control of interop, and the extent to which interop is allowed is controlled by contracts between service providers.

Where in the terms of service does it say that third party clients are disallowed?

(It doesn’t.)

While it does not explicitly state that, it does say:

"(ii) copy, adapt, modify, prepare derivative works based upon, distribute, license, sell, transfer, publicly display, publicly perform, transmit, stream, broadcast, attempt to discover any source code, reverse engineer, decompile, disassemble, or otherwise exploit the Service or any portion of the Service, except as expressly permitted in these Terms;" [1]

Given that the API is not public if you are not using a bot key, I would think that using it with a third party client would take some form of reverse engineering.

The devs also stated that other client modifications like betterDiscord are against the TOS.

[1]https://discord.com/terms (Under Right To Use The Service)

Ripcord isn't a modification of their software. It's an original implementation. I didn't look at any of their code.

ripcord is amazing. I bought it right away because in its current form, it's already worth the money

Just remember that it's entirely possible to do awkward and inconsistent UI in native apps, and there's a very long tradition of it.

But at least it's generally faster when you do it!

LMMS (https://lmms.io/) is a full blown DAW that's only 33MB as well

> I also think it has to do with the fact that older programmers now more about the cost of resources than younger programmers do.

I'm not convinced it's the programmers driving these decisions. Assuming that it takes less developer effort - even just a little - to implement an inefficient desktop application, it comes down to a business decision (assuming these are programs created by businesses, which Spotify and Slack are). The decision hinges on whether the extra cost results in extra income or reduced cost elsewhere. In practice people still use these programs so it seems the reduced income is minimal. What's more, the "extra cost" of a more efficient program is not just extra expense spent on developers - it's hard to hire developers so you probably wouldn't just hire an extra developer or two and get the same feature set with greater efficiency. Instead, that "extra cost" is an oppotunity cost: a reduced rate of implementing functionality.

In other words, so long as consumers prioritise functionality over the efficiency of the program, it makes good business sense for you to prioritise that too. I'm not saying that I agree with it, but it's how the market works.

Maybe we need a power declaration of software as with dish washers. (No joke)

> In other words, so long as consumers prioritise functionality over the efficiency of the program, it makes good business sense for you to prioritise that too.

And the kicker is, consumers don't have a say in this process anyway. I don't know of anyone who chose Slack. It's universally handed down onto you from somewhere above you in the corporate, and you're forced to use it. Sure, a factor in this is that it works on multiple platforms (including mobile) and you don't have to worry about setting it up for yourself, but that has nothing to do with the in-app features and overall UX. Or Spotify, whose biggest value is that it's a cheap and legal alternative to pirating music. And that value has, again, nothing to do with softare, and everything to do with the deals they've managed to secure with artists and labels.

I exercise my preferences wrt. Slack by using Ripcord instead of the official client. Most people I know exercise their preferences wrt. Spotify by using YouTube instead (which is arguably lighter resource-wise). And speaking of alternative clients, maybe that could be the way to go - focus on monetizing the service, but embrace different ways of accessing it. Alas, time and again, companies show they prefer total control over the ecosystem surrounding their service.

> And the kicker is, consumers don't have a say in this process anyway. I don't know of anyone who chose Slack. It's universally handed down onto you from somewhere above you in the corporate, and you're forced to use it.

The consumer here is the business itself, not their employees.

Technically yes (well, the customers, not consumers), but that's the problem itself: the feedback pipeline between end-users and producers is broken because the end-users aren't the customers.

As a younger developer I'd say I agree. But it's not just developers being used to resources being plentiful.

I do webdev mostly and there it's also a matter of management. I want to optimize applications to be less hungry, those are interesting challenges to me. But I've been told by management to just upgrade the server. Either I'd spend a day optimizing, and maybe fixing the issue. Or we just spend 50 euros a month more on a server.

Sometimes the optimization is not worth the effort. For applications like Blender? Optimization means a lot.

> Either I'd spend a day optimizing, and maybe fixing the issue. Or we just spend 50 euros a month more on a server.

So, discounting additional effects like more satisfied userbase, the optimization would pay for itself in a year. And optimizations stack.

Yes, that was my thought process as well. But management didn't agree. To them, the short term cost of me optimizing the problem was higher than the long term costs would be.

Something I noticed over my career. Programmers tend to get super beefy machines. My machine has 64GB of memory, and 12 cores. But the typical users who use our software don't have anywhere near those same specs.. but programmers often just say "it worked on my machine" without thought about the specs.

Same problem exists with designers and monitors.

I like to imagine 20 years in the future we’ll see articles posted on HN, or whatever the cool kids are reading by then ;)

... articles with titles like:

“Slack in one Ruby statement” a la https://news.ycombinator.com/item?id=23208431

More seriously though, Spotify and Slack are optimised to intentionally be huge time wasters, so it makes sense the organisations that produce them don’t care about performance / efficiency.

Most Spotify user-hours are probably office workers or students pumping music into headphones while working. If anything it's a productivity application because it trades flagrantly unnecessary resource usage (streaming the same songs over and over) for users' time (no more dicking around crafting the perfect iPod).

On the topic of flagrantly unnecessary resource usage...

My first child was born six months ago. Newborns (we discovered) sleep better with white noise. So of course we found a three hour white noise track on Spotify and played it from our phones for every nap, never bothering to download it.

I find it hard to believe at least some of that that data wasn't cached on your device. Setting a track to be downloaded just means the cached data is evicted differently. If you run their desktop client with logging enabled you'll see this happening and I'd say it's likely to be the same across platforms. That is of course the actual reason they have a non-native app - to reuse the codebase and save money.

> But now I had to upgrade my RAM.

But I can't. My ram is soldered on. How many tons of carbon dioxide should I emit so that you can use React? There are ways to do declarative ui/state management without dom...

If carbon footprint is that important to you, maybe you should find ways to encourage companies not to solder on RAM instead.

Why not both?

My computer still computes with 2 GB of ram. It’s just that developers are gluing more and more stuff together to do things we did on Pentium processors with 64 MB of ram.

no. just because soldered on ram is bad doesn't mean that bad code is ok.

I guess the question becomes: what is the native ecosystem missing that means devs are choosing to deliver memory/CPU hungry apps, rather than small efficient ones?

(Easy) Cross platform publishing.

HTML, CSS and Javascript. Most of these electron apps are basically wrappers around actual websites to give a place in the dock and show notifications and access the filesystem.

But that isn't what's missing. It's a restatement of the problem. DOM based apps are much more resource intensive than native. What is missing from native that makes business choose DOM?

If there was some modern tool like WxWidgets that supported modern apis like DOM, Android and UWP, would we see more use of native? Electron would therefore become pointless.

Qt Quick takes plenty of ideas from the web playbook.

https://en.wikipedia.org/wiki/QML

That is what's missing, albiet tersely stated.

The hypothetical business has two choices. Choose Electron, or choose some other toolkit that has native, cross-platform support (like Qt). It's far easier for the business, and the developers there, to take their existing website HTML, CSS, and Javascript; and simply wrap it in Electron (which costs $0), and call it a day. Every other choice is (perceived as being) more expensive.

Qt is a modern toolkit with native-cross platform support, but costs money for commercial use, and businesses and software developers don't want to spend the money on it.

as someone who has done both desktop apps and electron apps, it is much faster to write some html/css and wrap it in electron than to do the same in qt/gtk/etc...

Not to mention, the HTML/CSS combo is possibly the best we've come up with for designing user interfaces.

If you don't mind me asking, how much RAM did you have before, and what did you upgrade to?

I recently got a new PC myself and decided to go for 16GB, my previous one (about a decade old) had 8GB and I didn't feel I really hit the limit, but wanted to be future proof. Because as you said, a lot of 'modern' applications are taking up a lot of memory.

I upgraded from 8 to 16GB. But I'm in the process of ordering a new desktop that will have 32GB.

Spotify and Slack are not problematic as individual programs but since I have a lot of other programs open they are the ones that take up more memory than they should. I mean: Spotify is just a music player. Why does it need 250MB RAM?

Because it is not just a music player. It plays music, aside from giving you an entire experience that consists of connecting with your friends, managing your music library, consuming ads, having a constant connection with the server, and ...

This was meant to be sarcastic, but I'm not even sure how to continue. Maybe someone else can bulk up that list to get to something that requires 250MB. :)

64GB RAM is borderline reasonable today. Why not jump to that?

It probably uses it for buffering.

I also went from 8GB to 16GB recently (virtual machines are hungry); but I had gotten rid of Slack even before that. I mean, yes, it has round edges and goes ping and has all those cutesy animations - but 2GB of RAM for a glorified IRC client, excuse me, what exactly is it doing with billions of bytes worth of memory? ("Don't know, don't care" seems to be its developers' mantra)

The answer is JIT'ing JS.

For each of your Electron apps there is a little compiler chugging away.

Back in the day, we didn't have 2GB of RAM total, much less just for a compiler!

I work on a desktop CAD / CAM application, and I need every one of the 12 cores and 32 GB RAM on my windows workstation. I know this because I also have a mac workstation with lower specs (16 GB RAM, don't know offhand how many cores) and developing on it is intolerable (let's play "wait an hour to see if clang will compile my changes" - I know, I know, I should read the C++ standard more carefully so I'm not disappointed to discover that MSVC was overly permissive).

Parenthetically, we do use Slack and I am double-dipping on a lot of heavy functionality by having both Spacemacs (which I use for code editing and navigating / search within files) and Visual Studio (which I use for building, debugging, and jump-to-definition) open at the same time.

Pair that with some discord, vs code and chrome and all of a sudden my 16gb is getting maxed semi regularly

Just had to upgrade to 32 myself

m.spotify.com..?

Reply on news.ycombinator.com