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 shipping right now.
Which kind of makes me think, what is the smallest amount of JS one could write to 100% replicate this page? Would <1KB be enough? Bonus points if it could be implemented with CSS only, under 1KB.
But there are interactive chickens if you wait long enough.
CSS (since like CSS2, 1998) has interactivity too ;) Time to read up on the specifications oldie!
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/
Ah, I forgot that (everything except for the interaction should be okay, though). For the visibility state however, checking for focus is insufficient because you can have elements focused without the document being visible.
Scrolling using actual scroll - instead of following the pointer and automatically scrolling - would make the page better anyway IMHO
Not sure about the interactive part, but I have build butterflies like this in pure CSS with css animations before. Definitely doable.
modern.vendor.{cache_id}.min.js => 37.11MB
Absolutely insane. Some silly comparisons to what software has changed the world at less than 50MB:
- VisiCalc: ~27KB - i.e. the first killer app, and probably still the most successful. I wonder what DAUs on excel & google sheets compared to tiktok and insta are like...would be interesting to see.
- Wolfenstein 3D (1992): ~2MB - invented the FPS genre
- DOOM (1993): ~2.5MB (shareware), ~12MB (full)
- Quake (shareware) ~8.7 MB
- Quake (full) ~15-25 MB (excludes the CD audio)
- nginx: ~2-5MB - powers ~35% of all websites
- bash: ~1MB
- git (*nix only): ~3mb
- gcc + toolchain (ie ld, cc1, etc) ~40-45 mb
- FFmpeg: ~30-40MB
- curl: ~3MB
- OpenSSL: ~5MB
- windows 95: 50-55MB depending on features installed
- google.com circa 1998 - 10-15kb
- google.com today (anonymous session, ublock disabled) ~700kb
edit: my kingdom for markdown
- The Legend of Zelda: Ocarina of Time: 32 MB
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?"
> 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.
Mostly worked at bigger companies. Once joined a company with pretty shit colleagues/management. Left after three months.
If you have mobility, it's worth shopping around for a decent place to work.
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
> Clearly no one stops and ask "Should we?". Which is sad.
"I did what my manager asked me to. Asking questions is no in my job description. I've got kids to feed".
> Good to know that Slack is not company to choose for user experience and efficiency
Did the product itself not give it away? ;)
Should we what?
This is an effect from no one prioritizing extra complexity that might / might not provide any tangible value.
- [deleted]
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.
It's always been like this as well. Back when Slack first started gaining prominence ten years ago it was the only webapp that made my laptop's fan spin loudly. We actually migrated to HipChat because of that.
Same with how much space the entire thing wastes: it's clearly designed by people with 8K 30" monitors and perfect vision.
I have many more gripes, but that would be too off-topic. I don't understand how it got so popular.
I agree. I put in a ticket with them in 2015 that was basically “every time I compile I have to close slack because it uses more memory than my compiler”
My org hasn't moved away but I use localslackirc to connect via my preferred IRC client.
I get perks like not seeing reaction emojis, gifs, and being able to mute the constant flow of @channel notifications by configuring a list of people or channels from which I am not interested in getting these generic notifications.
Also most importantly, since my company recently shifted from treating us like adults to telling us we must only work on the assigned tasks and for no reason go out of task, I configured it to not join general discussions channels where people ask for help and such things. In theory I'm on them, but from the point of view of my IRC client I'm not.
It re-joins automatically if someone mentions me specifically. Unfortunately it won't fetch the history when this happens so I might need to open the real slack to get the context before I can answer.
Anyway, it has worked mostly fine for me… I can have decent battery life and I don't get most of the useless notifications.
That looks cool. I do like to see reactions to my messages, but other than that it sounds great
Add Teams and Outlook to this pile. For some reason there isn’t a non-shitty enterprise chat software.
Teams is far worse than Slack though, an embarrassment for a billion dollar company. Think of the collective waste of time and electricity.
Yeah.. seems like a great opportunity for Discord to start a Discorp whitelabel brand. :-) Just remove all the fun/spammy/nitro features, add SSO and an SLA, and slab on a steep per-seat price.
Imagine sitting down to work for the day, firing up Discorp, and waiting an hour for all those updates to download.
I’m laughing at the idea of someone there seeing this article.
Organizes a meeting: “we look like clowns”. Technical person explains the package being big. Non technical person asks to remove, hoping for some kind of correction story. Marketing people looped in to maybe come up with a way to float this story.
Fix is evaluated for in a couple of sprints from now. A simpler html page is shipped for the sprint. Everybody high fives about one month from now for the simpler html page.
Non technical manager feels like they delivered something and the org is sluggish but they can get things done.
No way it happens. The business/marketing people can't stand their JS getting messed with.
There was a whole thread the other day about a framework for smuggling these huge analytics bundles through content blockers. Funny it was just around the same time another large thread was on the front page full of marketing people spazing out over the low click through rate when people are given AI summaries and aren't forced to "experience" these corporate sites running on their computers.
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.
Jesus. Is there a hidden bitcoin miner or a Linux VM in there somewhere?
Nah, just a whole JS framework compiled, a bunch of tracking and instrumentation.
On the upside, thing does cache, and LocalCDN handles most of it.
Since nobody's mentioned this yet: this must be a left-over from or tribute to Glitch (https://en.wikipedia.org/wiki/Glitch_(video_game)) the video game project that Slack originally grew out of.
Yep! This seems like a tribute to Glitch!
I was profiling an ecommerce site we're responsible for and noticed that the app.js package felt a bit big: nearly 4MB unzipped. Most of it was the standard SPA/React attendant stuff with modern development, but within it was a 180 kB SVG of an old version of the company logo that wasn't being used anywhere on the site, but which had made it into a dev and then production branch and was shipped live. The zipped version was 175 kB total, but this SVG ended up being a decent portion of that size, and we do about 6M uniques per month, so it adds up, though we're now caching through CloudFlare instead of AWS/CloudFront, so that helps.
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 :)
54 requests
57.54 MB / 11.83 MB transferred
There's only 11.83 MB transferred, but that doesn't excuse it.
But you can click on the chicken and it will jump. KPIs matter.
Not sure what's wrong here, but in Safari, cache disabled, the page size ballooned to 110 MB: https://imgur.com/a/EJja3V0
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.
I'm guessing at that size (37MB!), the bottleneck becomes the initial parsing and interpretation of the JS for most clients, rather than the transferring part, which is kind of bananas when you think about it.
Well at least it's cute.
I'm all for Easter Eggs, but at least make them cool EEs.
Saw this Slack 404 page years ago so not a new release.
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.
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 to the negatives - which also align with my experiecne developing software for roughly the same target segment.
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.
Just like 40 years ago we where able to store a POSIX compatible OS on a floppy drive.
The things developers usually forget is that there are other stakeholders than the computer executing code - IMHO a lot of developers would benefit from developing a bit of business acumen.
I doubt customers specifically ask to make the product really large and slow.
No - the customer is not asking to spend additional developer time in minimizing bundles.
This is exactly the type of business acumen that is missing.
Is the customer asking for a product that takes 5 minutes to open? Eventually customers do move away from crap… they're just very slow.
Customers of Slack don't care - and I think you are talking about the users.
This is exactly why developers need more business acumen.
And 440MB tab memory usage
Missed opportunity for 404mb
Tricky to slim down, but 4.04 GB should be a snap
6.5MB compressed, and will be cached. Shrug
To be honest, still awful.
Out of interest, is slack still being used as extensively as it was 4-5 years ago?
I don't know, but anecdotally, I still use it for work, but no longer for personal chats.
It also seems like someone at Slack is tasked with driving up engagement, because I get these "Your team is missing you" messages from Slack (only to be find a dead slack community). That might be a sign that they're losing traction?
> slack still being used as extensively
Used differently I'd say, but can't say I have a 100% view of all the users. My feeling is that various software projects moved to Discord instead (particularly FOSS which feels strange), and Slack seen an uptake in enterprise usage which makes sense considering the new(-ish) owner.
Yes - everyone hates teams
Teams is useless comparing to slack if you need to coordinate work indeed.
I suppose you're supposed to use the whole Microsoft "ecosystem" for what a single app can do.
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, and the bean-counters in most corporations getting kudos from their bosses for 'cost savings'.
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
The next victim is going to be Figma
Slack is a public company so you can read the financials.
My company combines discord and teams.
Discord is mostly used by devs.
How much traffic do you think the 404 page gets? or do any 404 pages get these days? With a clean sitemap and only linked pages indexed on search engines, very few actual users/customers are going to hit 404 pages these days.
This isn't about being performative. This is about having fun. Blame a thousand Web 2.0 companies from yesteryear or blame Google for their legacy of little jokey easter eggs. This has a nod to Slack's history and some devs got to blow off some steam and have some fun. Would it be better if they crammed the animation into 1kb? Sure, but this isn't a demoscene comp. And perhaps Marketing gets a positive bump for it when someone shares it saying this is cool (or conversely threads like this).
This is about having some fun. It's part of our internet roots and culture.
It would be an interesting competition to find the biggest JavaScript payload for a single page of any Fortune 500 company.
like it
