1) Being able to switch to it is easier if it's an app

2) notifications become native rather than driven by a browser (which is a preference for some, due to reliability and permissions issues)

3) Browser vs Electron doesn't really change much in terms of performance or resident usage

4) Most people keep these chat programs running in the background, modern browsers are starting to suspend tabs (as they should) which could make the application behave strangely in future.

Not saying I don't do this with Zulip, but I also treat Zulip as "something I'll get to when I can"- like Email, rather than how many people treat Teams/Slack/Discord where it's really leaning on the instant messenger aspect and a much more realtime communication flow.

▲

bagacrap 17 hours ago | parent [-]

> Browser vs Electron doesn't really change much in terms of performance or resident usage

This isn't true?

As to the rest, I simply haven't had these problems. Seem like prioritization issues? The browser is doing a poor job if it's treating a tab that one switches to multiple times a day the same as a tab that hasn't been used in two weeks.

▲

dijit 12 hours ago | parent [-]

> This isn't true?

Heh, I’m not sure why you would think this- there is some sharing of resources for browser tabs but not a lot when you consider the javascript runtimes memory requirement and sandbox isolation features.

Safari is perhaps the best (or worst- depending on how you look at it) for sharing resources between tabs and weakening the sandbox for that, but I regularly see tabs running at over 1.5GiB of RAM (Tab+Renderer in Activity Manager).

It just becomes harder to track if its part of the normal browser, I think. Many browsers don’t show you a true per tab breakdown (firefox doesn’t) and often there are multiple threads per tab making the aggregation difficult (Chrome/Safari to some extent).

Even the “tab resource monitor” extensions and menus that exist only show part of the resources a tab is using, basically its DOM and in memory resources but not its renderer, runtime or other harness’

▲

bagacrap 3 hours ago | parent [-]

why I would think this is because both logic and every online resource indicates that it is true. There are a lot of shared utility processes, binary, etc in a browser. I'm not sure why you wouldn't think it was true, but if you assert that task manager reporting is untrustworthy, I guess we'll never be able to measure. Given how hard Slack is constantly pushing on getting me to install their desktop app, I'm just gonna assume they spend little to no time optimizing the tabbed experience. But that doesn't make me trust them enough to install and run another full browser runtime for a chat app.

Btw, up to the point that my desktop environment actually runs out of RAM, I actually don't care how much RAM is in use. In fact, if any less than the full amount is in use (less some buffer for new actions), I'm probably being underserved. So when a full browser has things like pre-rendering taking up some amount of memory to serve the next link click 0.2s faster, that's a benefit, not something I score against it.

> I regularly see tabs running at over 1.5GiB of RAM

But would they use less as an electron app is what we're debating.

	▲	dijit 3 hours ago \| parent [-]
		Ok, but we could make a test. 1) Launch a fresh browser and open teams and slack - check total system usage, then close 2) Launch Teams and Slack as electron apps - check total system usage, then close 3) Check the system usage with everything closed. Probably the closest to a proper test we'll get. Also, the debate about "unused ram is wasted ram" falls very short when it's storing numbers vs caching documents that are in frequent use. Your choice of using 64-bit double-precision floating point numbers for things that could otherwise be a byte (or a BIT in some cases).. though I know JS runtimes jump through hoops to avoid this in the modern day, those hoops also cause needless computations and overhead. When every object is heap allocated with all the cruft that it entales, when it has no value types or structs, when it needs GC headroom and runtime metadata (for JIT) and when strings are immutable requiring more allocations when "mutating"... and also while the ecosystem builds itself around stuffing as much code as possible into the browser... well... that doesn't provide a lot of value for the user.. Preloading the next page I might click and making sure the files I most access on my disk are in memory already: ARE. Your argument falls short because memory is never wasted if chat programs didn't gobble it all up, it would go to something that the user perceives as higher performance even if it was not used by any application.