Gregory's ServerNew post: JavaScript Bloat in 2024 https://tonsky.me/blog/js-bloat/
 30 comments
 @kommen @nikitonsky tbh mastodon's stock frontend still feels super clunky after using pinafore for a few years (560kb)  @nikitonsky Performance inequality gap is a good companion to this: https://infrequently.org/2024/01/performance-inequality-gap-2024/  @nikitonsky Surprised you didn't try Miro. Huge memory consumption on their tabs but I've never checked the raw amount of scripts. @OmegaPolice I don’t really use it, don’t even have an account. If you use it, you can measure yourself! I’m very curious to know @nikitonsky Fair. 😅 Hope I checked the right boxes. Opened a single Miro board there. "Finished" was more like ≈40s, is keeps sending requests (of course it does). Anyway: 29MB @OmegaPolice yeah that’s a lot. My baseline is still Figma. Is Miro 1.5x complexity of Figma? Probably not @nikitonsky Great post! Unfortunately though I think "disable cache" may be over-reporting. For react.dev for example, it looks like it is continually re-downloading the same resources as you scroll. My workaround is usually to use a fresh private window rather than "disable cache," FWIW.  @nolan a valid argument for some sites, but for react.dev? It's a blog post with static information, why does it even try loading a script in the first place, and why does it do it over and over again? Yeah, it's not what a typical user would experience, but it's still crazy dumb behaviour :D  @kytta @nolan @nikitonsky because most of their pages have inline code editors where you can write code and see the output in action. A lot of their pages have multiple embedded editors. Having caching enabled would prevent that from being an issue. I’m not excusing the total JS size, but calling it just static code is a bit disingenuous.  @nikitonsky @nikitonsky just used your method to check out what we have for https://karrot.world / @karrot 1.86mb of JavaScript for logged in main view - with maps, threaded messaging, emoji reactions, "events", etc... Compares quite favourably to sites of similar complexity from your post (discord = 21mb, slack = 55mb!!!). We also always publish a bundle analysis along with the code, e.g. https://karrot.world/bundlesize.html (ah, just noticed we've accidentally pulled in lodash recently!) @nikitonsky great post! So many of those examples are awful, especially because of how many of those sites were probably doing okay… until they injected shit tons of marketing JS. It’s a huge bummer to see how the app-ification of sites has led to such a negative first-load experience. Just makes me… want to work for those companies and try to fix stuff. The PornHub vs YouTube comparison is especially great, because the different monetization models result in vastly different outcomes. @sangster somebody mentioned on HN that Pornhub just can’t allow “load once, serve from cache” model since they are usually run in private windows @nikitonsky Great post! I've been wondering about something in regards to ad/tracking scripts on some of the example pages, as some basically cover entire sections of your DevTools screencaps. and in the case of GitLab, if I browse it using an adblocker, I get about 10 MB of assets, without an adblocker it goes up to 17 MB. Almost double. @nikitonsky A webapp we develop for internal users is sitting at around 8MBs of javascript at the moment. So... middle of the pack, I guess? @nikitonsky Agreed that the average website in 2024 is trending toward JS bloat. Even GitHub is moving in this direction. To counter this effect I think there needs to be better documentation/tutorials for using modern frontend reactive JS frameworks (like Vue or React) with traditional backend frameworks (like Django, Rails, even PHP). #Vue 2 did a good job here. But Vue 3 docs mainly focus on SFCs and Vite, which don’t play nice with other frameworks.  @nikitonsky really good post - I wonder what photopea.com ads up to - it being effectively photoshop in the browser. @nikitonsky This is such a good post, thank you. The first thing I did after reading this is to check my own blog first for the JS size :) @nikitonsky I think it would be interesting to include the "other" files as well, as many actually complex web apps are moving to web assembly code for computation. @nikitonsky Another thing to add to the list of reasons why I like Fastmail. Great post, thanks @nikitonsky Relatedly, I was clearing cached data out of Chrome yesterday night and discovered that the Ace Hardware website, which I’m pretty sure I visited ONCE almost two years ago to buy some dowels, was consuming 699 MEGABYTES of site storage. Just gonna let that hang in the air. |
@nikitonsky Mastodon clocking in just at 1,7 MB is rather refreshing for the social media section