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

31–40 of 214 posts

Re: Migrating Slack's Desktop App to BrowserView

#31

Post by gfodor »

plopz wrote: post #22

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.…

Obviously not, clearly the point mentioned just has to do with the macro layout of one or more browser frames. It sounds like they moved from a model like to

Re: Migrating Slack's Desktop App to BrowserView

#32

Post by Klonoar »

saagarjha wrote: post #25
Klonoar wrote: post #12

Earlier quoted context omitted.

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 yo…

Meh, there's often reasons to reinvent a portion of an API. You'd need to be more specific about what you see there that's an issue.

I also pointed out Telegram because people, consistently, in every one of these threads, trot it out as an example of a native chat app (I don't count the Qt version in any of this, because it does not in any way feel native on macOS).

To be honest, I welcome anyone to point out a competing cross-platform chat application that does almost as much as Slack does and doesn't eat up memory.

Re: Migrating Slack's Desktop App to BrowserView

#33

Post by pwnage »

ThrowawayR2 wrote: post #24
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…

> 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 Intel…

You're wrong. Slack is doing much more than Outlook.

Re: Migrating Slack's Desktop App to BrowserView

#34

Post by rosser »

Klonoar wrote: post #32
saagarjha wrote: post #25

Earlier quoted context omitted.

> 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 yo…

Meh, there's often reasons to reinvent a portion of an API. You'd need to be more specific about what you see there that's an issue. I also pointed out Telegram because people, consistently, in every one of these threads, trot it out as an example of a native chat app (I don't count the Qt version in any of this, because it does not in any way feel native on macOS). To be honest, I welcome anyone to point out a compe…

No-one else doing it "right" is not an excuse for anyone to do it "wrong".

EDIT: Leaving aside the question of whether the other multi-platform messaging apps also do it that poorly, and merely running with your assertion to that effect. I have neither the time nor the inclination to gather data on that question.

Re: Migrating Slack's Desktop App to BrowserView

#35

Post by avtar »

amedvednikov wrote: post #18
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…

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.

This sounds promising :) Btw, you have a Gmail icon on your site -- I'm assuming that implies Hangouts support?

Re: Migrating Slack's Desktop App to BrowserView

#36

Post by brightball »

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.

Re: Migrating Slack's Desktop App to BrowserView

#37

Post by zokier »

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 know I'd prefer not to have previews and emojis, but I'm sure my colleagues find them useful.

Of course if we'd use an interoperable standardized protocols instead of walled-garden apps, then your colleagues could have their cake and you could eat yours too by allowing everyone to choose a client based on their preferences.

Re: Migrating Slack's Desktop App to BrowserView

#38

Post by tstieff »

amedvednikov wrote: post #18
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…

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.

One thing that concerns me about any 3rd party chat application is that it's difficult to know if my data is secure. Any thoughts on open sourcing your application?

Re: Migrating Slack's Desktop App to BrowserView

#39

Post by WorldMaker »

gfodor wrote: post #31
plopz wrote: post #22

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.…

Obviously not, clearly the point mentioned just has to do with the macro layout of one or more browser frames. It sounds like they moved from a model like to

More like moving from to open in new browser tab and then working to position the new tab is if it were an .

Re: Migrating Slack's Desktop App to BrowserView

#40

Post by FanaHOVA »

ThrowawayR2 wrote: post #24
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…

> 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 Intel…

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.
Post reply on HN