
Our Quest for Faster Boot Times and Offline Support - rossharmes
https://slack.engineering/service-workers-at-slack-our-quest-for-faster-boot-times-and-offline-support-3492cf79c88
======
royjacobs
So, on the one hand we've had this discussion here a ton of times: People are
using Electron because it means faster shipping, easier cross-platform
development, and so on. But on the other hand, the amount of hackery in
Slack[1] that needs to happen just to get a level of performance and memory
usage that comes within the ballpark of a native application is so high that
it begs the question: At what point does the amount of work needed to get
basic levels of performance negate the initial gains of building the
application using a tool like Electron?

I'm not trying to troll and say "Electron bad" btw, I'm genuinely curious.

[1] See also: Optimizing VSCode, for instance:
[https://code.visualstudio.com/blogs/2018/03/23/text-
buffer-r...](https://code.visualstudio.com/blogs/2018/03/23/text-buffer-
reimplementation)

~~~
cjblomqvist
Albeit there are most likely a lot of "hackery" needed due to using
Electron/web tech to get the optimal performance, this article is about
architecture and how they originally did not build an architecture to support
this and how they now needed to re-think that in order to get the startup
performance they now desire - a situation you probably (likely?) could end up
in using other technologies than Electron/web.

The high velocity web tech landscape and a startup (velocity) mentality are
more likely the reasons why this was not made originally (most likely a good
trade off, in particular the startup velocity argument). I'm a little
surprised a community like HN don't see this, and rather bash Electron being
the devil of all things (as some comments seem to imply). We should rather
commend Slack for (obviously) making a decent tech choice (using a perspective
where what really matters to them; rapid growth, is/was the first priority
above all else, including "technical excellence").

~~~
royjacobs
It seems to me that the reason this architecture is needed is because the
original choice of technology necessitates it.

I mean, it's not that a C++ application wouldn't need a rearchitecting for
startup performance, but it would likely not be needed for an application as
simple as Slack.

~~~
jlmb
I’m curious: why would you consider Slack to be “simple”?

I see Slack as an incredibly full-featured app. As always, many people might
not use _all_ the features, but that doesn't mean that nobody does…

~~~
royjacobs
I'm comparing it to applications that may have somewhat more reasons for slow
startup times, like mentioned below in the thread (think: Photoshop, Maya,
Unreal Engine, etc). Not a chat application.

I'm not saying Slack is not full-featured, but it's definitely not on the same
scale as some of these other applications.

~~~
jlmb
Maybe, but I would actually argue with the assumption that an image editor is
somehow inherently (allowed to be) “more complicated and/or slow” than a
productivity app.

Or, more simply: Slack (and other similar products) are not just “chat
applications”.

~~~
royjacobs
No, they're certainly not just chat applications, but if you think that
Photoshop is an image editor that is somehow at the same level of complexity
as Slack I'm not sure what to tell you. We'll have to agree to disagree!

------
choeger
> Using a CDN-cached HTML file, a persisted Redux store, and a Service Worker,
> we were able to boot a stripped-down version of the client in less than a
> second (at the time, normal boot times for users with 1–2 workspaces was
> around 5 seconds).

Money quote right here. That is the price we all pay for the bloat in modern
software development. Just because slack is either unwilling to, incapable of,
or forced not to develop a true native version for let's say 8 different
platforms, they are using an architecture that wastes insane amounts of
resources and time.

~~~
flohofwoe
Not trying to defend Slack or Electron here, but it's definitely not the case
that native applications automatically start faster.

Otherwise splash screens wouldn't be a thing, and those existed long before
Electron (for examples of very long startup times, see Visual Studio,
Photoshop, Autodesk Maya, Outlook, etc... the list goes on and on). And all
those applications have slow UIs and eat tons of RAM too.

The actual question is of course, why does something as simple as a chat
client has to be so complex. Is a complete browser engine really necessary to
embed images and videos?

~~~
gtirloni
_> The actual question is of course, why does something as simple as a chat
client has to be so complex. Is a complete browser engine really necessary to
embed images and videos?_

If you keep adding features, at some point you're going to re-implement a
browser engine from scratch. So why not start with one in the first place?

