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 either, and it's a hell of a lot closer to C# than it is JS.
I'm a big JS guy, believe me, but I wouldn't call a chat app using "only" 800MB of RAM a "win." Sorry to the guys who worked hard on this.
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 better product, it may take over market share. Assuming your users even care about that. Hint: most are not obsessing over TOP, Activity Monitor, or whatever your OS uses.
Otherwise, don't whine. Electron makes it possible to create and ship apps very very quickly. Apps which would not exist otherwise. Every time you remove a barrier, you open up doors for more people.
While spinning up an entire browser for a single app has memory usage implications – namely, the baseline consumption is high, as is download size – the biggest issue is that it is easy to be wasteful when using web technologies. Look at Visual Studio Code, for instance. It's light and nimble compared to alternatives. It's true that a single one of its workers consume as much memory as a whole Emacs instance, but the development pace is staggering. And it still uses less memory than Slack...
Why? Electron apps still have to be packaged for Linux. And cross platform apps can be written in Qt or Java too. Doesn't seem like Electron is the thing making the difference here.
I'd be okay with Slack being sufficient but taking a gig of RAM. Instead it's really shitty and buggy and also take a gig of RAM. Any one of their problems doesn't make it a horrible product, that just the one most often pointed to as indicative of how horrible their engineering is.
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 more than Adium: web previews, document previews, pulling in pre-rendered fragments from the server and modular stylesheets. I wonder how much RAM Adium would have used to do the same things, and I wonder how much time the developers of an equivalent cross-platform app would have spent if they had been split trying to optimise lots of different platforms. They would essentially be re-inventing a modular layout and rendering engine (aka a web browser).
I don't know what the answer is. Maybe the detractors would prefer that the app did less. I know I'd prefer not to have previews and emojis, but I'm sure my colleagues find them useful.
(EDIT: Per reply below, turns out Adium did use a web view for presentation!)
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.
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?
Why should they "take performance seriously?" They probably have a bunch of front end devs who are cheaper to pay and clearly there is support sufficient for them to raise large amounts of capital.
I won't use the desktop app because I have standards. But apparently we're too few in number to matter. And from a business perspective there's nothing wrong with that. Frequently what engineers want and what makes (good business) sense are different.
I think that it's a trade off between features and performance. Are they going to add more customers by making Slack smaller and faster or by adding threaded conversations and other user features? Certainly stability is a requirement, and I see that in the changes they are talking about here. They could allocate a ton of engineers to platform native Slack implementations that would be fast as hell. But would they be able to ship a new feature like threaded conversations to all platforms quickly? What would be the cost? How would that change their presence in the marketplace. Everything is a trade off.
Spending time on problems you wouldn't have to solve if you would choose your tools more carefully instead of following fads, and still coming up with something very far from optimal.
That would be awesome post if it was made as an experiment, to test the limits of Electron, to learn and let others learn, to just play with BrowserView. But seeing this as a technical write-up about one of the very popular chat apps used out there, it's just sad and wasteful.
How about improving boot time? Nobody talks about it, but since Slack uses so much RAM, I like to close it from time to time and open it when I feel like getting distracted.
But then, it takes 30 seconds (!) from opening the application to being able to type the first message. There is no other app on my MBP that needs so long, and we're talking pretty new hardware with SSD and an i7.
Sorry, but I don't care about your portability across different platforms, I just can't. I want the best experience on mine.
On a related note, for an app I have open all day long but interact with on an event-driven basis - Slack's UI is just too darn big. I miss the days when the only chat UI was a small column (eg. ICQ).
Yeah, it's really wasteful of screen real estate. In a way that's worse than high RAM usage because I can spare 1GB of RAM if I really have to (and I can upgrade RAM easily enough if I can't spare it). But if an app takes up 1/4 to 1/3 of the width of my monitor, there's not much I can do to change that.
Though at least there is a workaround: put it all the way to the right, then let other windows obscure the rarely-needed left portion of the Slack UI.
I think Slack tries to mimic IRC more than ICQ, and all IRC clients I know had big windows, because they assumed you want to see what's happening on the channel at all times.
On macOS, web app wrappers created with Fluid (http://fluidapp.com) consistently use less resources than the official Electron-based versions, in my experience.
It's a wrapper for the system-supplied Webkit, so it inherits those benefits from that. I've been experiencing a similar performance to Chrome in Safari 11, but lower RAM/CPU/GPU usage overall.
I used Fluid, now use MacPin. Apps are much smaller, essentially just the size of their JS bundles. But then you're back to cross-browser woes and no native layer.
Really neat to see how Redux's design and extensibility make this kind of action serialization and store synchronization possible. There was another similar example recently where someone was synchronizing multiplayer game states via Redux actions [0]. There's actually quite a few addons available related to store synchronization [1].
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.
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 <webview /> 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.
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?
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 <iframe> to <frameset>
I'm sure this will not fix my 25% cpu core burn on open gifs. Slack is no. 1 reason for my laptop to spin up fans because I left it open with a gif from giphy.
Tried the new beta: it lost all my configured networks, and I had to re-add them all. Otherwise, it seems _way_ faster than the old one, and definitely an upgrade.
I am wishing that the devs on the HipChat desktop apps are paying close attention to this. The Slack desktop app has been a resource hog, but nothing compared to the HipChat desktop app. (All anecdotal evidence)
Interesting to read Slack proselytize the use of Observables (which I'm a huge fan of). I really wish TC39 would move it to stage two. I found the following discussion/ reasoning pretty lacking for the amount of use Observables are getting.
[+] [-] lwansbrough|8 years ago|reply
I'm a big JS guy, believe me, but I wouldn't call a chat app using "only" 800MB of RAM a "win." Sorry to the guys who worked hard on this.
[+] [-] brightball|8 years ago|reply
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.
[+] [-] outworlder|8 years ago|reply
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 better product, it may take over market share. Assuming your users even care about that. Hint: most are not obsessing over TOP, Activity Monitor, or whatever your OS uses.
Otherwise, don't whine. Electron makes it possible to create and ship apps very very quickly. Apps which would not exist otherwise. Every time you remove a barrier, you open up doors for more people.
While spinning up an entire browser for a single app has memory usage implications – namely, the baseline consumption is high, as is download size – the biggest issue is that it is easy to be wasteful when using web technologies. Look at Visual Studio Code, for instance. It's light and nimble compared to alternatives. It's true that a single one of its workers consume as much memory as a whole Emacs instance, but the development pace is staggering. And it still uses less memory than Slack...
[+] [-] SteveNuts|8 years ago|reply
RAM is pretty cheap, I'd rather put money towards a better Linux machine than give that money to Microsoft for the OS.
[+] [-] peoplewindow|8 years ago|reply
[+] [-] zeveb|8 years ago|reply
https://github.com/yuya373/emacs-slack works on Linux, and doesn't chew up CPU, RAM & disk to do it.
[+] [-] kentt|8 years ago|reply
[+] [-] LeoNatan25|8 years ago|reply
[+] [-] saagarjha|8 years ago|reply
[+] [-] afandian|8 years ago|reply
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 more than Adium: web previews, document previews, pulling in pre-rendered fragments from the server and modular stylesheets. I wonder how much RAM Adium would have used to do the same things, and I wonder how much time the developers of an equivalent cross-platform app would have spent if they had been split trying to optimise lots of different platforms. They would essentially be re-inventing a modular layout and rendering engine (aka a web browser).
I don't know what the answer is. Maybe the detractors would prefer that the app did less. I know I'd prefer not to have previews and emojis, but I'm sure my colleagues find them useful.
(EDIT: Per reply below, turns out Adium did use a web view for presentation!)
[+] [-] Twirrim|8 years ago|reply
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.
[+] [-] cisanti|8 years ago|reply
Either I'm getting old and grumpy, or it used to be possible in the year 2000 without your computer fans taking off and 1gb of ram.
[+] [-] CreepGin|8 years ago|reply
[+] [-] dmitriid|8 years ago|reply
In 2017 there’s no tech stack that lets you write consistent UIs across multiple platforms. Except, unsurprisingly, Electron
[+] [-] deedubaya|8 years ago|reply
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?
[+] [-] sidlls|8 years ago|reply
I won't use the desktop app because I have standards. But apparently we're too few in number to matter. And from a business perspective there's nothing wrong with that. Frequently what engineers want and what makes (good business) sense are different.
[+] [-] cakeface|8 years ago|reply
[+] [-] raverbashing|8 years ago|reply
[+] [-] WorldMaker|8 years ago|reply
[+] [-] seba_dos1|8 years ago|reply
That would be awesome post if it was made as an experiment, to test the limits of Electron, to learn and let others learn, to just play with BrowserView. But seeing this as a technical write-up about one of the very popular chat apps used out there, it's just sad and wasteful.
[+] [-] iagooar|8 years ago|reply
But then, it takes 30 seconds (!) from opening the application to being able to type the first message. There is no other app on my MBP that needs so long, and we're talking pretty new hardware with SSD and an i7.
Sorry, but I don't care about your portability across different platforms, I just can't. I want the best experience on mine.
[+] [-] CharlieHess|8 years ago|reply
[+] [-] rrggrr|8 years ago|reply
[+] [-] adrianmonk|8 years ago|reply
Though at least there is a workaround: put it all the way to the right, then let other windows obscure the rarely-needed left portion of the Slack UI.
[+] [-] M4v3R|8 years ago|reply
[+] [-] dictum|8 years ago|reply
It's a wrapper for the system-supplied Webkit, so it inherits those benefits from that. I've been experiencing a similar performance to Chrome in Safari 11, but lower RAM/CPU/GPU usage overall.
[+] [-] mikewhy|8 years ago|reply
[+] [-] acemarke|8 years ago|reply
[0] http://jimpurbrick.com/2017/01/04/vr-redux/ , http://jimpurbrick.com/2017/07/04/react-vr-redux-revisited/
[1] https://github.com/markerikson/redux-ecosystem-links/blob/ma...
[+] [-] nartz|8 years ago|reply
[+] [-] nerpderp83|8 years ago|reply
[+] [-] WorldMaker|8 years ago|reply
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.
[+] [-] plopz|8 years ago|reply
So to make electron less of a hog, you ditch the web part?
[0] https://blog.figma.com/introducing-browserview-for-electron-...
[+] [-] gfodor|8 years ago|reply
[+] [-] akhatri_aus|8 years ago|reply
[+] [-] xenadu02|8 years ago|reply
Stop being lazy. You’re not a scrappy startup anymore. Build real native apps for each platform.
Using electron solves your problem. As a user it sure as hell doesn’t solve any problem I have.
[+] [-] therealmarv|8 years ago|reply
[+] [-] forsaken|8 years ago|reply
[+] [-] CharlieHess|8 years ago|reply
[+] [-] hoodoof|8 years ago|reply
Even the TLDR at the bottom didn't succinctly explain the advantage of browserview over the old way.
[+] [-] codereflection|8 years ago|reply
[+] [-] iamatworknow|8 years ago|reply
[+] [-] dcgudeman|8 years ago|reply
http://tc39.github.io/tc39-notes/2017-05_may-25.html#17iiia-...
[+] [-] mmgutz|8 years ago|reply