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

1–10 of 57 posts

Re: Our Quest for Faster Boot Times and Offline Support

#3

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

Re: Our Quest for Faster Boot Times and Offline Support

#4

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

Re: Our Quest for Faster Boot Times and Offline Support

#5

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

Re: Our Quest for Faster Boot Times and Offline Support

#9

Post by crispinb »

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…

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.

Re: Our Quest for Faster Boot Times and Offline Support

#10

Post by 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
Post reply on HN