Hacker News new | past | comments | ask | show | jobs | submit login
Our Quest for Faster Boot Times and Offline Support (slack.engineering)
65 points by rossharmes on Aug 30, 2019 | hide | past | favorite | 54 comments



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


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").


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.


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…


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.


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


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!


Because very very little happens in the client itself. Basically any button that does something is just an api call out to their servers and an update to the view. You can see this yourself when you're working on a higher-latency network connection -- damn near every click gets you a spinner or a pause of some sort before things happen.


>rapid growth, is/was the first priority above all else, including "technical excellence"

That's the modus operandi of many unpleasant things like bacteria or cancer cells, why should it be commendable on its own?


One possibility is that the timing is usefully different with Electron - the products were out and getting traction (and presumably in Slack's case revenue) long before the performance hacks were conjured.

I don't know if the total amount of work over time sums to approach that of a portfolio of native apps, but even if that's the case, there's a world of difference between spending extra time improving a product that's already out in the world and developing the first cut.


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


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?


> Is a complete browser engine really necessary to embed images and videos?

No, but it is a "fast enough", well tested, well supported, regularly updated to address security issues, option that does the job, and the developers are already familiar with many of its ins-and-outs, and when a new display feature is needed it might just already be there.

Any smaller alternative has to compete with all that. Who is maintaining it? With fewer people using it (as it is optimal for specific cases but less useful generally) is there the resource available to support it, and are issues even going to be noticed before you hit them?

Electron is one of those odd things that is probably ideal for nothing, but is good enough for such a huge range of things, and is easily accessible to existing developers, that it quickly gained momentum, then ubiquity, and will likely keep both for some time to come. Not unlike Visual Basic, which was initially seen as prototyping system (my memory of VB1, its packaging and advertising, is that it was marketed as such) but turned out to be "good enough" for production use for many small apps & tools, and was more accessible to less experienced programmers than the other options for development targetting Windows. Similar arguments about its output hogging resources and having large distributables were made back then too: why does your simple calculator, slightly enhanced notepad, & other tools, need a 300Kbyte library to be distributed with each of them?!


You're actually comparing apps like Photoshop and Maya with Slack ?

Of course they use lots of RAM they do lots of complex things.

Slack's only job is to print text on the screen and send text to a remote server. That's it.


I addressed that in the last sentence of my comment.

But from what I've seen, most Slack channels contain more images, videos and animated emojis than text ;)


> 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?



And when you think of the browser as what it is - a VM manager for a weird sandboxed OS, it's all starting to make sense: good old OS wars where the user pays for the damage.


they are using an architecture that wastes insane amounts of resources and time Source? Are you talking about native performances vs electron performances?


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.


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


Telegram is able to do this just fine.


with much less $$$


> Supporting 3 platforms (Linux, Mac and Windows) basically means triple the development effort

Only if you're completely clueless.


I keep reading about people saying this but it hasn't happen once for me or my coworkers (500 employees). Are we too small or what's the difference?

EDIT: My coworkers as in my team, didn't ask all 500. :P


It happens to everyone in my team.

It's related to having multiple workspaces which is common if you work for a large enterprise.

Apparently it's all too much for this glorified IRC client.


I use Slack in a web browser. I have never had any of the issues I've seen others complain about.


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.


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


Multiple releases a day? How is that reasonable?


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


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?


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


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)


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


C++ is great, but I’ve always hesitated in pushing Qt at my employer because I’ve never quite understood their licensing. It seems like it’s really expensive for actual commercial use.

I keep meaning to dive into it to learn it now that my C++ is better, but what stops me there is that I don’t quite get where QtQuick + JavaScript fits in, or what parts of Qt I should be using / putting time into learning. For other languages, I don’t want to use an ‘unofficial’ binding in case it breaks.


Every time Qt is mentioned there is a comment with a licensing question. You don't pay for commercial use as long as you don't want to make secret modification to Qt itself. Paid licenses are for a couple of obscure modules.

QtQuick + JavaScript puts JavaScript into its original place that it had at the times of the old web: oneliners to bind stuff together.

Also there is probably a confusion from Qt having two distinct GUI systems: QtWidgets and QtQuick.


That was my experience creating a small Qt web site archiver/spidering tool. Most of my experience is in Rust, and it was easier to learn a little bit of C++ than it was to try and figure out the binding generators required to avoid C++.


Getting off topic, but what resources do you recommend for learning C++. It seems that half the resources I find are either designed for people completely new to programming (I know basic programming construct, along with OOP) or don't bother teaching stuff like the stl and all these different pointer types


My learning experience was through first understanding how memory and everything works in the C language. To me C++ is not the place to learn programming, it's more like a tool to take some syntax/idea from another more specialized language and then develop an underlying implementation that makes the similar syntax to compile into the specific thing I imagine in C.

It's important to take into account the dates when the learning materials were published. New features change the way how the same thing is done (while keeping the old way still compiling and working). Specifically about the STL there are old books from Meyers. To not get lost in time there is the "C++ Standards Support in GCC" site of the GCC compiler which enumerates all the new features that were added during the post-2011 accelerated development period. The modern C++ has seen no books so it's may be useful to just watch some talks by people who develop the language, standard library, compilers or who have experience in using it: Sutter, Lavavej, Stroustrup, Alexandrescu, Carruth‏, Hinnant, Vandevoorde, Niebler for example.


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


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.


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.


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


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.


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.


If you're on desktop, you can use the keyboard shortcuts to quickly swap between conversations. I don't like the drafts section either, but that has been my only way of coping with it.


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



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?


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


>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?


> 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?


I don't buy it. Slack is, supposedly, a product for professionals (I think the non-professional lunch was eaten by Discord already). Professionals communicating at work would benefit from RAM and CPU being left alone much more than from animations and other fluff.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: