Our Quest for Faster Boot Times and Offline Support
slack.engineering
slack.engineering
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...
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").
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 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 not saying Slack is not full-featured, but it's definitely not on the same scale as some of these other applications.
Or, more simply: Slack (and other similar products) are not just “chat applications”.
That's the modus operandi of many unpleasant things like bacteria or cancer cells, why should it be commendable on its own?
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.
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.
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?
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?!
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.
But from what I've seen, most Slack channels contain more images, videos and animated emojis than text ;)
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?
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.
Only if you're completely clueless.
EDIT: My coworkers as in my team, didn't ask all 500. :P
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.
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.
> […]
> 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.
(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)
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.
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.
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 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.
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 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?
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.
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?
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?