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.
Slack's 57MB 404 page
41–50 of 84 posts
Re: Slack's 57MB 404 page
#42Is 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…
Re: Slack's 57MB 404 page
#43Earlier 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
Re: Slack's 57MB 404 page
#44And 440MB tab memory usage
Re: Slack's 57MB 404 page
#45Earlier 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?"
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
#46Is 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.
Re: Slack's 57MB 404 page
#4748MB of this is JavaScript, which is abomination.
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
#48Re: Slack's 57MB 404 page
#49Earlier 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,…
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
#50Earlier 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
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/