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

21–30 of 57 posts

Re: Our Quest for Faster Boot Times and Offline Support

#21

Post by Nextgrid »

fnord77 wrote: post #6

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.

Re: Our Quest for Faster Boot Times and Offline Support

#22

Post by gtirloni »

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…

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

Re: Our Quest for Faster Boot Times and Offline Support

#23

Post by antisemiotic »

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…

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

Re: Our Quest for Faster Boot Times and Offline Support

#24

Post by orbifold »

gnur wrote: post #19
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 som…

Telegram is able to do this just fine.

Re: Our Quest for Faster Boot Times and Offline Support

#25

Post by ivanbozic »

Nextgrid wrote: post #21
fnord77 wrote: post #6

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

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.

Re: Our Quest for Faster Boot Times and Offline Support

#26

Post by jmsaucier »

Nextgrid wrote: post #21
fnord77 wrote: post #6

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

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.

Re: Our Quest for Faster Boot Times and Offline Support

#27

Post by threeseed »

Kiro wrote: post #18
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

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.

Re: Our Quest for Faster Boot Times and Offline Support

#28

Post by [deleted] »

gnur wrote: post #19
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 som…

[deleted]

Re: Our Quest for Faster Boot Times and Offline Support

#29

Post by threeseed »

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…

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.

Re: Our Quest for Faster Boot Times and Offline Support

#30

Post by malinens »

orbifold wrote: post #24
gnur wrote: post #19

Earlier quoted context omitted.

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

Telegram is able to do this just fine.

with much less $$$
Post reply on HN