Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JavaScript Bloat in 2024

tonsky.me

Post reply on HN
Print view View original

41–50 of 266 posts

Re: JavaScript Bloat in 2024

#41

Post by eitland »

nsonha wrote: post #39

it's always bothered me that this dogma exists. Somehow web apps need to be super frugal with code size, while apps distributed on other (native) platforms never have such a problem. Somehow it's the bloated web that blocks the access for children in Affrica, but they can download bloated android apps just fine? Maybe, just maybe, the problem isn't the size of the javascript, it's how broken the entire web stack (spe…

If Atlassian did't use a full minute to update a certain roadmap view on my MBP from January I would be one step closer to agreeing with you even if it was still 50 MB.

But I am old enough to remember Gannt charts didn't use to take that long on old Pentium processors back in school, way before Git was invented.

Another thing is the sheer yuck of it:

If a typical web app was lots of business code, maybe. But when you look at the network tab and it feels like you are looking at the hair ball from a sink drain, lots of intertwined trackers to catch everything that passes, that is another story.

Re: JavaScript Bloat in 2024

#42

Post by devtailz »

420698008 wrote: post #28

Meanwhile the author has a ton of 1440p images while pegging his website width to 560px I like the conversation about web performance, but you should make sure you practice what you preach

The images display at 720x720, on a 2x retina screen the image needs to be 1440x1440 to fill that.

Re: JavaScript Bloat in 2024

#43

Post by cyclotron3k »

420698008 wrote: post #28

Meanwhile the author has a ton of 1440p images while pegging his website width to 560px I like the conversation about web performance, but you should make sure you practice what you preach

720px actually, but more importantly, 720px is not actually 720px on a HiDPI screen.

I just measured it on my mbp and "720px" is actually... 1440 physical pixels. I was surprised too!

Re: JavaScript Bloat in 2024

#44

Post by donkeybeer »

nsonha wrote: post #39

it's always bothered me that this dogma exists. Somehow web apps need to be super frugal with code size, while apps distributed on other (native) platforms never have such a problem. Somehow it's the bloated web that blocks the access for children in Affrica, but they can download bloated android apps just fine? Maybe, just maybe, the problem isn't the size of the javascript, it's how broken the entire web stack (spe…

Web sites should be frugal. If content websites, even more so if they even lack comment sections, are getting huge that's a pure "skill issue". It's not our place to speculate why what should have been a content site became a web app.

Re: JavaScript Bloat in 2024

#45

Post by kevin_thibedeau »

willsmith72 wrote: post #38
BandButcher wrote: post #20

Earlier quoted context omitted.

Was going to mention this, almost any company's brand site will have tracking and analytics libraries set in place. Usually to farm marketing and UX feedback. Whats worse is some of them are fetched externally rather than bundled with the host code thus increasing latency and potential security risks

im pro privacy, but is it really so bad to get anonymous data about where people clicked and how long they stayed where? it would be almost impossible to measure success without it, whether it's a conversion funnel or tracking usage of a new feature

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.

Re: JavaScript Bloat in 2024

#46

Post by MrJohz »

willsmith72 wrote: post #38
BandButcher wrote: post #20

Earlier quoted context omitted.

Was going to mention this, almost any company's brand site will have tracking and analytics libraries set in place. Usually to farm marketing and UX feedback. Whats worse is some of them are fetched externally rather than bundled with the host code thus increasing latency and potential security risks

im pro privacy, but is it really so bad to get anonymous data about where people clicked and how long they stayed where? it would be almost impossible to measure success without it, whether it's a conversion funnel or tracking usage of a new feature

It is when (a) that data collection takes up a significant amount of bandwidth whenever I visit your website, and (b) I don't trust that that data collection really is as anonymous as the website says (or even thinks).

The major players here are explicitly not anonymous, they are designed to keep track of people over time so that they can collate habits and preferences across different sites to better target advertising. Yes, your AB test script isn't doing the same thing, but is it really adding any value to be as a consumer, or is it just optimising an extra 0.01% revenue for you?

Re: JavaScript Bloat in 2024

#47

Post by YuukiRey »

iamsaitam wrote: post #34

At this point, blog posts like these just look like "rage bait" for web developers.. What's the point of it? What's the alternative? The biggest reason why this topic is a topic, is due to the browser developer tools letting anyone glance at these details easily. If this wasn't a low hanging fruit blog post, it would also try to figure out if this is isolated to web development or can we see this across the board (hi…

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 so on. He mentioned a fair share of essentially static landing pages that really have no reason to ship so much crap. And even though it's not explicitly mentioned: this isn't just a potential issue for end users. This code likely makes life hard for the developers as well. With every dependency you get more potential for breaking changes. With every layer it gets harder to understand what's going on. The default shouldn't be to just add whatever you want and figure it out later, the default should be to ask yourself what really needs to be added. Both in terms of actual code, but also layers, technologies, frameworks, libraries.

Re: JavaScript Bloat in 2024

#48

Post by ehnto »

kevin_thibedeau wrote: post #45
willsmith72 wrote: post #38

Earlier quoted context omitted.

im pro privacy, but is it really so bad to get anonymous data about where people clicked and how long they stayed where? it would be almost impossible to measure success without it, whether it's a conversion funnel or tracking usage of a new feature

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 my experience through agency work. Maybe a product owner company could do it.

Not to be rude to the industry either, but I don't see why the assumption would bet that an in house dev has the chops to not make the same mistakes a third party does.

Re: JavaScript Bloat in 2024

#50

Post by lukan »

SebastianKra wrote: post #6
acdha wrote: post #5

Earlier quoted context omitted.

Compression helps transfer but your device still has to parse all of that code. This comes up in discussions about reach because there’s an enormous gap between iOS and Android CPU performance which gets worse when you look at the cheaper devices a lot of the public use where new Android devices sold today perform worse than a 2014 iPhone. If your developers are all using recent iPhones or flagship Android devices, i…

I happen to develop a JS-App that also has to be optimised for an Android Phone from 2017. I don't think the amount of JS is in any way related to performance. You can make 1MB of JS perform just as poorly as 10MB. In our case, the biggest performance issues were: - Rendering too many DOM nodes at once - virtual lists help. - Using reactivity inefficiently. - Random operations in libraries that were poorly optimised.…

"- 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 twice.

I found the chrome dev tools to be really helpful with spotting those and other stuff. But sure, if you update EVERYTHING anyway, including waiting for the whole data transfer, with any click, when you just want some tiny parts refreshed, you have other problems anyway.

Post reply on HN