Also worth noting some of these website (such as Linear) pre-load other pages once the current page is done loading. The actual JavaScript on the page seems to be about 500kb (as opposed to 3mb)
JavaScript Bloat in 2024
191–200 of 266 posts
Re: JavaScript Bloat in 2024
#192Earlier quoted context omitted.
That data can be gathered with self-hosted JS if the devs were allowed to implement it. The infatuation with third party analytics is just a more elaborate version of leftpad.
Marketing snippets are rarely implemented by devs, they get dropped into a text box or added to Google Tags by marketing/SEO peeps. If it is put in by a developer, the budget for that is like an hour to copy paste the code snippet in the right spot. Few are going to pay the hours required for an in house data collection layer that then has to integrate with the third party if that's even an option. At least that is m…
its not about having the chops to do it well, its about not importing every feature under the sun just because you want to do intern's first marketing analytics campaign.
earlier in the conversation someone talked about pasting a snippet. We're talking about the "chops" to not paste a snippet that is hundreds of thousands of lines long. A snippet so long it would crash many editors.
Re: JavaScript Bloat in 2024
#193Earlier quoted context omitted.
Marketing snippets are rarely implemented by devs, they get dropped into a text box or added to Google Tags by marketing/SEO peeps. If it is put in by a developer, the budget for that is like an hour to copy paste the code snippet in the right spot. Few are going to pay the hours required for an in house data collection layer that then has to integrate with the third party if that's even an option. At least that is m…
its not about having the chops to do it well, its about not importing every feature under the sun just because you want to do intern's first marketing analytics campaign. earlier in the conversation someone talked about pasting a snippet. We're talking about the "chops" to not paste a snippet that is hundreds of thousands of lines long. A snippet so long it would crash many editors.
Typically the person including the JS tag that then fetches the massive third party payload has no idea that's what is happening.
It is very common to get multiple departments and contracted companies sticking their misc JS in since every marketing SaaS tool they use has it's own snippet. Your SEO guy wants 3 trackers, your marketing has another 5, and you sell on XYZ online market and they have affilliate trackers etc.
No devs engaged at any point and the site performance isn't their responsibility. They can't do their job without their snippets so the incentives are very sticky, and the circus goes on.
It's kind of like an NPM dependency tree of martech SaaS vendors...
Re: JavaScript Bloat in 2024
#194I recently came back from a road trip in New Zealand - a lot of their countryside has little to no cell coverage. Combined with roaming (which seems to add an additional layer of slowness) and boy did it suck to try to use a lot of the web. Also if any spotify PMs are here, please review the Offline UX. Offline is pretty much one of the most critical premium features but actually trying to use the app offline really…
Offline is still miles and miles better than patchy Internet. If spotify thinks you have Internet it calls the server to ask for the contents of every context menu, waiting for a response for seconds before sometimes giving up showing a menu and sometimes falling back to what would have been instant if it was in offline mode. I really loathe their player.
This was one of the major reasons I left Spotify. Apple Music handles this much more gracefully.
Re: JavaScript Bloat in 2024
#195[dead]
Re: JavaScript Bloat in 2024
#196I know the implication here is "too much JavaScript" but we also need to talk about how much of this is purely tracking junk.
But surely even pieces of scummy tracking code can't take up megabytes of memory, right?! Just collect user session data and send it to some host.
Not sure whether you looked at the requests in the screenshots, but the tracking script code alone for many of these websites takes up megabytes of memory.
Re: JavaScript Bloat in 2024
#197Earlier quoted context omitted.
I never really understood why SPAs became so popular on the web. It’s like we suddenly and collectively became afraid of the page reload on websites just because it’s not a wanted behaviour in actual web applications. I have worked with enterprise applications for two decades, and with some that were build before I was born. And I think the React has been the absolute best frontend for these systems compared to every…
Why SPAs became popular? Because they "feel" native on mobile. Now you have page transitions and prefetch which really should kill this use case. IMO the bloat he talks about on the post is not representative of 2024. Pretty much all frontend development of the last 2 years has been moving away from SPAs with smaller builds and faster loading times. Fair enough it's still visible in a lot of sites. But I'd argue it's…
> Why SPAs became popular? Because they "feel" native on mobile.
They... Don't :) The absolute vast majority of them is a shittier, slower, clunkier version of a native app
> IMO the bloat he talks about on the post is not representative of 2024. Pretty much all frontend development of the last 2 years has been moving away from SPAs with smaller builds and faster loading times.
He literally lists Vercel there. One of the leaders in "oh look at our beautiful fast slim apps". Their front page loads 6.5 megabytes of javascript in 131 requests to those smaller bundles.
Re: JavaScript Bloat in 2024
#198Earlier quoted context omitted.
"- Rendering too many DOM nodes at once - virtual lists help" Yup, despite all the improvements, the DOM is still slow and it is easy to make it behave even slower. Only update what is necessary and be aware of the performance bottleneck forced reflow. Every time you change anything and then get clientWidth for example and then change something else - you will make the DOM calculate(and posibly render) everything twi…
> the DOM is still slow and it is easy to make it behave even slower I think this should be more nuanced: the DOM itself has been fast for 10-15 years but things like layout are still a concern on large pages. The problem is that the DOM, like an ORM, can make it easy to miss when you’re requesting the browser do other work like recalculating layout, and also that as people started using heavier frameworks they start…
> I think this should be more nuanced: the DOM itself has been fast for 10-15 years
It's faster than it was 10-15 years ago. It's still extremely slow.
> things like layout are still a concern on large pages.
> it easy to miss when you’re requesting the browser do other work like recalculating layout
You can't say things like "DOM is fast" and "oh, it's fast if you exclude literally everything that people want to be fast".
> and also that as people started using heavier frameworks they started losing track of what triggers updates.
I don't know if you realise, but on the very same devices where you're complaining about "large pages and oh my god layout" people are routinely rendering millions of objects with complex logic and animations in under 5 milliseconds?
The DOM is excruciatingly slow.
Re: JavaScript Bloat in 2024
#19910MB, 12MB, … Compare it to people who really care about performance — Pornhub, 1.4 MB Porn was always actual web hi-tech with good engineering, not these joke-level “tech” giants. Can’t remember a single time they’d screw up basic ui/ux, content delivery or common sense.
I never really understood why SPAs became so popular on the web. It’s like we suddenly and collectively became afraid of the page reload on websites just because it’s not a wanted behaviour in actual web applications. I have worked with enterprise applications for two decades, and with some that were build before I was born. And I think the React has been the absolute best frontend for these systems compared to every…
[deleted]
Re: JavaScript Bloat in 2024
#200Earlier quoted context omitted.
I think it's good and important that people occasionally call this out. Same as https://news.ycombinator.com/item?id=39315585 I don't understand why you'd consider this "low hanging fruit". What could the author have done to make it a high quality submission in your eyes? The alternative is to have more awareness of the amount of dependencies you really need, of when you actually need a framework with a runtime, and…
It would be much more interesting to analyse one of the sites in detail and consider what could be done to reduce the code size, looking at where it's coming from and what it does. Or to find out why it might be that some landing pages are shipping a lot of JS (could be because they are landing pages for web apps?). Or consider performance more holistically (are pages shipping a lot of code, but lazy loading or other…
> It would be much more interesting to analyse one of the sites in detail and consider what could be done to reduce the code size, looking at where it's coming from and what it does.
No. No it wouldn't. It's not the job of strangers on the internet to do the job of incompetent developers.
> Or to find out why it might be that some landing pages are shipping a lot of JS (could be because they are landing pages for web apps?)
How does being a landing page for a web app excuse downloading 6-10 MB of javascript to show two pages of static text and images?
> Or consider performance more holistically (are pages shipping a lot of code, but lazy loading or otherwise optimising it so that pages still perform well?).
Here's a holistic overview of performance: The Performance Inequality Gap, 2024 https://infrequently.org/2024/01/performance-inequality-gap-...
> There's a lot of bad faith "this is just a text box" for sites which clearly do much more than that too.
Not clearly. Not clearly at all.
---
Edit: note on the incompetence.
If you embed Youtube player in your website, Lighthouse will scream at you for being inefficient and loading too many resources. Nearly all of those issues will come from youtube.
Lighthouse will helpfully provide you with a help page [1] listing wrappers developed by other people to fix this. Chrome's "performance lead" even penned an article[2] on lazy loading iframes and linked to a third-party youtube wrapper which promises 224x speed up over the official embed.
They know. They either are so incompetent that they cannot do the job themselves, or they don't care.
[1] https://developer.chrome.com/docs/lighthouse/performance/thi...
[2] Over at webdev: https://web.dev/articles/iframe-lazy-loading pointing to https://github.com/paulirish/lite-youtube-embed
BTW. web.dev is created by web devs at Google. Promoting web development best practices. It takes it ~3 seconds to display a list of articles and the client-side only navigation is broken https://web.dev/articles