When signed into multiple workspaces, each of those workspaces was in fact running a stand-alone copy of the web client inside a separate Electron process, which meant that Slack used more memory than users expected.
Slack’s original UI was built using HTML templates that needed to be manually rebuilt whenever the underlying data changed, making it a pain to keep the data model and user interface in sync. The architecture of the existing desktop app had a number of shortcomings: Despite our best efforts to keep things snappy, it became clear that some fundamental changes would be required to evolve the desktop app and prepare it for the next wave of product development. Additionally, the technology landscape had shifted away from the tools we chose in late 2012 (jQuery, Signals, and direct DOM manipulation) and toward a paradigm of composable interfaces and clean application abstractions. Somewhat predictably, a few internal cracks were starting to show in the desktop client’s foundation. Today, after more than half a decade of hyper-growth, Slack is used by millions of people with larger companies working with more data than we ever could have imagined when we first started. During this period, we were optimizing for product-market fit and in a constant sprint to keep up with our customers as their use - and expectations - of the product grew. The desktop version of Slack is our oldest client, growing out of a period of rapid development and experimentation during the earliest moments of our company.
Still, software codebases have life spans.
And running code knows things: hard-won knowledge gained through billions of hours of cumulative usage and tens of thousands of bug fixes. Time spent rewriting something that already works is time that won’t be spent making our customers working lives simpler, more pleasant, and more productive.
Conventional wisdom holds that you should never rewrite your code from scratch, and that’s good advice.