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

21–30 of 214 posts

Re: Migrating Slack's Desktop App to BrowserView

#21

Post by nerpderp83 »

nartz wrote: post #10

I think this article is really helpful when deciding to use a nascent technology (Electron) in production- pretty cool you can create a desktop app with javascript, but at the same time, expect to do a lot of custom bug fixing and hope that there aren't issues in the core code (note: there always are) =D

This isn't Electron's fault. This is slacks fault. Look at the memory footprint of VS Code opening hundreds of files. A much much more substantial application than slack that uses a small fraction of the memory. On my machine, VS code with hundreds of open files is using just over 200MB.

Re: Migrating Slack's Desktop App to BrowserView

#22

Post by plopz »

Following a link in the article led me to this nice quote[0] "The trade-off is that positioning and layering BrowserViews is trickier because you can no longer use the normal HTML and CSS positioning and layering primitives like you can with a webview. You have to manually layout BrowserViews and make sure that it is layered properly."

So to make electron less of a hog, you ditch the web part?

[0] https://blog.figma.com/introducing-browserview-for-electron-...

Re: Migrating Slack's Desktop App to BrowserView

#24

Post by ThrowawayR2 »

afandian wrote: post #7
saagarjha wrote: post #3

The screenshot shown in the article shows Slack using well over 600 MB of RAM. I'm not sure I find this acceptable for a chat app with four "tabs" open.

When these kinds of things come up there's often complaint that desktop apps running in the browser are inefficient. As it happens, I agree. An old favourite of mine, Adium, probably never used 600 MB because I'm pretty sure my PowerBook G4 had less RAM than that. But I think it's a mistake to jump to the conclusion that these apps should be written in a native framework rather than a web view. Slack is doing much mo…

> Maybe the detractors would prefer that the app did less.

Sorry, that argument just does not hold water. On my Mac currently, MS Outlook is using 483 MB versus Slack using 704 MB, with just one tab open. For all of Outlook's bloat, one can hardly say it does less than Slack; it's just a glorified chat app for pity's sake.

Even IntelliJ is using only 2x as much RAM as Slack with 4 medium sized projects open and IntelliJ is orders of magnitude more complex than Slack.

Re: Migrating Slack's Desktop App to BrowserView

#25

Post by saagarjha »

Klonoar wrote: post #12
afandian wrote: post #7

Earlier quoted context omitted.

When these kinds of things come up there's often complaint that desktop apps running in the browser are inefficient. As it happens, I agree. An old favourite of mine, Adium, probably never used 600 MB because I'm pretty sure my PowerBook G4 had less RAM than that. But I think it's a mistake to jump to the conclusion that these apps should be written in a native framework rather than a web view. Slack is doing much mo…

I'll second this and note that Telegram, an app actually written in native code, is currently using ~500MB on my machine right now. I hate to be the one to say it (mostly because I just don't care about the ensuing argument), but I think most people who decry Electron/et al don't actually have that great of an understanding of how memory works. I say this as a guy currently sitting here writing an iOS/macOS app in Ob…

> Telegram, an app actually written in native code, is currently using ~500MB on my machine right now.

I took a look at the Telegram source code right now, and…I'm not impressed. It appears to be written without a real knowledge of how Swift or Cocoa works, has no consistent style, and seems like it reinvents significant portions of standard APIs. Like anything, the benefits from migrating to "native" only work if you actually utilize it correctly.

Re: Migrating Slack's Desktop App to BrowserView

#26

Post by Twirrim »

saagarjha wrote: post #3

The screenshot shown in the article shows Slack using well over 600 MB of RAM. I'm not sure I find this acceptable for a chat app with four "tabs" open.

I was happy when we moved from the HipChat client that used several hundred MB of RAM over to Slack which is proving to at least be more svelt. I really don't want to go back to another RAM hog.

It's not like my laptop is just brimming with extra RAM, and being a Mac of course the RAM isn't user upgradeable.

My choice shouldn't be "be present in chat, or carry out work". Guess it's time to figure out IRC integration.

Re: Migrating Slack's Desktop App to BrowserView

#27

Post by rosstex »

nerpderp83 wrote: post #19
afandian wrote: post #7

Earlier quoted context omitted.

When these kinds of things come up there's often complaint that desktop apps running in the browser are inefficient. As it happens, I agree. An old favourite of mine, Adium, probably never used 600 MB because I'm pretty sure my PowerBook G4 had less RAM than that. But I think it's a mistake to jump to the conclusion that these apps should be written in a native framework rather than a web view. Slack is doing much mo…

You are making a false assumption that more features is something like geometripential in the amount of memory it should use. It is a list, with some images. They have Rubegoldberged themselves into some Sisyphusian box of poo while they expect us to row the SS Honeybucket to work and back. You know what my solution is for when I need to slack? I RDP to a VM running Slack. Mother of Lord! How about Slack sell lil USB…

> geometripential

please define this new word

Re: Migrating Slack's Desktop App to BrowserView

#28

Post by lobster_johnson »

afandian wrote: post #7
saagarjha wrote: post #3

The screenshot shown in the article shows Slack using well over 600 MB of RAM. I'm not sure I find this acceptable for a chat app with four "tabs" open.

When these kinds of things come up there's often complaint that desktop apps running in the browser are inefficient. As it happens, I agree. An old favourite of mine, Adium, probably never used 600 MB because I'm pretty sure my PowerBook G4 had less RAM than that. But I think it's a mistake to jump to the conclusion that these apps should be written in a native framework rather than a web view. Slack is doing much mo…

Does Slack actually render any externally-provided HTML?

Last I checked, they had full control over all the rendered content, including the snippets that show up when you paste, say, a YouTube video. They do use HTML UIs here (e.g. the embedded YouTube player), but is this stuff coming directly from the upstream source or from Slack? I would hope the latter. After all, it seems you can paste a direct link to a video file (e.g. .mp4), and Slack renders its own video player.

I never understood why Slack didn't spend their many billions of cash rewriting the desktop app with something like React Native. Even if they do need to render third-party snippets, they could still embed web views for those instances, which should hopefully be in the minority.

Re: Migrating Slack's Desktop App to BrowserView

#29

Post by rosser »

rosstex wrote: post #27
nerpderp83 wrote: post #19

Earlier quoted context omitted.

You are making a false assumption that more features is something like geometripential in the amount of memory it should use. It is a list, with some images. They have Rubegoldberged themselves into some Sisyphusian box of poo while they expect us to row the SS Honeybucket to work and back. You know what my solution is for when I need to slack? I RDP to a VM running Slack. Mother of Lord! How about Slack sell lil USB…

> geometripential please define this new word

Guessing: Between arithmetical and exponential? Geometric/multiplicative?

Re: Migrating Slack's Desktop App to BrowserView

#30

Post by deedubaya »

I'm a proponent of Electron for startups just getting off the ground with cross-platform desktop apps.

Slack has raised some serious capital, however. The desktop app is the cornerstone of their product and performance is a known pain point (cpu/memory). Why haven't they left electron in the dust and taken performance seriously?

Post reply on HN