~~~
coldtea
[https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it](https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it)

------
threeseed
Slack truly amazes me.

Here is a company that's entire reason for existence is to provide a great
chat experience. And yet they can't be bothered to build native apps.

At least a dozen times a day Slack will freeze for at least 15s on my 2018
MacBook Pro. And this is with the current and beta versions. Unacceptable.

~~~
gnur
Supporting 3 platforms (Linux, Mac and Windows) basically means triple the
development effort. Off course slack would love to have native apps for all
platforms, but apparently it's just not cost effective. 90% of the users
probably don't even know what electron is, and even for those that do, it's
probably safe to say that the performance benefits of a native application
don't outweigh the the negatives of using something else then 90% of the
company/community

~~~
orbifold
Telegram is able to do this just fine.

~~~
malinens
with much less $$$

------
AriaMinaei
I can write a long list of reasons why Electron is bad for performance.

Having read this blog post though, I can see none of those reasons apply to
Slack.

The kind of performance optimizations that they're calling "a radically
reimagined desktop client architecture," are actually basic engineering
practices that apply equally to all development platforms.

> Using a CDN-cached HTML file, a persisted Redux store, and a Service Worker,
> we were able to boot a stripped-down version of the client in less than a
> second

None of these are specific to the browser or Electron. For example:

> a CDN-cached HTML file

Assuming the HTML file simply points to the styles and the scripts (i.e. no
content-related markup), I am surprised that they weren't already caching it
on the client and the server. Without caching the HTML file, upon boot,
everything has to wait until a meaningful chunk of that file is loaded.

What happens in a regular native setup is that what functions as that minimal
HTML file is already bundled into the app's package and is always read from
disk.

> a persisted Redux store

