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

11–20 of 57 posts

Re: Our Quest for Faster Boot Times and Offline Support

#11

Post by andybak »

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.

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)

Re: Our Quest for Faster Boot Times and Offline Support

#13

Post by cjblomqvist »

royjacobs wrote: post #4

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

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

Re: Our Quest for Faster Boot Times and Offline Support

#14

Post by Fr0styMatt88 »

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.

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.

Re: Our Quest for Faster Boot Times and Offline Support

#15

Post by royjacobs »

cjblomqvist wrote: post #13
royjacobs wrote: post #4

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

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.

Re: Our Quest for Faster Boot Times and Offline Support

#16

Post by flohofwoe »

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…

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?

Re: Our Quest for Faster Boot Times and Offline Support

#17

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

Re: Our Quest for Faster Boot Times and Offline Support

#18

Post by Kiro »

threeseed wrote: post #5

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.

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

Re: Our Quest for Faster Boot Times and Offline Support

#19

Post by gnur »

threeseed wrote: post #5

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

Re: Our Quest for Faster Boot Times and Offline Support

#20

Post by dspillett »

flohofwoe wrote: post #16
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…

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…

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

Post reply on HN