Live data from Hacker News

Slack's 57MB 404 page

a.slack.com

41–50 of 84 posts

Re: Slack's 57MB 404 page

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

[deleted]

Re: Slack's 57MB 404 page

#42
post #7

Is this because it is a SPA? I'm hesitant to ascribe blame but I have to confess I'm pretty bored of inexplicably heavy frontend code that takes an age to both arrive and execute. Bonkers stuff.

Yep, it is a SPA - but there is still a category of old grumpy devs who insist that the real web is a single hand crafted HTML file sprinkled with a bit of CSS. Yes, a 6MB (compressed) bundle is big. But it is not clear that the alternatives are better. The bundle would need to be split increasing complexity of building the application. It is likely judged that splitting the bundle only has minimal positives compared…

I assure you that 20 years ago websites with chats existed and they worked fine. Which means they weren't so huge because it would have taken days to download that amount of stuff.

Re: Slack's 57MB 404 page

#43
post #28

Earlier quoted context omitted.

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

Scrolling using actual scroll - instead of following the pointer and automatically scrolling - would make the page better anyway IMHO

Re: Slack's 57MB 404 page

#45
post #25
post #15

Earlier quoted context omitted.

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

> I don't know where you've met all those programmers who are good at their job

Most of my professional experience is from working in smaller startups, grown into medium-sized ones, that I've picked to approach for work because I liked the programmers who already worked there, I'm guessing that's why :)

Consulting for various IT and IT-adjacent companies of all types of sizes, I certainly understand where you coming from, they tend to already be burned out (or something) enough to not ask questions anymore.

Re: Slack's 57MB 404 page

#46
post #7

Is this because it is a SPA? I'm hesitant to ascribe blame but I have to confess I'm pretty bored of inexplicably heavy frontend code that takes an age to both arrive and execute. Bonkers stuff.

There is no inexplicably heavy front end code and SPA is not to blame here. This is a matter of non existent optimization and code pilled on top of code.

Re: Slack's 57MB 404 page

#47

48MB of this is JavaScript, which is abomination.

Presumably you're getting the whole Slack app, and if you're landing on their 404 page (for reasons other than this thread), then presumably you're using Slack. Which means you would have downloaded and cached that already.

There's a discussion to be had as to whether the Slack app should be 48mb, but that's a different discussion. Focusing on the 404 page feels like outrage bait for web devs.

Re: Slack's 57MB 404 page

#48
It aligns quite well with their Linux client that hogs so much memory that I need to run it in a cgroups with a memory limit to avoid eating too much memory :)

Re: Slack's 57MB 404 page

#49
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,…

Teams are decent tbh

Ive been using them since 2021 iirc and they improved a lot

And im using Discord daily which is state of the art

Re: Slack's 57MB 404 page

#50
post #28

Earlier quoted context omitted.

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

> How would you implement that scrolling background?

At a glance I'm not sure exactly how I'd implement it, but my guess is that it's possible with some workarounds and hacks, at the very least.

Here's an article showing some demos (at the bottom) on how you can make the mouse cursor affect CSS: https://css-tricks.com/how-to-map-mouse-position-in-css/

Post reply on HN