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

221–230 of 266 posts

Re: JavaScript Bloat in 2024

#221

Post by kaba0 »

troupo wrote: post #198
acdha wrote: post #186

Earlier quoted context omitted.

> 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 fast er 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…

Rendering a bunch of vertices in 3D is an “embarrassingly parallel” problem, you can scale it pretty much forever.

With all due respect, if you compare that to 2D layouting and stuff, you don’t know much about the topic.

Re: JavaScript Bloat in 2024

#222

Post by kaba0 »

okaleniuk wrote: post #138

Meanwhile, all the pages on https://wordsandbuttons.online/ with all the animation and interactivity are still below 64 KB. This one, for example, https://wordsandbuttons.online/trippy_polynomials_in_arctang... is 51 KB. And the code is not at all economical. It's 80% copy-paste with little deviations. There is no attempt to save by being clever either, it's all just good old vanilla JS. And no zipping, no space redu…

It could add at least some minimal margin. On mobile, I literally can’t see the edges.

Re: JavaScript Bloat in 2024

#223

Post by lukan »

kaba0 wrote: post #221
troupo wrote: post #198

Earlier quoted context omitted.

> I think this should be more nuanced: the DOM itself has been fast for 10-15 years It's fast er 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…

Rendering a bunch of vertices in 3D is an “embarrassingly parallel” problem, you can scale it pretty much forever. With all due respect, if you compare that to 2D layouting and stuff, you don’t know much about the topic.

Why are you sure, he was talking about vertices or 3D in general?

Re: JavaScript Bloat in 2024

#224

Post by troupo »

lukan wrote: post #223
kaba0 wrote: post #221

Earlier quoted context omitted.

Rendering a bunch of vertices in 3D is an “embarrassingly parallel” problem, you can scale it pretty much forever. With all due respect, if you compare that to 2D layouting and stuff, you don’t know much about the topic.

Why are you sure, he was talking about vertices or 3D in general?

I was. But people are always missing a point.

There's a range of options between "can render millions of objects with complex animation and logic" in a few milliseconds and "we will warn you when you have 800 dom nodes on a static page, you shouldn't do many updates or any useful animations"

Somehow people assume that what HTML does is so insanely hard that the problem of 2D layout should not just be relevant to modern day supercomputers, but to be so slow as to be seen with the naked eye.

The 2D layout in HTML is slow because the DOM (with the millions of conflicting hacks on top of it) is slow, not the other way around.

We could do most of the frankly laughable HTML layouts at least in early 2000s, perhaps earlier.

Well, definitely earlier, as Xerox that influenced the Mac is from 1970s

Re: JavaScript Bloat in 2024

#225

Post by FractalHQ »

cyclotron3k wrote: post #43
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!

MBP device pixel ratio is 2 after all!

Re: JavaScript Bloat in 2024

#226

Post by lukan »

troupo wrote: post #224
lukan wrote: post #223

Earlier quoted context omitted.

Why are you sure, he was talking about vertices or 3D in general?

I was. But people are always missing a point. There's a range of options between "can render millions of objects with complex animation and logic " in a few milliseconds and "we will warn you when you have 800 dom nodes on a static page, you shouldn't do many updates or any useful animations" Somehow people assume that what HTML does is so insanely hard that the problem of 2D layout should not just be relevant to mod…

"The 2D layout in HTML is slow because the DOM (with the millions of conflicting hacks on top of it) is slow, not the other way around."

Well yeah, all those hacks of html that we cannot get rid of, because of backwards compatibility are probably the main reason the DOM is slow. HTML was made to view documents after all and not design UI's. And now it is, what it is. But there are options now!

So yes, it is definitely possible to build snappy 2D layouts. I build one with HTML, using only a subset and that worked out somewhat allright .. but now I am switching to WebGL. And there is a world in between in terms of performance.

Re: JavaScript Bloat in 2024

#227

Post by jkoudys »

thiht wrote: post #80
wruza wrote: post #35

Earlier quoted context omitted.

Pornhub will be run in incognito mode It’s not '80s anymore, nobody cares about your porn. I have bookmarks on the bookmarks bar right next to electronics/grocery stores and HN. And if you’re not logged in, how would PH and others know your preferences?

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

I'd never even heard of pornhub until you degenerates told me about it. I had to look it up. Apparently "porn" is short for "pornography"?

Re: JavaScript Bloat in 2024

#228

Post by ch_sm »

ffsm8 wrote: post #201
devjab wrote: post #52

Earlier 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…

I feel like the term SPA has since ceased to have any meaning with the HN crowd. I mean i do generally agree with your sentiment that SPAs are way overused, but several of the examples of TFA arent SPAs, which shoould already show you how misguided your opinion is. depending on the framework, SPAs can start at ~10KB. really, the SPA is not the thing thats causing the bloat.

You’re right. People miss that SPAs aren’t heavy by definition, but by accident and/or acquire bloat over time. You can totally have a super-useful, full featured, good looking and fast SPA in 150 KB gzipped including libraries. Only it takes knowledge and discipline to do that.

Re: JavaScript Bloat in 2024

#229

Post by qingcharles »

I work with newly-released prisoners and homeless people who are mostly on free Lifeline phones. They typically get 15GB of data a month. This is used up in 2-3 days on average. After that they can sometimes get 2G data, but it is impossible to use Google Maps to get to an interview, or even to download their email or fill out a job application online. Because the phone is no longer useable they often get lost or stolen.

I regularly come across web sites with >250MB home pages these days. It doesn't take many of those to kill your entire data allotment.

Re: JavaScript Bloat in 2024

#230

Post by jauntywundrkind »

It sucks that we blew up CDNs for security reasons.

How nice it would be if sites using React could use the React already in cache from visiting another site!

I keep wanting to have some kind of technical answer possible here. Seems hard. And who cares, because massive bundles are what we do now anyways, in most cases. But it sucks that the web app architecture and web resource architecture are both massively less capable than they were 20 years ago.

Post reply on HN