Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Our Quest for Faster Boot Times and Offline Support

slack.engineering

Post reply on HN
Print view View original

31–40 of 57 posts

Re: Our Quest for Faster Boot Times and Offline Support

#31

Post by de_watcher »

Fr0styMatt88 wrote: post #14
de_watcher wrote: post #8

Earlier quoted context omitted.

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

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 l…

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.

Re: Our Quest for Faster Boot Times and Offline Support

#32

Post by de_watcher »

andybak wrote: post #11
de_watcher wrote: post #8

Earlier quoted context omitted.

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.

Re: Our Quest for Faster Boot Times and Offline Support

#33

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

Re: Our Quest for Faster Boot Times and Offline Support

#34

Post by The_rationalist »

choeger wrote: post #3

> 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 de…

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

Re: Our Quest for Faster Boot Times and Offline Support

#35

Post by coldtea »

gtirloni wrote: post #22
flohofwoe wrote: post #16

Earlier quoted context omitted.

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 actua…

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

https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it

Re: Our Quest for Faster Boot Times and Offline Support

#36

Post by non-entity »

de_watcher wrote: post #8
KaiserPro wrote: post #7

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.

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

Re: Our Quest for Faster Boot Times and Offline Support

#37

Post by flohofwoe »

threeseed wrote: post #29
flohofwoe wrote: post #16

Earlier quoted context omitted.

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 actua…

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 ;)

Re: Our Quest for Faster Boot Times and Offline Support

#38

Post by de_watcher »

gtirloni wrote: post #22
flohofwoe wrote: post #16

Earlier quoted context omitted.

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 actua…

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

Re: Our Quest for Faster Boot Times and Offline Support

#39

Post by jlmb »

royjacobs wrote: post #15
cjblomqvist wrote: post #13

Earlier quoted context omitted.

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…

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…

Post reply on HN