[virmundi]

Similar real line: Does it still eat battery like a mid-westerner at a buffet?

I've thought about using underlying tech for a desktop app. I don't know how easy it will be to sell given that it would drain battery at probably 1.5 the rate of a normal Java or QT app.

[cwyers]

As a Midwesterner, I have to ask, what do you coastal folks do at your buffets?

[twic]

Well they don't eat batteries, it seems. I know, doesn't make a lot of sense to me either.

[wyldfire]

Maybe they meant the mid-west of some other continent?

[doug1001]

not sure, but i think for buffet restaurants on the coast, "all you can eat" is at the customer's discretion; it's not a legal requirement like it is in the MidWest

[msbarnett]

I wouldn't really call buffets a coastal phenomenon.

I mean, there's the odd one here or there, but compared to the last time I was in Kansas, they might as well not exist.

[bryanlarsen]

I thought buffets were called smorgasbords in the midwest, or is that just Minnesota?

[heydenberk]

Trick question.

[peterkelly]

I think it's unlikely the performance issues are related to the underlying tech (that is, Electron), since it's basically a custom build of Chromium that omits the normal web browser controls. Performance-wise, if your app is suitable for running in a browser, it should be fine for bundling with Electron.

[ralmeida]

As noted in a sibling thread, other Electron apps such as Spotify and Slack do suffer from performance issues, and the general notion is that Electron apps are "slow by default" - that is, slow unless you take explicit effort to make them fast.

[coldtea]

Since when are programming editors handling large files and IDE-like features "suitable for running in a browser"?

I know there have been several (browser based programming editors) over the years, but all have been equally crappy and slow on medium to large files, and not that better at normal workflows either.

[ralmeida]

For what's worth (and to the best of my knowledge), Spotify's and Slack's desktop apps are based on Electron, the same "underlying tech" as Atom.

[PeCaN]

Yeah, and they're both pretty miserable. I'm thinking of unsubscribing to Spotify just because their desktop client is so bad.

Also, I'm not sure why Slack needs ~250MB of RAM. Seems a bit extreme for a chat app.

[Klathmon]

250mb of RAM for a chat app that can display 4k assets, renders every known written language under the sun side-by-side in multiple fonts, supports a stupid number of emoji, has an inline image viewer, realtime sockets kept open for notifications, includes syntax highlighting for a bunch of languages, a wysiwyg-ish editor for posts, one-on-one audio chat, and can work effortlessly with hundreds of people in a single channel (which is about as many as i've seen, but it could do more).

I think that's more than reasonable, and trying to get that number down to anything lower would be such a waste of resources for almost no payoff (what percentage of users do you think will have their lives measurably improved by having slack use 100MB less RAM?)

Oh, and mine is only using 100MB and has been running for a few days at least.

[coldtea]

>250mb of RAM for a chat app that can display 4k assets, renders every known written language under the sun side-by-side in multiple fonts, supports a stupid number of emoji, has an inline image viewer, realtime sockets kept open for notifications, includes syntax highlighting for a bunch of languages, a wysiwyg-ish editor for posts, one-on-one audio chat, and can work effortlessly with hundreds of people in a single channel

Not of what you wrote is even remotely difficult to be achieved, even in a 50MB-using native app.

In fact most of those things come for free with the OS and relevant native libs are already loaded into memory:

"renders every known written language under the sun side-by-side in multiple fonts", "supports a stupid number of emoji" (the OS font-renderer can give all that to all apps for nearly free)

"can display 4k assets", "has an inline image viewer" (I can do that in a trivial app that's 1MB or less).

"includes syntax highlighting for a bunch of languages" ...

Really, none of these features, and neither all of them combined, warrant 250mb of RAM.

[Klathmon]

But again, would it really make any significant difference in the vast majority of users?

If slack had taken the time to devote another team to developing another application (because they still need to support the web), possibly multiple applications for each platform, would they be where they are today?

Would that time and money pay off in any way? I really believe it wouldn't. To save a few hundred mb of RAM, you are looking at triple or quadruple your development and maintenance costs, not to mention making it that much more costly to add new features. That doesn't seem like a good payoff.

Obviously in places where it did make a difference (mobile platforms) they went completely native, and it shows in both the positive and the negative. Their mobile apps look and feel native, and work quite well, but they lag behind the "web based" clients in features. (most notably the new voice chat options are not in the mobile versions)

In a perfect world every application would be custom developed for each and every platform, and no expense would be paid to ensure that there are 0 wasted resources, but we are far from a perfect world.

Having a slack app that runs on any desktop platform, feels the same between all of them, and allows Slack as a company to exist is a win in my book, even if it uses a few hundred mb more than it should (which again, for me it only uses 100mb of ram, that's 1/320th of my total ram on this machine, and only like 40mb more than the tab that i'm writing this comment on is taking).

[coldtea]

>Would that time and money pay off in any way? I really believe it wouldn't. To save a few hundred mb of RAM, you are looking at triple or quadruple your development and maintenance costs, not to mention making it that much more costly to add new features. That doesn't seem like a good payoff.

I don't think writing native apps is so much more difficult that a web app like Slack. If anything, it's probably the opposite.

There are cross-platform (native) apps with custom UIs, like DAWs and NLEs that are an order of magnitude more complex in both their UI and their logic code, and yet are done with teams and by companies that have an order of magnitude less funding than a company like Slack.

[bnt]

Slack is eating up 560MB on my machine. I actually do wonder why it needs this much.

[ralmeida]

There's no doubt both of them are not resource-effective at all, especially compared to other apps made in other tech stacks.

However, both are pretty successful services, and since the parent comment expressed concern if an Electron app "would sell", these are examples that such apps are comercially viable (even with all the problems they have).

At the very least, one can use them to go to market faster and/or validate an idea. I do hope that Electron (or other similar techs) apps reach a point where they are viable long-term in terms of performance and battery-efficiency. I also dislike slow, memory-hungry and battery-draining apps as much as pretty much anyone, but one should not dismiss Electron as useless.

[ishansharma]

250 MB for slack is good. I am in 4 teams and it is consistently taking 1 GB or more.

Something is wrong when a chat app takes more RAM than my Vagrant VM running an entire OS!

[Touche]

I'm not sure why people insist on using the Slack app rather than use it in a browser tab. It's literally the exact same thing.

[merqumab]

If you have multiple Slacks, it's not. You can cycle through all your connected Slacks with the app.

[PeCaN]

My browser gets messy and I tend to lose the Slack tab. I could just pin it I suppose.

[asdf1234]

I dropped Spotify completely because of the ridiculous energy use.

[HalfwayToDice]

Ugh that's maybe why Slack is one of the slowest apps I've encountered on my Mac. Asides from Atom.