Live data from Hacker News

Slack's 57MB 404 page

a.slack.com

21–30 of 84 posts

Re: Slack's 57MB 404 page

#22
Slack is a constant garbage fire where clearly all the devs have a fast desktop and don’t care about performance or battery use in the slightest. I wish my org would move away from this junk.

Re: Slack's 57MB 404 page

#23
post #8

My intuition was that most of the (transferred) 11MB would be images, but no! Of course it's JavaScript bundles: https://i.imgur.com/QoM0Mz5.png I'm guessing most of that code is used for other things on the website/landing page (SPA without bundle splitting per page), and the same stuff is loaded for every page, since the code for building that would be trivial compared to the multiple large bundles like they're shi…

modern.vendor.{cache_id}.min.js => 37.11MB

Re: Slack's 57MB 404 page

#24
Looks like the biggest part is a 37MB vendor bundle, so I assume those are all the libraries they use. It's 6.5MB transferred, but compression only helps with the network part, something still parses and interprets that JS.

Re: Slack's 57MB 404 page

#25
post #15
post #10

Clearly no one stops and ask "Should we?". Which is sad. I was just spending long weekend at place with less perfect connectivity, that is 2-3 Mbs LTE... And the 11MB would have taken quite many seconds... Not exactly good user experience. Good to know that Slack is not company to choose for user experience and efficiency.

> Clearly no one stops and ask "Should we?". Which is sad. I'm not sure, I've seen plenty of cases where programmers do stop and ask "Should we?" while management says "It's not ideal, but you have 4 hours allocated to shipping this things, so decide the "right" approach for achieving our OKRs" or similar.

I don't know where you've met all those programmers who are good at their job. In my experience the ones who don't care beyond the questions "does it compile? Does it pass the test suite?" outnumber the ones who ask questions like "is this even the correct approach at all?"

Re: Slack's 57MB 404 page

#26

Slack is a constant garbage fire where clearly all the devs have a fast desktop and don’t care about performance or battery use in the slightest. I wish my org would move away from this junk.

Add Teams and Outlook to this pile. For some reason there isn’t a non-shitty enterprise chat software.

Re: Slack's 57MB 404 page

#27
post #17
post #10

Clearly no one stops and ask "Should we?". Which is sad. I was just spending long weekend at place with less perfect connectivity, that is 2-3 Mbs LTE... And the 11MB would have taken quite many seconds... Not exactly good user experience. Good to know that Slack is not company to choose for user experience and efficiency.

You can stop and ask that question. This quickly antagonizes the entire org - because that 57MB bundle is composed of sub-bundles owned by teams with their own incentives, and none of them are interested in doing a 404 page right - that they do not own, won't get promoted for and which doesn't show up in their KPIs.

so much this

Re: Slack's 57MB 404 page

#28
post #8

My intuition was that most of the (transferred) 11MB would be images, but no! Of course it's JavaScript bundles: https://i.imgur.com/QoM0Mz5.png I'm guessing most of that code is used for other things on the website/landing page (SPA without bundle splitting per page), and the same stuff is loaded for every page, since the code for building that would be trivial compared to the multiple large bundles like they're shi…

It reacts with the visibility state, so no JS seems impossible. [ADDED:] Besides from the obvious mouse interaction, [/ADDED] everything else should be implementable in CSS I believe.

How would you implement that scrolling background? Particularly the mouse interaction, where it scrolls with a dynamic speed ( depending on how far to the side the mouse it) and even has some smooth damping when you stop scrolling.

And what part uses the visibility state? The grayscale seems to be triggered by focus which I think would be doable with CSS

Re: Slack's 57MB 404 page

#29
post #19

Earlier quoted context omitted.

No. Everyone is on Teams.

Which is unfortunate, but a consequence of Microsoft's perennial, embrace, extend, extinguish - they embraced instant-messaging version 3 (or wherever we are now), and they're onto the extend part - extending Teams' reach by bundling it 'for free' in Office, and the OS, so people don't "need" to buy Slack. Slack won't be 'extinguished' but it will have a falling market share, despite the dumpster fire that is Teams,…

The next victim is going to be Figma

Re: Slack's 57MB 404 page

#30
post #8

My intuition was that most of the (transferred) 11MB would be images, but no! Of course it's JavaScript bundles: https://i.imgur.com/QoM0Mz5.png I'm guessing most of that code is used for other things on the website/landing page (SPA without bundle splitting per page), and the same stuff is loaded for every page, since the code for building that would be trivial compared to the multiple large bundles like they're shi…

It reacts with the visibility state, so no JS seems impossible. [ADDED:] Besides from the obvious mouse interaction, [/ADDED] everything else should be implementable in CSS I believe.

Not sure about the interactive part, but I have build butterflies like this in pure CSS with css animations before. Definitely doable.
Post reply on HN