There is nothing radical about this. Storing part of the application state on
disk and re-hydrating upon reload is standard practice. And again, not
specific to the browser or Electron. On iOS (and I'm sure on Android), models
can be decorated with a persist/re-hydration mechanism. In fact, having this
redux-style single-source-of-truth state object makes it even easier to
serialize the state to disk and read it back.

In fact, not a single optimization mentioned in the article is specific to the
browser or Electron. Slack is not slow because of Electron. Slack is slow
because of Slack. They could've written it in assembly, and without these
basic optimizations, it wouldn't have run much faster.

ps. I'm not trying to bash on the engineering team though. I'm certain they
had other priorities, being a hyper growth startup and all. I cannot say that
I would've done differently under those same constraints.

------
Dunedan
> However, a typical Slack customer may boot just once each morning and could
> find themselves perpetually a full day’s worth of releases behind (we
> release new code multiple times a day).

> […]

> We still want users on the latest possible version so they receive the most
> up-to-date bug fixes, performance improvements, and feature roll outs. Soon
> after we released the new client, we added registration on a jittered
> interval to bring the gap down. If there’s been a deploy since the last
> update, we’ll fetch fresh assets ready for the next boot

Great. So additionally to wasting CPU and memory Slack is now also wasting
more network bandwidth than before.

~~~
cosarara
Multiple releases a day? How is that reasonable?

~~~
joquarky
Some companies have multiple releases per /minute/. They have likely invested
heavily in a very comprehensive CICD system.

------
KaiserPro
The amount of time and money pushed into basically creating a JS version of
QT, we could have had a native client, that isn't workaround bloat?

~~~
de_watcher
How far will people go to avoid learning C++? Trust me, C++ isn't that scary.

~~~
andybak
I really hope our choices don't consist of merely "choose between Electron or
C++". There's surely reasonably performant languages and frameworks with a
more pleasant developer experience than either.

(considering where the bottlenecks probably are I doubt that the language
itself is the problem - it's wrapping a browser that is. Even Python/Qt would
probably be performant enough in this context)

~~~
de_watcher
Language isn't the direct performance problem indeed. It's the choice of the
whole stack that depended on the language.

------
pkorzeniewski
I've noticed that their web client is getting worse and worse, sometimes it
loads messages just to reload (with a force_cold_boot param or something like
that) them again, other times it shows the "new messages" bar even though I've
already read them or doesn't scroll to the last message, not to mention that
it usually takes several seconds to load a channel on a new computer... It's
just not pleasent to use, I can't believe that 20+ years ago we had IRC
clients that worked so much faster that this "modern" chat.. Sure there are
many features on the Slack that IRC is missing but still the major one is
simply messaging

------
lwansbrough
How about a quest for dark mode? Slack recently went out of their way to
provide custom notifications on Windows which explicitly ignore my preferences
where a dark, Windows-style notification once appeared.

------
prennert
It would be great if slack would also work at bad connections. I always feel
like I just want to see the text someone just sent me and text should be
available reasonably fast even when the network reception is bad. Particularly
if the text has already been pushed via a push notification. I would just like
to view it without loading a lot of things around when I click on it.

------
fnord77
it seems with each new release they add-on more and more useless UI elements
and embellishments, I guess the UX equivalent of "chart junk".

~~~
Nextgrid
I hate the new “Drafts” feature with the passion of a thousand suns.

I select my recipient in the sidebar towards the bottom, start typing, then
quickly switch to another channel to check something out, then want to switch
to the recipient again to finish typing my message... it’s no longer there. I
waste 10 seconds before I realise the recipient is now in the “drafts”
category all the way _at the top_.

Which moron thought this was a good idea? I can’t think of any use case where
this “feature” is actually beneficial.

~~~
ivanbozic
I don't have the same vehement hate you do, haha, but I can agree that the UX
here is bad. On desktop, I usually switch between users and channels using the
Quick Switcher (⌘+K) so don't really have to dig through the sidebar, but I
have noticed it on my tablet and it annoys the hell out of me.

One simple tweak to that would be to have that specific user at the top in the
_Drafts_ section, but also leave the user in the _Direct Messages_ area as
well.

------
F117-DK
Great read. Though a bit unclear if using stale assets while updating? Guess
that could speed it even further.

------
Shorel
Meanwhile, this is actually fast:

[https://cancel.fm/ripcord/](https://cancel.fm/ripcord/)

Found here
[https://news.ycombinator.com/item?id=19617699](https://news.ycombinator.com/item?id=19617699)

------
The_rationalist
I would like to debunk some myths around electron (chromium performance) vs
"native" performance.

If we talk about desktop, native means everything and nothing. Originally
native means the GUI(s) that are shipped by default on an OS. There are also
cross platforms GUI(s) like QT or GTK, they're not native and native is not an
intrinsic quality _per se_ it's a limitation (not being cross platform) and
one could say it is better "integrated on the OS" but in practice that doesn't
mean a lot (actually people are _far more_ used to web UX than the native
default UX (which is inconsistent between their own devices (Android vs
windows mainly)))

The default GUI themes from e.g GTK are not flexible enough and modern enough
for a startup.

So let's compare GUI(s) that allow customizing UX Let's debunk the performance
myth: Native or cross platforms GUI(s) are less performant than
chromium/electron on a number of metrics The most user facing performance
metric is rendering performance. GTK use Cairo, QT has it's own renderer, many
smaller native GUI(s) use worse or equal renderer. Chromium develop and use
Skia (tuned for the needs of chromium) Skia is by far the fastest, mature 2D
renderer (but I have hope in a fastuidraw backend from Intel), GTK and QT
renderers are often ridiculously slower. Rendering performance is not only
tied by that. Vsynctester.com show that chromium has great support for low,
consistent latencies. QT and GTK have not the human resources nor the
expertise to have such a quality assurance and performance. Hardware makers
contribute to chromium, e.g the state of the art NV_path support if you have
an Nvidia card. GUI(s) cannot afford this. Every potential bottleneck in
chromium is decoupled, they parallelize (+ AVX) and make asynchronous almost
everything. They have state of the art scrolling performance. State of the art
networking performance (and will be the firsts to support HTTP3 (for
September) Chromium will in a few releases render every websites using Vulkan
API, no GUI toolkit can catch up. They are also totally rewriting their layout
engine to learn from past mistakes. Microsoft is moving chromium input
handling off the main thread to reduce input latency. Web apis allow
performance control (e.g css containment) and profiling far beyond native apis
(but most don't know about them)

So if chromium has the fastest rendering, scrolling, input handling and
networking performance, why do people think that electron apps are "slow" or
"bloated"

It depends what we talk about: If we talk about Langage performance, yes c++
destroy JS. WebAssembly help but does not catch-up. But electron or CEF allow
to use c++ just fine so this point is moot.

Indeed people won't observe lag on native guis when such guis have e.g gnome
theme where everything is monochrome, there's no complex rendering, no
animation, no responsive layout, etc. If you watched the slack GUI on Gtk I
believe it would lag, but actually GTK has not enough features to recreate
slack.

Let's talk about RAM usage: Not using available RAM is a failure not a reason
to be proud... RAM allow preemption / caching instead of recomputing the same
thing over and over. So if you want to compare chromium vs a GUI toolkit
efficiency: compare the same UX, and look at cpu usage too.

Let's talk about disk usage: Yes it's dumb to download a browser for each
app... It's not a big problem seeing current disk space, and is solved by
Google Carlo. Electron has a prototype for solving this issue too. Using
Carlo, web apps will use less disk space that most other GUI toolkits!

Another potential reason for the misunderstanding come from the usual gap of
skill between say a QT dev and an electron dev. Generally the QT dev (c++) has
a mindset more oriented for performance, optimizations. This is cultural, the
same person could optimize for electron.

The last reason could have been a valid one: Chromium transcend any other GUI
toolkit feature wise which allow startups to express most design, in a
precise, productive way. This has the theoretical downside of having more
complex designs, and more constraints on possible optimizations. E.g a layout
engine cannot make the same Invariant assumptions if it has to handle Right to
left text (RTL). If there was as much dev improving QT there is on chromium, I
have no doubt QT would have better performance because of more possible
optimizations because of less features.

But the reality is, this is far outweighted. I would like to introduce the
important notion of software poverty. What I mean by software poverty is a
software that has a slow development. It's relative, and comparing QT or GTK
to chromium is like comparing USA to Zimbabwe. Gui(s)often have a few 10K
commits while chromium has 850000 commits. This is order of magnitudes
differences! Numbers have not a strong effect on the brain but they should.
The gap will increase even more now that Microsoft joined chromium.

To partially survive, GUI(s) toolkits like GTK or QT, webify! GTK styling is
now made with css via an old webkit... QT QML and styling (modern QT) is made
through the QT web engine (an old chromium).

Finally it is true that electron is not latest chromium, but it's "quickly"
catching up, and many issues attributed to an electron app are due to it being
an old electron, so using an old browser (and yes browsers are awesome since
not that many years)

BTW skia is becoming the default renderer in android 10.

I guess I debunked many myths, any feedback?

~~~
dspillett
_> Let's talk about RAM usage: Not using available RAM is a failure not a
reason to be proud..._

That is rather disingenuous. People aren't complaining about using RAM at all,
they are complaining about using it inefficiently compared to other options.
Your statement makes it sound like using more RAM is in itself a source of
pride. Many of your other points are perfectly valid, but they are
overshadowed a bit by that rather silly one.

~~~
The_rationalist
> _Many of your other points are perfectly valid, but they are overshadowed a
> bit by that rather silly one_

Thank you.

> _they are complaining about using it inefficiently compared to other
> options_

I cannot deny nor confirm that, where is the evidence? For an equivalent UX?

~~~
dspillett
_> where is the evidence_

Evidence of people stating that Electron apps use RAM inefficiently compared
to how they believe "more native" implementations would? All over the place.

Of people giving specific examples? No time to search one out right now but
I've seen many discussions where similar tools written in different frameworks
show Node+Chrome+YourCode to use much more memory than the others, sometimes
with a less responsive feeling UX, while providing a very similar feature set,
so that evidence should be easy to find.

Do you have any evidence of your opposing theory? Applications with the same
feature set where an Electron based version has similar (or, indeed, lower)
memory requirements for similarly performant operation / UX, or a situation
where an Electron based tool manages to provide more functionality with the
same memory requirements?

