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

181–190 of 266 posts

Re: JavaScript Bloat in 2024

#181

Post by npteljes »

wruza wrote: post #32

10MB, 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.

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

Well, I do remember the myriad of shady advertisement tactics that porn sites use(d), like popups, popunders, fake content leading to other similar aggregation sites, opening partner website instead of content, poisoning the SEO results as much as they can, and so on. Porn is not the tech driver people make it up to be, even the popular urban legend around the Betamax vs VHS is untrue, and so is that they drive internet innovation. There is a handful of players who engineer a high quality product, but it's hardly representative to the industry as a whole. Many others create link farms, dummy content, clone websites, false advertisement, gaming the search results, and so on. Porn is in high demand, it's a busy scene, and so, many things happen related to it, and that's about it.

The current state of snappy top-level results is I think the result of competition. If one site's UX is shitty, I think the majority of the viewers would just leave for the next one, as there is a deluge of free porn on the internet. So, the sites actually have to optimize for retention.

These other websites have different incentives, so the optimized state is different too. The user is, of course, important, but if they also have shareholders, content providers, exclusive business deals, monopoly, then they don't have to optimize for user experience that much.

Re: JavaScript Bloat in 2024

#182

Post by npteljes »

wruza wrote: post #160
thiht wrote: post #80

Earlier quoted context omitted.

I don’t think you’re speaking for the majority here, no one has pornhub in their bookmarks bar

Yeah that was incoherent remark on my side, and there are situations where I'd put them in a folder. But I still find going incognito to watch porn paranoid.

It can also be considerate, like when using a shared device. Similar to how we don't vocalize every intrusive thought.

Re: JavaScript Bloat in 2024

#183

Post by npteljes »

vendiddy wrote: post #133

I'm inspired to slim down my own app. Any good tools or techniques out there to identify what's causing bloat?

Turning on any kind of performance monitoring can help. They usually have ones for every platform. For the web, for example, I used YSlow in the past, but there are several alternatives: https://alternativeto.net/software/yahoo-yslow/

Re: JavaScript Bloat in 2024

#185

Post by acdha »

lifthrasiir wrote: post #144
guappa wrote: post #129

Earlier quoted context omitted.

It is parsed and loaded in memory, and not executed.

"Loaded" part is no longer true in major JS implementations (for example, [1]). [1] https://v8.dev/blog/preparser

That’s a broader claim than that page supports. They describe how they avoiding fully generating the internal representation and JITing it, but clearly even unused code is taking up memory and CPU time so you’d want to review your app’s usage to make sure that it’s acceptable levels of work even on low-end devices and also that your coding style doesn’t defeat some of those optimizations.

Re: JavaScript Bloat in 2024

#186

Post by acdha »

lukan wrote: post #50
SebastianKra wrote: post #6

Earlier quoted context omitted.

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 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 started losing track of what triggers updates.

Lists are an interesting challenge because it’s surprisingly hard to beat a well-tuned browser implementation (overflow scrolling, etc.) but a lot of people still have the IE6 instincts and jump for implementing custom scrolling, only to find that there are a lot of native scrolling implementation features which are hard to match, and at some point they realize that what they really should have done was change the design to make layout easier to calculate (e.g. fixed or easily-calculated heights) or displayed fewer things at once.

Re: JavaScript Bloat in 2024

#187

Post by iamsaitam »

shiomiru wrote: post #87
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…

> What's the alternative? Many websites listed on the page don't even need JS.[0] Consider how just a few years ago there used to be an entire suite of alternative frontends to major "web apps"/"social media platforms", which generally worked without any JS, and were created & ran by volunteers. In general, they all provided superior UX by just not loading megabytes and megabytes of tracking code; this would be the a…

You're confounding using Javascript for web development and "loading megabytes of tracking code". They are not mutual exclusive, nor have anything to do with the development side of it. Advertising and tracking are a business decision, not technical one.

Well, you're entitled to not visit/use those websites if the megabytes of JS don't serve you. That would be the cost of the decision made to use Javascript by those websites, to have people that share your opinion not using them. And cost is a subjective factor dependent on multiple things and hidden from the user, so when you judge a website to be using Javascript without need, you're basically saying that you know better the cost to the developer than the developer itself.

Re: JavaScript Bloat in 2024

#188

Post by pier25 »

CompuIves wrote: post #161
tjosepo wrote: post #26

Earlier quoted context omitted.

You can see from the recording that it's downloading the same few files from Codesandbox over and over again, as the iframes used for the examples are being unloaded and reloaded on scrolls and because the author disabled caching. The author could've scrolled forever and the number would've gone up indefinitely.

Exactly, the result would've been different if the author would not have disabled caching. In this case it's because the iframes are loaded/unloaded multiple times, but we also spawn web workers where the same worker is spawned multiple times (for transpiling code in multiple threads, for example). In all those cases we rely on caching so we don't have to download the same worker code more than once.

Wouldn't it be better if the code editors only activated if the user interacts with one?

Even with caching it's absurd to download so much JS for a feature that probably most users will not use. It's a docs site after all.

Re: JavaScript Bloat in 2024

#189

Post by wruza »

npteljes wrote: post #181
wruza wrote: post #32

10MB, 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.

>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. Well, I do remember the myriad of shady advertisement tactics that porn sites use(d), like popups, popunders, fake content leading to other similar aggregation sites, opening partner website instead of content, poisoning the SEO resu…

I generally agree and understand. The reasoning is fine. But comments like this make me somewhere between sad and contemptuous towards the field. This neutral explanation supports the baseline that no professional can vocalize anywhere and retain their face. I'm talking youtube focus & arrows issues here, not rocket science. Container alignment issues [1], scrolling issues [2], cosmic levels of bloat [$subj], you name it. Absolutely trivial things you can't screw up if you're at all hireable. It's not "unoptimized", it's distilled personal/group incompetence of those who ought to be the best. That I cannot respect.

[1] https://www.youtube.com/watch?v=yabDCV4ccQs -- scroll to comments and/or switch between default/theater mode if not immediately obvious

[2] half of the internet, especially ux blogs

Re: JavaScript Bloat in 2024

#190

Post by AHTERIX5000 »

gpjanik wrote: post #135

Serious question: what is the issue with these paritcular sizes? I know that features/look these websites have are definitely achievable with less JS at a higher engineering cost, but what's the problem with it? 10MB loads in two seconds on an okay-ish desktop connection (correct me if I'm wrong, but most of people don't deploy Vercel apps from their phone from a mountain range with 3G connection). The experience on…

But the experience is not smooth as it can get if you're running a bit older HW. Gmail and Slack are notorious for bad performance even when the content displayed is rather simple plain text. As a user I don't really get anything in return when developers decide to use complex JS solutions for simple use cases.
Post reply on HN