Slack has recently made version 3.0 available in their beta channel, with numerous performance improvements and bug fixes. At its core, most of the changes have revolved around migrating from the Electron component webView to browserView, a newer and more stable alternative. Charlie Hess, engineer at Slack, has published a blog outlining this journey.
Slack is written in Electron, a framework which is used to develop desktop applications using web technologies such as a NodeJS and Chromium. Whilst this technology choice has helped keep Slack cross-platform, it has not been as stable as the team would like. Hess explains that this is mainly down to webView, an Electron feature used for rendering web pages.
One of the main issues with webView was that the component itself is implemented in Chromium directly. This means that bug fixes end up needing to be done by the Chrome team, effectively blocking progress. To get around this, the Electron team introduced browserView, a component which behaves more like a Chrome tab and is part of the operating system window hierarchy. It’s migrating to this which was most of the work for Slack 3.0:
What we mean by that is — unlike the webView — you can’t drop a BrowserView into the DOM and manipulate it with CSS. Similar to top-level windows, these views can only be created from the background Node process. Since our app was written as a set of React components that wrapped the webView, and — being React — those components lived in the DOM, this looked to be a full rewrite.
However, by making good technology choices and design decisions, Hess explains that the rewrite was made as painless as possible, and he estimates that in the end, they were able to retain more than 70% of their original code.
One decision made by the team was to introduce redux-electron with Redux. Essentially, Slack is comprised of many processes, each one containing its own Redux store. Redux-electron uses Electrons IPC (inter-process communication) to share actions between processes, using the main process as the single source of truth and treating the others as proxies.
Another choice made was TypeScript, which Hess states as something which brought major benefits through the project. Now, in the case of a major refactor, the type checking has helped avoid many bugs which would have not otherwise be detected:
Never again will you ponder over the output of a flatMap (do I get the array or just one item?), the argument order for a reduced, or the name of that one operator that’s like throttle but starts with a D… (it’s debounce). When coupled with autocomplete in VS Code, writing JavaScript feels a lot like writing, say, C#. And I mean that in the nicest way possible.
Finally, Hess explains that Slack uses redux-observable, and RxJS 5-based middleware for Redux. It essentially brings reactive programming to Redux via an epic primitive, a function which takes and produces a stream of actions.
The full blog can be read online, going into more detail with code examples. Furthermore, the latest version of Slack can be download on the beta channel.
