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

11–20 of 214 posts

Re: Migrating Slack's Desktop App to BrowserView

#11

Post by saagarjha »

wlesieutre wrote: post #9
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…

If I’m not mistaken, the actual chat contents in Adium were rendered with web views, and its configurable message styling was done with HTML/CSS. The whole program wasn’t stuffed in the web view though, it was a presentation layer on top of a native backend. EDIT- here’s a source on that http://meyerweb.com/eric/thoughts/2005/12/19/adium-chatting-...

Yes, this is what the native macOS Messages.app does as well. On my Mac, with relatively heavy usage, I'm at around 100 MB of RAM.

Re: Migrating Slack's Desktop App to BrowserView

#12

Post by Klonoar »

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…

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 Objective C by choice.

Also, to echo your point: yes, the amount of free stuff you get in a web browser would be an absolute nightmare to reproduce in some native code environments (especially cross platform).

The only reason I'm still wary of running any Electron app for long periods of time is because I do end up feeling the same sluggishness that I feel with Chrome open after awhile, and I don't think there's much that can be done about that. With that said... I've been using sluggish apps since the Windows 98 days, this isn't a new concept.

Re: Migrating Slack's Desktop App to BrowserView

#14

Post by wlesieutre »

saagarjha wrote: post #11
wlesieutre wrote: post #9

Earlier quoted context omitted.

If I’m not mistaken, the actual chat contents in Adium were rendered with web views, and its configurable message styling was done with HTML/CSS. The whole program wasn’t stuffed in the web view though, it was a presentation layer on top of a native backend. EDIT- here’s a source on that http://meyerweb.com/eric/thoughts/2005/12/19/adium-chatting-...

Yes, this is what the native macOS Messages.app does as well. On my Mac, with relatively heavy usage, I'm at around 100 MB of RAM.

It clearly works pretty well that way. Textual (Mac IRC client) is the same setup.

Slack, on the other hand, feels like JavaScript frameworks piled three or four deep, often getting its UI out of sync with the actual state.

Chats/channels will briefly flash (1) unread in the sidebar to tell me about my own message that I just sent, or I’ll continue to have a blue “10 new messages” banner in a conversation that I’m actively participating in.

I use it because it’s convenient, but there’s definitely room for improvement.

Re: Migrating Slack's Desktop App to BrowserView

#16

Post by kitsunesoba »

wlesieutre wrote: post #9
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…

If I’m not mistaken, the actual chat contents in Adium were rendered with web views, and its configurable message styling was done with HTML/CSS. The whole program wasn’t stuffed in the web view though, it was a presentation layer on top of a native backend. EDIT- here’s a source on that http://meyerweb.com/eric/thoughts/2005/12/19/adium-chatting-...

Yes, this is accurate. Adium’s message views were almost entirely HTML and CSS with very little JavaScript. The bulk of Adium’s “brains” were written in Objective-C (and plain C, via libpurple).

Re: Migrating Slack's Desktop App to BrowserView

#17

Post by afandian »

wlesieutre wrote: post #9
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…

If I’m not mistaken, the actual chat contents in Adium were rendered with web views, and its configurable message styling was done with HTML/CSS. The whole program wasn’t stuffed in the web view though, it was a presentation layer on top of a native backend. EDIT- here’s a source on that http://meyerweb.com/eric/thoughts/2005/12/19/adium-chatting-...

Well! You learn a new thing every day.

Re: Migrating Slack's Desktop App to BrowserView

#18

Post by amedvednikov »

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…

That's why I'm developing eul, a lightweight native desktop client for Slack, Skype, Facebook etc:

https://eul.im

It's only 4 MB and handles tens of thousands of Slack messages in one chat without lag.

1.0 release is going to be out in early November.

Re: Migrating Slack's Desktop App to BrowserView

#19

Post by nerpderp83 »

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…

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 ARM computers, like a chromebit that just runs Slack? Maybe I could pair them with my Snapchat glasses! Modular, yes you can!

Re: Migrating Slack's Desktop App to BrowserView

#20

Post by WorldMaker »

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

I'm not sure that's the message here. The trade-offs in play aren't "custom bug fixes" but different approaches to a similar problem. In fact, the solution provided (BrowserView) is considered a better solution because it benefits from more "ordinary" browser bug fixes in Chromium and less overall custom work. (Every Chromium developer cares that Tabs work, not every Chromium developers works on or uses Chromium add-ons that make use of the component.)

Furthermore, BrowserView versus WebView isn't even necessarily a concern for every Electron application. It's used for embedding remote (read as web server hosted) web pages. In the Electron apps I've been building, 100% of the code is hosted locally, and I don't have a need to host outside webpages.

Post reply on HN