
When a rewrite isn’t: rebuilding Slack on the desktop - kgraves
https://medium.com/@SlackEng/rebuilding-slack-on-the-desktop-308d6fe94ae4
======
mcguire
" _Conventional wisdom holds that you should never rewrite your code from
scratch, and that’s good advice._ "

Speaking as someone who has done a fair number of rewrites as well as watching
rewrites fail, conventional wisdom is somewhat wrong.

1\. Do a _rewrite._ Don't try to add features, just replace the existing
functionality. Avoid a moving target.

2\. Rewrite the _same project._ Don't redesign the database schema at the same
time you are rewriting. Try to keep the friction down to a manageable level.

3\. Incremental rewrites are best. Pick part of the project, rewrite and
release that, then get feedback while you work on rewriting the next chunk.

~~~
paxys
Your third point is arguing against the premise. A "partial rewrite" isn't a
rewrite. That's the entire point.

~~~
kbenson
At some point a partial rewrite might become a complete rewrite. It depends.
Ship of Theseus[1], etc.

1:
[https://en.wikipedia.org/wiki/Ship_of_Theseus](https://en.wikipedia.org/wiki/Ship_of_Theseus)

~~~
m463
The easy way to fund a new military plane is:

\- remove one bolt and raise in the air

\- slide out rev 30 "parts" from beneath bolt

\- slide in rev 40 "upgrade parts" (fuselage, wings, engines, etc) underneath
the bolt

\- fly "upgraded plane" without a lot of pesky 'new plane" studies

Additionally, in parts of california, how to build a house:

\- find existing house

\- pick a wall

\- remodel everything except for that wall

\- reap tax benefits in your 99.9% new house.

~~~
bin0
That's sometimes a good strategy, but breaks when you do too much at once. See
boeing's recent fiasco where they did basically just that with parts and a
fuselage that weren't really compatible. Metaphor extends: try to replace too
much in part and something will break.

~~~
kickopotomus
I would say the Boeing incident more so favors the counterpoint. Boeing tried
to keep adding features to an airframe (code base) that could not support it.

------
Klonoar
I will consider this benchmark vindication both for myself and the times I've
had to argue as to why Electron isn't the issue, as well as the commentator
from many moons ago who worked at Slack, dropped in here and explained why
Electron wasn't the problem (rather, poor engineering on Slack's part was),
and then was ripped to shreds over it.

In fact I'm sure this comment will bring out native fanatics in force.

At any rate, good for them. Seems like they reengineered themselves to a happy
medium. I can definitely see myself installing it again at some point.

~~~
DaiPlusPlus
I’m still skeptical. The memory usage chart from the article shows only a
slight (10%?) improvement for single-workspace Slack clients, now at around
250MB.

Yes, getting a 5+ workspace client down from ~800+MB to 300MB should be
applauded - but the 250MB floor is still too high.

I want to know what’s in the 250MB it’s still using.

~~~
harryh
_250MB floor is still too high_

Too high for what? Low end desktops and laptops today come with 8GB of ram.
Using ~3% of that for a chat app doesn't seem like a big deal.

~~~
asark
Those memory-bloat apps are never, _never_ only memory hogs. They always come
with an outsize hit to general system responsiveness, always have UI lag, and
so on. These days almost all of them are webtech junk. I still have a few Java
programs with that problem —I've been reading "it's in your head, here's a
proof that it can't be as bad as you say" for like 20 years now and those
folks continue to be wrong in practice—but webtech's even worse.

Which makes perfect sense. If you're operating on more memory than should be
necessary you're gonna be burning a lot more processor/battery than is
reasonable, too.

~~~
harryh
I've been using Slack on the desktop daily since the alpha version. I've never
found it to have UI lag.

I honestly think that most people us use phrases like "webtech junk" are
offended on principle and not because of any measurable difference that
matters to regular users.

~~~
asark
Low-latency UIs that respect user input are amazing. They're just quite rare
these days. I guarantee the difference is noticeable and makes a
difference—look at how everyone liked (and still likes) the UI smoothness and
low UI latency of iOS, for example, and iOS, though probably the current front
runner on this front for popular operating systems, is just so-so at it.

I guess if my principle is that I like my computer to respond quickly and
accurately to my input then yeah, I dislike webtech junk on principle.

[EDIT] as far as it not mattering, everyone I know, including plenty of non-
techies, who has used Google Docs hates it, due to the UI lag. Typing with
that large a delay between keypress and the letter appearing sucks. They may
use it anyway because they have to, but they all complain about how laggy the
UI is, responding to clicks and keypresses.

