This weird old tip unlocks running Slack with less than 32GB of RAM

Slack has become an integral part of many working environments. It's flagship product is the extended chat service that aims to improve communication. The enhanced chat application with APIs for integrations with third party tools has seen immense success from startups with a handful of folk to enterprises like Blackberry, Bloomberg and VMWare adopting the communications tool at scale.

The messaging traffic going through this SaaS is incredibly large and the company has been able to keep it's PHP powered backend chugging along fine under huge load reliably with it's tech stack. This is a critical area, because people will abandon a real time messaging plaform that is not… real time. Slack has done a good job scaling it's backend. Judging by popularity the team has excelled elsewhere as well.

A chat platform is only as good as it's client apps. In the contemporary working environment a number of devices are used on and off, and many people expect to be able to access Slack and other services from their desktops as well as mobile devices. Chats are increasingly being used as interfaces to other tools, as casual collaborative tasks like user generated content approvals are done through API driven chatbots.

The corporate chat arena is competitive — both the delivery service and the apps need to be top notch.

Mem's the word

The mobile apps for Android and iOS devices are generally regarded to be of high quality and you rarely hear negative feedback from them. In the desktop things are different. The main issue is the memory use by the clients, something the company itself has paid attention to:

However, these capabilities come at a cost: the desktop client can use a lot of memory. This memory footprint increases as the user signs into more teams, as each team runs in its own webview. More memory usage means worse performance, degrading our customer’s experience of Slack and their other applications.
- Reducing Slack’s memory footprint

The Slack desktop application is created with standard web technologies, with some helpers like Electron and TypeScript. A single user can be a part of multiple organizations (teams or workspaces in Slack lingo) at the same time. Each of these runs in it's own sandbox, a webview that is essentially it's own browser.

These web application instances create a lot of memory overhead, despite Operating Systems like Windows optimising duplicate RAM use under the hood. There are memes on Slack memory use which which is a clear sign the problem is real. It's funny because it's true.

In the article discussing reducing the memory use Slack engineers describe how they addressed this with lightweight versions of their app for teams not in active use. This is a valid option, but there is a simpler way to manage this. In fact, you're using the best available Slack client as we speak. It's called the web browser.

Browsers are able to run tens, hundreds, even thousands of tabs. Where as a consultant you'll spend hours a week watching Slack spinners and cheeky messages when working with a mere 5-10 teams. Opening a team is quick and easy as a tab - you can even dedicate a browser to Slack for separation.

Use the browser, stupid

I can already hear the desktop luddites yelling that they need "all the features"… but really what features need deep OS level integration in Slack? Notifications are certainly something that are key, but hello… the Notification API has been implemented in browsers for years and gives you native system prompts, just like the desktop Slack app does. What about pasting screenshots from the clipboard? No problem.

After some days of using Slack exclusively in the browser, I did find an area where it does not enjoy feature parity with the version running in the Electron wrapper. The teams running in the background do not send notices, as I do not have open in a tab or window. However, this is a problem that has been solved and is widely deployed. If you're a Gmail.com user you might have noticed it's available… offline.

Background threads for web applications come in the form of Web Workers. They are JavaScript apps in their own right that keep running in the context of an URL even when a browser tab is closed. These "threads" can be made to send notifications from teams which are not open in a tab using background sync. Web Workers can work as HTTP proxies and could provide access to cached resources on the go.

Most of the hype around Progressive Web Apps (PWAs) is around mobile devices, but there's plenty in it for desktop users - Microsoft believes so as it's rolling out PWAs for Windows 10 to the Microsoft Store. In addition to Slack, there are many professional application that run in an Electron wrapper. Like with React Native, Electron apps have their uses, but for many things the mundane web browser is just fine.

Of course, not everything is best written in JavaScript (but will be, see Atwood's law). Even some of apps that are best created in JavaScript can benefit from closer OS integration with Electron or something similar. An example the VS Code editor is web tech based, but benefits from tie-ins for accessing local files, etc. But that might be a thing of the past as writing code moves increasingly to the cloud.

So please, go ahead and give Slack a try in your browser to free up some RAM in your computer. If it's not your cup of tea and you want that icon in your desktop, start menu or dock you can go ahead and download Slack. Never mind the rant Slackers, just wanted to say the web is a great app platform today.

Uh-oh, almost forgot to share the the weird old tip: Run web applications in a web browser

- Jani Tarvainen,  27/02/2018