Live data from Hacker News

Migrating Slack's Desktop App to BrowserView

slack.engineering

131–140 of 214 posts

Re: Migrating Slack's Desktop App to BrowserView

#131

What the hell is taking up all that RAM? Slack is using over 800MB of RAM on my computer right now, and it's completely idle. I've got a C# process on my computer right now handling thousands of messages per second and consuming 1/20th the RAM. If you rebuild Slack in Xamarin you'd probably drop your RAM consumption to under 50MB, just a guess. JS fiends are gonna tell me C# ain't JS, and I agree. TypeScript ain't JS…

Why slack desktop use electron? Slack mobile app using xamarin. Why they not porting from mobile app to desktop? U must learn electron, and also not running on native

Re: Migrating Slack's Desktop App to BrowserView

#133
post #84

On macOS, web app wrappers created with Fluid ( http://fluidapp.com ) consistently use less resources than the official Electron-based versions, in my experience. It's a wrapper for the system-supplied Webkit, so it inherits those benefits from that. I've been experiencing a similar performance to Chrome in Safari 11, but lower RAM/CPU/GPU usage overall.

I used Fluid, now use MacPin. Apps are much smaller, essentially just the size of their JS bundles. But then you're back to cross-browser woes and no native layer.

Re: Migrating Slack's Desktop App to BrowserView

#134

Earlier quoted context omitted.

Yea a glorified chat app with video chat, audio chat, screen sharing and screen takeover remotely, file uploading, 3rd party integrations doing multiple things depending on your team setup, etc. I'd hardly call it a glorified chat app.

I'd be interested to see a study of how many users actually use those features. The company I work for mostly switched from using Skype for chat to Slack and I don't think I've ever done anything with it except send and receive plain text a sentence or two at a time. The only reason we are trying to switch from Skype is for the persistent and searchable history. I say "trying to switch" because about half the company…

My team built a couple bots that help us keep track of issues we are working on, schedule releases, etc. We also do all of our meetings on Slack; when you're on a call it automatically updates your Slack status to reflect so, that way your teammates know you are busy.

Whether people use all of Slack's potential or not it's a different discussion, but I'd rather have the ability to do more if I wanted to than having to look for yet another tool to solve a small problem.

Re: Migrating Slack's Desktop App to BrowserView

#135

Earlier quoted context omitted.

Yea a glorified chat app with video chat, audio chat, screen sharing and screen takeover remotely, file uploading, 3rd party integrations doing multiple things depending on your team setup, etc. I'd hardly call it a glorified chat app.

Messages.app does all of those and uses a tenth of the RAM.

You can control people's screens through Messages? And you can write simple webhooks and bots with a few lines of Ruby? Please send me some links, I'd love to do that.

Re: Migrating Slack's Desktop App to BrowserView

#136
post #124

Earlier quoted context omitted.

Yes, I have. Well, I guess it depends what you mean by large scale. But I wrote and shipped a Windows/Mac/Linux cross platform app using JavaFX with native packaging for each platform. I didn't try and match native widgets. I styled it to look like a desktop app. It was quite productive and straightforward. That said, Java likes to use as much RAM as it can get even if it could release a lot back to the OS. It looks…

Cant you put java apps on the leash with Xmax and Xmin memory ? I might be wrong, but I thought that was the case.

Yes, but within that leashes it will prefer not releasing back what it has. E.g. if you say minimum 256, maximum 1G, if you used 1G for a short time it tends to hold onto it. This is a performance optimization iirc - it is far cheaper to wait a bit if you need that memory again than releasing it to the OS and then requesting it back again.

Re: Migrating Slack's Desktop App to BrowserView

#137
post #109

Earlier quoted context omitted.

Have you actually written a large scale cross platform app for Linux and Windows? Sure, Qt components will show up on both platforms. But to get them to show up the same tends to be an incredible headache, especially if custom styling is applied.

Why would you want them to be the same? What percentage of people who use slack on both platforms and who care whether the appearance is the same on both?

Many people expect similar UIs for better branding and easier workflow.

Re: Migrating Slack's Desktop App to BrowserView

#139
post #54
post #15

On a related note, for an app I have open all day long but interact with on an event-driven basis - Slack's UI is just too darn big. I miss the days when the only chat UI was a small column (eg. ICQ).

I think Slack tries to mimic IRC more than ICQ, and all IRC clients I know had big windows, because they assumed you want to see what's happening on the channel at all times.

I wish Slack has multi-window view, like many IRC clients.

Re: Migrating Slack's Desktop App to BrowserView

#140

Earlier quoted context omitted.

I'd be interested to see a study of how many users actually use those features. The company I work for mostly switched from using Skype for chat to Slack and I don't think I've ever done anything with it except send and receive plain text a sentence or two at a time. The only reason we are trying to switch from Skype is for the persistent and searchable history. I say "trying to switch" because about half the company…

My team built a couple bots that help us keep track of issues we are working on, schedule releases, etc. We also do all of our meetings on Slack; when you're on a call it automatically updates your Slack status to reflect so, that way your teammates know you are busy. Whether people use all of Slack's potential or not it's a different discussion, but I'd rather have the ability to do more if I wanted to than having t…

Don't get me wrong - I'm 100% in favor of extensibility through plugins and bots.

I don't think that means that the default client can't be lean and efficient.

Post reply on HN