~~~
snazz
Google Docs on what device? Their iOS apps are famously bad on slower iPads
(like the original Air) but the website with a correctly configured browser on
a reasonably-specced laptop or desktop is very responsive, once it loads. Of
course, I'm not a fan of it myself, but the input lag isn't the reason.

------
acemarke
I know that popular opinion in the Twitterverse is that "Redux is dead", but I
note that both Twitter and Slack just released major rewrites that use Redux
heavily.

I talked about Redux usage stats and comparison with other alternatives in my
"State of Redux" talk at Reactathon earlier this year [0], and my post "Redux
- Not Dead Yet!" also addresses some of these aspects [1].

Also, quick plug for our current focus. I'm working on some tutorials for our
new Redux Starter Kit package [2], and then will be working on tackling
additional functionality to push it towards a 1.0 release [3].

After that, we'll get started on a major revamp of the Redux docs [4] to
improve the learning flow, better organize the content, cover more real-world
usage topics, and teach using Redux Starter Kit as the "default way to write
Redux".

[0] [https://blog.isquaredsoftware.com/2019/03/presentation-
state...](https://blog.isquaredsoftware.com/2019/03/presentation-state-of-
redux/)

[1] [https://blog.isquaredsoftware.com/2018/03/redux-not-dead-
yet...](https://blog.isquaredsoftware.com/2018/03/redux-not-dead-yet/)

[2] [https://redux-starter-kit.js.org/](https://redux-starter-kit.js.org/)

[3] [https://github.com/reduxjs/redux-starter-
kit/issues/82](https://github.com/reduxjs/redux-starter-kit/issues/82)

[4]
[https://github.com/reduxjs/redux/issues/3313#issuecomment-45...](https://github.com/reduxjs/redux/issues/3313#issuecomment-450601554)

~~~
wootie512
What is the goto for web if Redux is dead?

I am not super knowledgeable about all the exact architectures, but I thought
mobile was just starting to adopt the redux architecture vs MVP, MVVM, etc

~~~
api_or_ipa
A lot of people are saying that the new-but-not-really-new React Context API
and useReducer hooks are sufficient to cover redux. My team isn't convinced,
we see immense value because we're big fans of using Redux Saga-- a model that
isn't well covered using Context or hooks, although we do use those APIs as
well when needed.

~~~
RobertKerans
Suspense for data loading seems to cover that side of things quite well in the
experiments I've tried with the current API.

I use Sagas as well though, and Ive found them ok...really easy to test but
feel very heavyweight and clunky; personally, I don't _really_ like the
loading/error state to be handled by Redux: the more years I work on
React/Redux app the more I prefer for a section of an app to be mounted ->
triggering a fetch -> loading, show local loading UI -> {fails, show local
UI|succeeds, dispatch success}. So Redux becomes a serializable normalized
data cache that acts to store the results of disparate API calls and doesn't
care at all much about the UI.

~~~
cozuya
What do you do if multiple components/"pages" that aren't even remotely
connected need access to the results of an API call?

~~~
RobertKerans
The results are in the Redux store. I'm not sure I understand the question,
why and how would multiple components be making the same fetch request at the
same time? With what I'm describing, there is already a common state, if they
just need access to that state they have access to it.

Edit: If you do need to synchronise multiple async updates to that state that
happen in a very short space of time & in an unknown order in a controlled
way, then yeah something like sagas is a solid choice to exert control over
that. But very often the user of the UI is only going to make one request [or
one batched set of requests] -- eg I am working on an RN app at the minute,
and each screen does need to fetch data. So I fetch in the component, it shows
loading etc, then populates the store. If the user cancels what they're doing
(navigate away for example), the component used to fetch unloads and no
dispatch is made.

~~~
cozuya
I meant to reply to the guy above me who advocates component level fetch as
opposed to using Redux sorry.

~~~
RobertKerans
That was me! Component level fetch !== no Redux, that's not what I described;
using Redux does not _mean_ you have to use one of the many libraries built to
wrestle asynchronous fetching into Redux.

I've got nothing against any of them, I've used almost every major one in my
jobs over the last few years. But I (and the person who replied to me) both
seem to feel the same way, that in many cases just fetching in React, in the
component, is all that is needed, let the Redux application deal with
marshalling the resultant state (which it is very good at)

~~~
kochthesecond
I have preferred this method myself when dealing with simple calls (calls that
need no further external information). jumping through 7 files just to find
the API request that gets shipped is slightly insane.

but how do you put the result back in the store? how about displaying a
default failure screen?

~~~
RobertKerans
> jumping through 7 files just to find the API request that gets shipped is
> slightly insane.

The API request is in the file that represents the point at which the API
request is made by the user (previously in a loader component or, now, using a
hook, in future using suspense), so I would say it involves jumping through 0
files, as opposed to several if I move it to redux (the dispatch occurs at the
UI trigger point, then I have to drill through several other layers of
abstraction). In practice there's normally some facade in front of the API to
prefill values and also to make it easier to mock for testing, but if anything
that just makes it simpler as the facade acts as a reference.

> how about displaying a default failure screen?
    
    
       failure && <FailureComponent>{failure.message}</FailureComponent>
    

This is I guess down to a preferred philosophical approach but from my pov
React is a UI library and it's _really_ good at showing conditional UI. Redux
is a state container and is not great for this. I don't feel I want that in
Redux, I want Redux purely to be a reference the state of the data in the app;
loading/req/etc states are not that. Whenever I've moved
error/request/loading/failure state to Redux (ie almost every app I've made
over the past four years before this year) it involves a series of
abstractions to track the current request. Whereas React can do this out of
the box at the point the action is taken: make the request, show some state,
if the request succeeds, dispatch the data to the store and [re]render the
component that displays the data based on the state of the store.

> but how do you put the result back in the store?
    
    
        dispatch({ type: "foo", data: "bar"})
    

And have a component that renders based on props in the store, same as normal.

------
_bxg1
The most interesting details:

\- The first iteration was largely powered by jQuery(!)

\- Every workspace got its own isolated Electron process because they didn't
anticipate multiple workspaces in their initial architecture

Honestly it's amazing they got as far as they did with the above limitations.
Sounds like this rewrite was sorely needed after their phase of rapid growth.
Glad they pulled it off.

~~~
mosdl
They switched to React, which will increase their memory usage and be slower
than pure js.

~~~
untog
> be slower than pure js

There's no way of knowing, without knowing what they were doing previously.
The whole point of React is to leverage the virtual DOM to avoid unnecessary
(and very slow) DOM manipulations. Given the sheer number of things Slack has
on any given page it isn't unreasonable to expect that React will make things
quicker, even if it has a penalty at startup time.

------
oflannabhra
This is great, but that ship long sailed for me. I still use Slack
extensively, but for the past year+ exclusively in Safari tabs. Memory usage
and Energy usage (I'm on a MacBook Pro) have both quartered (or more).

~~~
voicedYoda
For over a year i was running 5+ Slacks in the Electron app, and continuously
noticed how much memory was being hogged up. After some basic research, I
realized that Electron is basically a wrapper of a Chrome instance. Suddenly i
understood where my ram was disappearing to because so many "native" apps
running in Electron were literally just spawning new chrome instances and
gobbling up ram.

I now do my best to keep my website apps running just in Firefox containers.

Electron feels like the last rush of "write once, deploy everywhere" days of
flash and Adobe air. God save us all.

------
mtarnovan
How about a native client? I think it's safe to assume that Slack has the
resources for this.

~~~
throwaway66666
Nobody has the resources for that. Some companies make OSes, and some
companies send rockets to space. Those feats are also powered by thin wrappers
over electron. /s

People seem to forget that C++ and opengl is cross-platform. And there are
projects far bigger than slack, like ffmpeg and OpenCV that have existed for
decades, always had very fast development cycles, with only a subset of the
funding and money that Slack has, and stayed native and close to the metal
forever.

A better answer would be, that Slack has deemed the benefits that would result
from this as not that important. Or that the current team's expertise cannot
handle the task. But they always looking into ways of improving the core
product and experience.

~~~
bendixso
It is telling that the person arguing in favor of native C/C++ has to use a
throwaway account for fear of going against the dominant force of opinion in
our industry. We should be able to have these conversations openly without
wondering if it makes us less employable.

~~~
hellofunk
You shouldn't make assumptions about why someone's account is named throwaway.

~~~
bendixso
Fair point. It's a thought that has gone through my head a few times. There
are places that want you to conform to whatever it is we call "modern"
software development, and I often find myself feeling uncomfortable about
expressing an alternate viewpoint.

There's no conspiracy or anything going on here, and you're right it's wrong
to assume. That's the general sentiment of what I was trying to say though.

------
kup0
I was so hoping that they had dropped Electron.. but nope. At least they’re
focusing on performance, but the achilles heel will always be there.

That said, as much as I dislike Electron, Microsoft has done a fine job with
VSCode, so there are ways to do Electron “better”, even if the “best” Electron
apps are still mediocre compared to native apps

~~~
gilgoomesh
They're proud that they can operate in just 500MB of RAM for an app that shows
scrolling lists of text.

The economics of RAM has changed somewhat but 1990s me is still _appalled_.

~~~
untog
It isn't scrolling lists of text, though. It's user profiles, _rich_ text,
colored code snippets, images, uploaders for both, reactions, contextual
menus, channel lists...

I'm not saying they can't do better, but the app does do quite a lot.

~~~
SquareWheel
Interactive embeds, notifications, inline messages, voice and video calling,
an extensive app API...

------
steeve
I was so happy they had finally gone native.

The disappointment is strong.

On a side note, SBlack, a lightweight slack client is very impressive on
memory usage [1].

1\. [https://www.sblack.online/](https://www.sblack.online/)

~~~
btmiller
How does this work? I thought Slack deprecated their IRC gateway; is this all
API-based then?

~~~
swalladge
> Sblack works exactly like a browser with small tweaks.

Looks like it just wraps the website in this case.

Yes there are clients that use the API. Slack offers a http rest-like api as
well as a websockets realtime api. For example, wee-slack[1] (weechat plugin
for slack) and slack-term[2] (curses client in golang).

[1]: [https://github.com/wee-slack/wee-slack](https://github.com/wee-
slack/wee-slack)

[2]: [https://github.com/erroneousboat/slack-
term](https://github.com/erroneousboat/slack-term)

------
me551ah
For me the gold standard of Chat applications is always going to be mIRC. It
supports a ton of plugins, consumes 10-50mb of memory and little to no CPU.
You could be connected to multiple servers and channels with DCC scripts
running and you still wouldn't notice that it's even running.

Even though Slack is using react now, they are still using electron under the
hood. Which means it can never match the snappiness of a native application
like mIRC.

~~~
anchpop
I don't really understand the hacker love for IRC. It's always been hard to
figure out what level of encryption you can expect, what plugins are supported
on what clients, using it from multiple devices was never a good experience,
you miss any messages sent while your pc was off, very poor support for
searching server history for messages with certain text, sending files can be
confusing, etc. Having a snappy client is cool but it'd be cooler if it
supported half the modern features people enjoy when using chat.

~~~
driverdan
Their comment had nothing to do with IRC. It was comparing two chat clients
and how Slack's Electron version is much worse than a native version.

~~~
anchpop
The native client they were referring to was mIRC, which does much less than
Slack does. A better comparison might be Discord, which performs much better
than Slack and is also written in Electron. VSCode, written in Electron,
performs much better for me than Visual Studio (a native app), but I wouldn't
use that as proof that Electron is faster than native apps because Visual
Studio does so much more

~~~
driverdan
The major differences I can think of off the top of my head are threading,
reactions, voice chat, and history. Voice chat is the only one that should use
significantly more resources than mIRC.

~~~
entropicdrifter
Don't forget screen-share and video chat

------
briandear
Could someone please explain to me why a publicly traded company can’t write
an actual, native Mac (or Windows/Linux) client instead of force feeding the
lowest common denominator approach of React “native?” Imagine the performance
and UI improvements of Slack could write a Swift app using standard Mac/iOS
conventions. React “native” can be a treat approach for resource constrained
organizations, but there is little excuse for a big tech company to shortcut
using pseudo-native cross-platform approaches. For what Slack is, it’s still
terrible when it comes to efficiency and stability. It’s lazy.

------
akstrfn
Switching to ripcord on my laptop was a breath of fresh air. I always wonder
why don't these companies develop proper desktop clients that dont wreck mid
range laptops...

~~~
bmurphy1976
I never heard of ripcord. I just downloaded it and gave it a try. It suffers
the same problems as every single native (non-electron) chat client I've ever
used. Primarily it's hideous and you can't change the UI size uniformly.

As an older dev who's eye sight isn't as good as it was 30 years ago when I
started, it's getting harder and harder to use native apps because the default
fonts are so goddamn small.

Oh sure, you can dork around in the font preferences dialog and change some
things, but there is no option to scale all of the UI (UI => Scale => 120%).
It ends up being a hodgepodge of unreadable small text mixed with reasonably
sized by but poorly styled and colored larger text that's nearly as hard to
read because of the lack of space separating elements. Of course everything
gets more crowded when you increase the size, instead of doing what it should
do and also increasing the space between elements to let everything breath.

In an Electron app, I can Ctrl-+, Ctrl-+ and everything looks great. I have
yet to find a single native app that I use regularly where this isn't an
issue. The only ones that comes close (no surprise here) is Sublime Text.

These problems just don't happen with Electron apps. Electron technology may
be slower than native, but it sure nails UI scaling. I'll take a UI I can
actually see over one that runs more efficiently any day.

~~~
tumult
You can set `QT_SCALE_FACTOR=2` (or whatever) as an environment variable and
the entire UI will scale. But by default, it should be trying to use your
desktop scaling and DPI settings -- you might want to try changing those,
first.

~~~
bmurphy1976
I'm using a mac. QT_SCALE_FACTOR doesn't really help, and most of Apple's
native apps are actually sized appropriately. It's everything else that's a
problem.

Honestly, I think it's an accessibility issue. Most devs are simply used to
the small GUIs, so that's what they build. They don't give it any real thought
or put any actual design effort into it. It's the same with accessibility,
it's not _my_ problem so it's not a problem. And while native GUI's help with
some aspects of accessibility, they don't provide the tools to make scaling
easy and obvious so it doesn't happen.

And that's why people throw fits about software being inaccessible, because
it's literally unusable for them. I'm lucky, I just want everything to be 20%
bigger by default because it makes my life a little easier. Others don't have
that luxury. That 20% can be the difference between being able to use your
software or not.

~~~
jancsika
> Honestly, I think it's an accessibility issue.

Even just focusing on the usability of zooming in a browser-- I wonder how
much even the best Linux desktop environment (or even OSX) trails behind
browsers. Off the top of my head:

* the obvious keybindings (even across browsers?) that are the same for tabs/windows regardless of the content inside them

* in FF the zoom percentage animates itself into existence when you go below or above 100%, then remains viewable and clickable to return to normal

* most of the popular web pages are designed for zooming so that text reflows in a readable manner when zoomed

* when zooming, fonts remain readable without the user fudging around with DPI or rendering settings that no mortal ought to understand

* zoom level and scroll position is remembered in case I click the back button

Well, the desktop doesn't even _have_ a notion of the back button so I'd say
we're already at least a few years ahead of the desktop.

------
bfrog
Well there goes my last hope of ever getting a native slack client in my
lifetime. I miss hipchat often. They had enough sense to make the client
native.

~~~
charrondev
Are you sure HipChat was a native client? At least on MacOS I’m pretty sure it
was some web view. If not Electron, one of the others.

I was very happy when we switched from HipChat to slack.

~~~
guessmyname
HipChat was originally built using Adobe Air (2012) [1].

Then they switched to QT using WebView (2013) [2].

Then they created Stride using Electron (2017) [3]

Finally they created a partnership with Slack (2018) [4].

[1] [https://www.engadget.com/2013/02/14/hipchat-ditches-adobe-
ai...](https://www.engadget.com/2013/02/14/hipchat-ditches-adobe-air-for-a-
native-mac-client/)

[2] [https://techcrunch.com/2013/02/14/with-3500-paying-
customers...](https://techcrunch.com/2013/02/14/with-3500-paying-customers-
hipchat-launches-a-native-mac-client-to-vanquish-the-lousy-adobe-air-app/)

[3] [https://techcrunch.com/2017/09/07/atlassian-launches-
stride-...](https://techcrunch.com/2017/09/07/atlassian-launches-stride-its-
slack-competitor/)

[4]
[https://www.atlassian.com/partnerships/slack](https://www.atlassian.com/partnerships/slack)

~~~
charrondev
Thanks for the context!

I was using from 2017 -> Feb 2019 when we migrated to slack. It definitely had
a webview feel similar to slack. I never particularly noted any memory issues.
I haven't noticed any with slack either though.

For me my top memory consumers end up being:

1\. Docker (web dev servers) 2\. Chrome 3\. Firefox 4\. VSCode 5\. 1Password
6\. Spark 7\. Sublime Text

Even at the bottom of the list they are using 200-300 MBs. Spark, 1Password, &
Sublime Text are all "native" apps so I really don't understand what the whole
fuss is about.

~~~
merb
I don't know which 1 password you are using but my 1password uses two accounts
and sits at below 100mb. lower than slack/spark/vscode and many more apps.

~~~
charrondev
I’m using 1Password 7 for Mac with 6 vaults. Seems to hover around 300Mb.

Spark is a native app right? If it’s not they definitely nailed the look and
feel of a native app.

------
gnicholas
I went to get the update on my Mac, and it shows a new version from July 8.
The release notes say: "Slack is a little faster, thanks to a few small but
important changes". Huh?

This seems to be the right update (4.0.0), but on Slack's website the release
notes [1] show the release date to be July 15. Is this the same version as I'd
get via the Mac update? If so, what's with the press push today (Verge and
others), if this has been out for weeks? Also, why is it described as "a
little faster" and "a wee bit faster overall" (in the web release notes)? Is
it a wee bit faster, or much faster?

1: [https://slack.com/intl/en-gb/release-notes/mac?geocode=en-
gb](https://slack.com/intl/en-gb/release-notes/mac?geocode=en-gb)

~~~
entropicdrifter
The changes that made it faster and use fewer resources have been incremental
for the last year. This is just the last of the modernization updates that has
completely removed the last of the original architecture's source code

~~~
gnicholas
Thanks for the additional background. So will this release improve performance
much for those who have the prior update?

------
ebg13
In their side-by-side memory usage comparison, what the hell is happening on
the left at 6 teams that isn't happening at 5 teams and happening at 3 teams
that isn't happening at 2 teams? What the is happening on the right at 6 teams
that isn't happening at 5 teams?

~~~
mh-
They're buckets, it's 6 _or more_ teams ("6+") not 6.

The only one that doesn't make sense to me is _2 teams_. Unless they had some
specific hack to reuse processes for a 2nd team, how can the incremental
memory usage of that 2nd team be almost nothing?

Thinking about it, though- separate teams were lazily loaded and the usage
behaviors of people with different numbers of teams probably varies
substantially enough to cause these artifacts. e.g. I imagine this is "3-5
teams logged in" not "3-5 teams actively loaded".

(disclaimer: I don't work for Slack, just speculating.)

~~~
ebg13
You're probably right, but, if "6+" means "100 teams", then "6+" is the wrong
label.

------
zeusly
I wonder if they increased their efforts after seeing VS Code (also a complex
Electron app) run fast and memory-efficient.

Before VS Code everyone just accepted Electron's memory bloat, maybe slack
even had plans to go fully native b/c no one thought it could be done
properly.

~~~
doc_gunthrop
> memory-efficient.

Not how I'd describe a text editor that consumes 700MB+ of RAM at any given
time.

~~~
wgoodall01
Replace "text editor" with "IDE," and that 700mb figure doesn't seem so
extravagant.

~~~
flukus
It does to those of use that remember upgrading to (I think) 128MB of RAM to
run Visual C++ 6, it's not like a heap of new features have been added since.

------
0xDEEPFAC
Yikes! The legacy version used up to 2 gb of memory? I guess its good they got
it down to only 1 gb...

For reference AIM 4.2 system requirements was 6mb of RAM and 6mb of disk
space.

------
TimWolla
I already noticed that after the workspace selector looked different Slack was
no longer being regularly killed by the OOM killer. Finally.

------
jpalomaki
Creating native Slack client with the same features as current is not trivial.
Just think all the apps, their embedded UI, voice/video calls.

Likely the only reasoble way to have all this and keep it compatible with the
browser version is to either build on browser or embed a browser in the native
app.

You can argue that all those things are not needed in a group chat, but Slack
clearly feels otherwise. They are building a platform, some sort of groupware
- not just chat.

Check for example the Doodle bot demo: [https://slack.com/apps/AFA5VQJKX-
doodle-bot](https://slack.com/apps/AFA5VQJKX-doodle-bot)

~~~
matchbok
Well, that's the problem. It does too much, poorly.

------
electronstudio
Is it still an Electron app? The only reason for using Electron is surely
because you don't have the manpower to develop a proper native app. But then
how have you got the manpower for a rewrite?!

~~~
BinaryIdiot
Yes. The biggest change here is moving away from direct DOM API usage to React
and not having multiple instances of a browser window inside of electron.

Considering this took _two years_ it's kinda incredible they couldn't rewrite
it natively in that amount of time or less. I'm guessing the only reason this
took two years is due to the incremental approach they initially took.

------
zerr
Just hire proper native desktop developers (e.g. C++) and do another rewrite.

~~~
saagarjha
Slack’s library that they share between their mobile apps is written in C++.

~~~
zerr
That's great (and an obvious choice), but I mean the proper native desktop GUI
app.

------
kndjckt
Give me Grammarly and Dark Mode and then I'll stop using the browser version

~~~
dewey
I'd rather not send my keystrokes to two companies at the same time.

Not sure they changed that but this is always at the back of my mind when I
see someone use Grammarly via the browser extension:

[https://techbeacon.com/security/grammarly-leaks-
everything-y...](https://techbeacon.com/security/grammarly-leaks-everything-
youve-ever-typed-service-everything)

~~~
kndjckt
Excellent point :/

Is there a security-conscious Grammarly alternative?

~~~
jamesponddotco
I use their macOS application instead, and make sure not to type anything
sensitive. Not as easy as using their browser extension, but it is safer.

Been trying Language Tool as well:
[https://languagetool.org/](https://languagetool.org/)

Not nearly as good as Grammarly, though, but it works with more languages and
even has a plugin for vim.

------
jupp0r
> 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.

With that being said, can we please have dark mode now?

------
pixelbath
Good news for the Slack team, as this means they'll no longer be the poster
child for "look how bloated Electron apps are! Slack takes up _x_ gigabytes of
RAM!" Great work, Slack team.

~~~
mac01021
I can still say "Look how bloated Electron apps are! Slack takes up half a gig
of RAM!".

------
stephen82
I guess they need to invest some time to experiment with QuickJS[1] so they
can produce a binary executable and check how well it performs and how much
memory it consumes on any system. I'm really curious about it!

[1] [https://bellard.org/quickjs/](https://bellard.org/quickjs/)

P.S.: Yes, Fabrice Bellard did his thing again!

------
bredren
This must have been a forgone conclusion--but was there never consideration of
writing this natively for MacOS / iPadOS?

------
vasilakisfil
With all this amount of profit and market share they should be more eco
friendly and write a native client instead.

------
Sodman
I've noticed that the browser version of slack has been crashing increasingly
frequently in recent weeks, I wonder if this is because of their "Run the
entire old + new systems in parallel" approach? Got the "modern-only" update
today and it seems much more stable!

------
dstaley
The post doesn't say, so does anyone know if the new React version is also
available on the web?

~~~
methyl
I see the new interface (mainly chat input) and notification that Slack just
became snappier on the web.

------
vzaliva
I hope they will do a decent Linux port. For example, maximum font zoom was
limited by 150%. It does not allow to zoom more than that. On 13" screen with
3840x2160 pixels it is not enough. Fonts are too small to read comfortably.

------
JustSomeNobody
It isn't _just_ about memory, though that's a big issue with Electron apps.
It's still running probably a couple orders of magnitude more instructions per
operation than an equivalent native application.

------
wanone
The sheer amount of salt in the medium comments because of Electron is
astounding. Never had any memory hog issues with Slack. Have been using it
extensively for over 2 years now. Works fine on my 2010 laptop as well!

------
viraptor
It's not clear to me from the post - did they do the same changes on the
website version? Should I expect the same improvement there, or are those
completely separate implementations.

------
brailsafe
Gitlab is approaching rewrites in sensible way. Slowly replacing discrete
components of jQuery / rails views with Vue components, but only if necessary

------
royge
I am expecting that they'll rewrite it into a proper native desktop client. :(
Anyway, I'll just use the browser version.

------
charlieegan3
I got this update in the browser, does anyone know what happened to the
subdomains? (e.g mycompany.slack.com)

------
riston
There's a lot of discussions that Slack should go for a full native
application. Yes memory/CPU usage would be much smaller but then again this
cross-platform maintenance hell begins. You can look at Skype's example it
didn't end well, Linux version was lagging totally behind, also Mac client
wasn't up to date and now Skype also released web client :D.

------
adiM
After this update, slack stopped working on Opera. Anyone else has the same
problem?

------
buboard
So this is another javascript "native app". Why not just keep the website?

------
rob74
Hmmm... trying to optimize their Electron app is nice, but how about a real
desktop app instead of a heavyweight browser engine masquerading as one? Would
be really nice, especially for an app you have to have running in the
background the whole time. But the chances for that are slim, I'm afraid...

------
k__
I hoped the go for Revery.

Would be cool to see a native Reason app from such a big player :)

------
ausjke
so this new Desktop app will run inside a browser? or it still uses Electron
underneath? It's unclear to me after reading the post. It's certainly not a
native app though.

~~~
_bxg1
You're correct about what "native" means; the article never uses the word
"native", though. This is still an Electron app, just a vastly improved one.

~~~
ausjke
thanks. realized the native is from a comment and just updated, so this is an
improved electron slack desktop app then.

------
nottorp
They say React. How is this a desktop app? It's still in a browser.

~~~
pwinnski
Electron makes it a desktop app. That part has not changed.

~~~
nottorp
Just because you don't see the browser it doesn't mean it's not still there.

No, js/html "applications" are not desktop apps, they're web pages. Doesn't
matter how you hide it.

~~~
paxys
If an app is running on its own and not in a web browser, it is a desktop app.
The language or framework it is written in does not matter. Do you consider VS
Code a web page as well? What about Spotify?

~~~
lpcvoid
Actually, yeah, I would argue that specially Spotify is simply a website
bundled with some chromium.

------
nik736
So for people who only use one team nothing has changed?

~~~
_bxg1
They also reworked their whole codebase to use React instead of jQuery, among
other things. Please read the article before commenting.

~~~
nik736
I read the article, but for me as a user it doesn't matter at all if the
client is written in jQuery, plain javascript, React or some new shiny
framework. Memory usage seems to be the same, as long as I don't feel any
performance difference nothing has changed.

~~~
_bxg1
They also talked about a different loading strategy which will gradually
request content as needed instead of doing it all up-front, dramatically
decreasing time-to-first-interaction.

And code quality has a huge impact on user experience in the long run. Writing
it off as a non-factor is laughably ignorant.

------
Despegar
Slack is eventually going to write native apps once they realize that
productivity software shouldn't be developed like an ad product from Google.
It will take Teams winning because it gets included in the Office 365
subscription for several quarters before they come to the realization that
they need to compete on user experience.

~~~
basch
an electron app (teams) beating them will lead them to the conclusion that
they shouldnt use electron?

I mean, I agree, losing mass marketshare SHOULD lead to a major shakeup on
trajectory, and competing on desktop user experience would be a logical next
step. But... back to the first sentence of this comment.

~~~
Despegar
Teams is winning because it's being bundled with Office 365. The business
model and distribution lets them compete effectively with an inferior product.
Slack doesn't have that luxury.

~~~
Guillaume86
Teams is so inferior I'm not sure they compete for the same market, when team
chat become really important Teams is just not an acceptable option in my
experience (we had to switch away from Teams last year because there was too
many bugs/frustrating issues and basic features missing, like a actually
usable search feature).

~~~
basch
its about momentum though too. your point in time experience is quite
different than the trajectory/velocity of the product, and its rate of change.

------
pwinnski
"We acknowledge that nobody should ever rewrite from scratch... but after five
years we're rewriting from scratch because we know better."

~~~
bdcravens
It’s an iterative rewrite, which is how you should do it. “Rewrites are bad”
refers to a blank slate and reimplementing.

~~~
pwinnski
I didn't choose the framing, they did.

Here are the first sentences of the first two paragraphs:

> Conventional wisdom holds that you should never rewrite your code from
> scratch, and that’s good advice.

> Still, software codebases have life spans.

~~~
bdcravens
Yes, those sentences set up the rest of the article, establishing the thesis:
Those two sentences are true, and not necessarily at odds with one another.
The author spends the rest of the article explaining this, and how they
accomplished it.

------
djsumdog
So big re-engineering rewrite .. and they're still going with electron? I
mean, I guess it's good they're getting memory usage down for multiple teams,
but other than that, it still seems like a bad start.

I realize native apps on the three big platforms is difficult, but they're not
using any native components what-so-ever. It's their web interface in a
window. They could have used existing toolkits like QT, Gtk or something else,
themed them to look like the Slack we're familiar with, and ditched the
electron bloat.

I've tried to write a couple of prototypes in electron and have worked on some
electron projects and I just don't see why people are flocking to it. Every
tutorial is based around huge amounts of boilerplate or scaffolding, and unit
testing always seems to require weird freaky hacks with modules.

I mean I guess if it works for them, good on them, but I'm still not going to
take this as a sign to recommend or try new projects in Electron.

~~~
fjabre
I think Slack’s web interface is ideal.

I fail to see the need for a slack desktop client.

