Live data from Hacker News

Migrating Slack's Desktop App to BrowserView

slack.engineering

171–180 of 214 posts

Re: Migrating Slack's Desktop App to BrowserView

#172
post #157

Earlier quoted context omitted.

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.

Many mobile apps do rely on web views. Think about it, it's already difficult to make Android and iOS apps look similar. You need devs for both platforms. Teams are already squeezed supporting web (4 browsers with their own quirks), mobile web (screen size matters), mobile native (android and iOS) without also having to spread their talent thinner across completely native desktop experiences in Mac, Windows, and Linux. It's too bad Java never did live up to that write once, run anywhere promise...but that's the world we live in.

Re: Migrating Slack's Desktop App to BrowserView

#173

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…

I understand that 800MB for a chat client is a lot, but don't devs have lots of RAM to spare? I run about 20 apps at any given time + background process which I haven't counted, and I never run out of RAM (8GB).

It's a problem, but is it an actual problem..?

Re: Migrating Slack's Desktop App to BrowserView

#174
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 align look of web and desktop

This is what I don't want, I want it to look like every other desktop app, I want to be able to set the theme of my OS and have every app adopt it, I don't want every piece of software thinking it's special and looking different.

> Harder to work with than CSS.

What native technologies have you used? Many are easier than css+html and look native by default.

Re: Migrating Slack's Desktop App to BrowserView

#175
post #157

Earlier quoted context omitted.

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

Many mobile apps do rely on web views. Think about it, it's already difficult to make Android and iOS apps look similar. You need devs for both platforms. Teams are already squeezed supporting web (4 browsers with their own quirks), mobile web (screen size matters), mobile native (android and iOS) without also having to spread their talent thinner across completely native desktop experiences in Mac, Windows, and Linu…

But we are talking about Slack and they can get this talent. New Skype for macOS is also made with Electron despite Microsoft having a ton of resources and even the old native Skype client for Mac (v7.x and earlier).

Meanwhile, Doist is a smaller company but they made Twist[0] clients native because they care about their customers.

[0]: https://twistapp.com

Re: Migrating Slack's Desktop App to BrowserView

#176

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

> Hint: most are not obsessing over TOP, Activity Monitor, or whatever your OS uses.

Most users think their computer is broken, or they have a virus, or something along those lines because the perceive how slow their computer is but they don't have the knowledge to place the blame where it belongs.

Re: Migrating Slack's Desktop App to BrowserView

#177

Earlier quoted context omitted.

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

does video always on? This is just WebRTC and it is not using 500mb of RAM while idle. Integrations? They all are constantly keep something in memory? Most of this logic is done on the server and app is just a mirror of a server state.

Re: Migrating Slack's Desktop App to BrowserView

#178

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.

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.

I paid for Sublime Text because to me it's better than the editors you mention.

I rather put money towards responsible developers than contributing to the waste of more computing power and more electricity than Bitcoin wastes, while doing basically nothing over what Sublime Text can do.

I mean, if there were no other way to code a text editor I could accept the idea of Atom. But with faster alternatives, it is just an exercise in consumerism. Wasting computing power for the sake of wasting computing power.

It's the rolling coal of computers.

Re: Migrating Slack's Desktop App to BrowserView

#179
post #43

Earlier quoted context omitted.

Wow, that's crazy. The iOS Messages app is native. I'm only familiar with iOS development... is AppKit that bad?

UIKit is noticeably better than AppKit but I doubt this is the reason why Messages is webview based. I don't know the exact reason behind it, but my guess is that they stopped caring about updating it when the people working on it either left or moved over to other projects.

I've taken that same guess after the new fancy effects and animations for iMessage got fully implemented in iOS 10 and barely supported at all in macOS Messages. It seemed like an afterthought on the Mac.

Re: Migrating Slack's Desktop App to BrowserView

#180

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…

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

I mean I’m not recommending it for production, but wasm is right around the corner, perhaps C# Xamarin on the web is closer than we think.
Post reply on HN