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

241–250 of 266 posts

Re: JavaScript Bloat in 2024

#241

Post by Alifatisk »

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

> I like the conversation about web performance, but you should make sure you practice what you preach

I'd say the author is practicing what he preaches, the JS is just 4,6 kB. There is some optimizations [1][2][3] that can be done to the images but I wouldn't fully disqualify the article because of that. The websocket connection is kinda odd though, I tried reading the code but didn't fully catch the purpose, it just says something about pointers.

[1] https://www.youtube.com/watch?v=uqmgQB5Gyfo [2] https://www.youtube.com/watch?v=uqmgQB5Gyfo [3] https://www.youtube.com/watch?v=hJ7Rg1821Q0

Re: JavaScript Bloat in 2024

#242

Post by Alifatisk »

chuckadams wrote: post #25

Jeepers, how does this even happen? I've been developing a fairly complex app with Nuxt, Apollo client, and PrimeVue, and paid no attention to size whatsoever. Yet the most complex page in the app with the most module dependencies loads only 3.8 megs, and that's not even a minified build. Same page from the Nuxt dev server throws 24.4M at me, but I'm pretty sure it's pre-loading everything. Do the big players just no…

> On the other hand, node_modules weighs in at 601M.

Use pnpm and see the difference

Re: JavaScript Bloat in 2024

#245

Post by Alifatisk »

While I agree with the article, I am also obsessed with keeping the size as low as possible, I can't stop thinking about how it feels like the Author is somewhat mixing up webapps with websites.

Websites requiring that much JS for doing very simple static tasks is bloat, but the same bar should not be set for webapps. It should still be required and a high priority to keep the bundle size low but webapps should be considered as different category. Websites can (and should) function without JS, webapps cannot.

Another thing is that the Author only looked at the visible elements, for example on Google Translate and Outlook. What he did not consider is that there is a lot of more apps accessible behind the menus.

If you take a closer look at Outlook at first glance, sure, it's just a simple app to display your emails. But on the sidebar you have access to a lot more features like calendar, contacts and the office suite.

Re: JavaScript Bloat in 2024

#246

Post by troupo »

acdha wrote: post #236
troupo wrote: post #207

Earlier quoted context omitted.

> I think you’re using DOM to refer to the entire browser, not just what’s standardized as the DOM. No, I'm referring to DOM as Document Object Model. > Things like creating or modifying elements will run at tens of millions per second on an old iPhone Not in the DOM :) > but fundamentally a web page is doing more work and there’s no way it’s going to match something which does less. That's why I'm saying that the DO…

> No, I'm referring to DOM as Document Object Model. This is what I was talking about: you’re talking about the DOM but describing things like layout and rendering. Yes, nobody is saying that abstractions which do less won’t be faster - that’s why things like WebGL exist! – but most of the performance issues are due to things which aren’t supported in WebGL. If you aren’t using something slow like React you could do…

> This is what I was talking about: you’re talking about the DOM but describing things like layout and rendering.

Ah yes, because layout and rendering are absolutely divorced from DOM and have nothing to do with it :)

> that’s never going to catch up with WebGL for the kinds of simple things you’re focused on - displaying a rectangle which doesn’t affect its peers other than transparency is a really tuned fast path with hardware acceleration

You will never catch up with anything. It's amazing how people keep missing the point on purpose even if they eventually almost literally repeat what I write word for word, and find no issues with that.

Here are your words: "The web is centered on documents and text layout". Yes, yes it is. And it's barely usable for that. But then we've added lots of haphazard hacks on top of it. The rest I wrote here: https://news.ycombinator.com/item?id=39485437

Re: JavaScript Bloat in 2024

#247

Post by mortallywounded »

Alifatisk wrote: post #243
mortallywounded wrote: post #214

SPAs were a psyop by FAANG companies to gain a monopoly and mind-share of developer talent. Are you team Google (Angular)? Meta (React)? Are you a hipster (Ember)? From there things only went downhill faster.

Why did you leave out Vue?

It came after the first wave of SPAs and if we listed every SPA framework (or "library") we'd be here all day.

Re: JavaScript Bloat in 2024

#249

Post by tstenner »

ezreth wrote: post #202
ozim wrote: post #136

Earlier quoted context omitted.

Oh my god iframes should be removed from browsers so no one should be able to use them ever.

I think there are a couple of legitimate uses of iframes, but in most cases, it’s not something you want to use. If you want to take payments in your application using a vendor like Nodus, ie, if you have an app that is being used by a CSR/Salesperson, and they need to take CC or eCheck data, showing the payment application in an iframe (within the context of the app) lets you have that feature within the application…

Opening the payment flow in a separate window while displaying a message like "please complete the payment with your chosen payment provider" is almost as good from a usability standpoint and a lot better when considering security best practices.

Re: JavaScript Bloat in 2024

#250

Post by Tistron »

meowtimemania wrote: post #112
Tistron wrote: post #108

Earlier quoted context omitted.

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.

I get irritated by this too. When it happens I put my phone on airplane mode to force Spotify to show the offline ui.

Yeah, me too.

And vow to someday get around to finding a different music solution.

Post reply on HN