Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Migrating Slack's Desktop App to BrowserView

slack.engineering

Post reply on HN
Print view View original

151–160 of 214 posts

Re: Migrating Slack's Desktop App to BrowserView

#151

Post by chrisco255 »

bernadus_edwin wrote: post #131
lwansbrough wrote: post #45

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

Because QA, design, and dev effort. You have to make a web app anyways, so it makes sense to align desktop and web.

Re: Migrating Slack's Desktop App to BrowserView

#152

Post by chrisco255 »

ivm wrote: post #150
petemill wrote: post #122

Earlier quoted context omitted.

Even if it was done in Xamarin, you'd still need some kind of web client / browser to fetch and render the actual slack workspaces

Why use web at all? IRC clients have been made with native UIs since the 90s.

Harder to work with than CSS. Harder to align look of web and desktop.

Re: Migrating Slack's Desktop App to BrowserView

#153

Post by chrisco255 »

peoplewindow wrote: post #111
SomeCollegeBro wrote: post #93

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.

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…

We're talking about Slack, for context. Non-trivial QA effort to build cross platform apps, even with Qt.

Re: Migrating Slack's Desktop App to BrowserView

#155

Post by revelation »

m_fayer wrote: post #114
SteveNuts wrote: post #48

Earlier quoted context omitted.

Same here, it's really nice to have VSCode, atom, slack, etc. RAM is pretty cheap, I'd rather put money towards a better Linux machine than give that money to Microsoft for the OS.

Oh what a lovely cycle. Every dev knows 16gb is the new 8gb so sure, why not have every desktop app consist of 20 independent webview/node processes. Can't wait until 32gb is the new 16gb. Eventually, when every single desktop app is like this, and we can no longer keep shoving more RAM into computers, we'll realise that the only way to manage such hogs is to pickle background apps to disk Android-style and to just h…

RAM is harmless. Even the most inept developers would struggle to waste as much of it as Slack Desktop.

No, the real casualty in this cycle have been spinning rust, good old hard disks. Their performance was never great but a sure fire way to kill it and make sure it never recovers is to trigger a full fucking unthrottled index scan at every boot that inevitably finds nothing changed. Looking at you Dropbox.

Re: Migrating Slack's Desktop App to BrowserView

#156

Post by mlvljr »

randyrand wrote: post #98
dang wrote: post #58

Earlier quoted context omitted.

Yikes, you can't comment like this on Hacker News regardless of how bad a desktop app may be. We ban users who do this, so would you mind reading https://news.ycombinator.com/newsguidelines.html and not doing it again? The idea for discussions on HN is: if you have a substantive point to make, make it thoughtfully; if you don't, then don't comment until you do. This isn't only about being nice, it's about preventing…

There's no need to ban. Just put comments like these at the bottom under a "see more comments" button. Then we can accommodate more people.

Nooooo, ban em!! :V

Re: Migrating Slack's Desktop App to BrowserView

#157

Post by ivm »

chrisco255 wrote: post #152
ivm wrote: post #150

Earlier quoted context omitted.

Why use web at all? IRC clients have been made with native UIs since the 90s.

Harder to work with than CSS. Harder to align look of web and desktop.

> Harder to work with than CSS.

Harder for a web developer for the first two weeks. UI builders are more suitable for making app layouts than CSS.

> Harder to align look of web and desktop.

Thousands of mobile apps do it without much trouble.

Re: Migrating Slack's Desktop App to BrowserView

#158

Post by outworlder »

brightball wrote: post #36

As a Linux laptop user, I fully endorse Electron. There’s so much more available for Linux because of it that would have no client at all otherwise. Between NVMe disks and the ability to have 64gb of RAM if I want...keep it coming. I’d rather have heavy software than no software.

Indeed.

Some posters seem to think that, because you CAN build a chat app consuming a few megabytes of RAM, it means you should and it's practical. It's like pointing to 64KB demoscene games and saying "see, you can write a game in 64KB, why does this one take multiple gigabytes".

Well, by all means, create a Slack competitor in hand-optimized assembly if you wish. Or whatever else you prefer (Rust?). If it's a better product, it may take over market share. Assuming your users even care about that. Hint: most are not obsessing over TOP, Activity Monitor, or whatever your OS uses.

Otherwise, don't whine. Electron makes it possible to create and ship apps very very quickly. Apps which would not exist otherwise. Every time you remove a barrier, you open up doors for more people.

While spinning up an entire browser for a single app has memory usage implications – namely, the baseline consumption is high, as is download size – the biggest issue is that it is easy to be wasteful when using web technologies. Look at Visual Studio Code, for instance. It's light and nimble compared to alternatives. It's true that a single one of its workers consume as much memory as a whole Emacs instance, but the development pace is staggering. And it still uses less memory than Slack...

Re: Migrating Slack's Desktop App to BrowserView

#159

Post by mateuszf »

ihsw2 wrote: post #143
rosser wrote: post #130

Earlier quoted context omitted.

Thank you. Are those runtimes all bytecode compatible? Or is that another layer of developer cognitive burden that the more efficient/performant/whatever choice entails, atop the whole "having a good way to write cross-platform applications" tangle?

Nope but few (if any) platforms will accommodate such a demand. Xamarin will produce different bytecode from mono, for example.

> Nope but few (if any) platforms will accommodate such a demand.

JavaScript does though, and it even doesn't need bytecode.

Re: Migrating Slack's Desktop App to BrowserView

#160

Post by jsjohnst »

FanaHOVA wrote: post #135
saagarjha wrote: post #49

Earlier quoted context omitted.

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.

Screen sharing w/ control: https://support.apple.com/guide/messages/screen-sharing-icht...

As to web hooks and bots, if you really think that necessitates having it be a bloated Electron app, I don't know what to say.

Post reply on HN