JavaScript Bloat in 2024 • Hacker News Board

Re: JavaScript Bloat in 2024

#201

Post by ffsm8 » Fri, Feb 23, 2024, 3:07 PM UTC

devjab wrote: post #52

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.

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.

Re: JavaScript Bloat in 2024

#202

Post by ezreth » Fri, Feb 23, 2024, 3:11 PM UTC

ozim wrote: post #136

figmert wrote: post #123

Earlier quoted context omitted.

> It’s like we suddenly and collectively became afraid of the page reload on websites I used to work at a place where page reloads was constantly an issue brought up as a negative. They couldn't be bothered to fix the slow page loads and instead avoided page changes. I argued several times that we should improve performance instead of caring about page reloads, but never got through to anyone (in fairness, it was pro…

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 but importantly, means you don’t have to be PCI DSS compliant yourself

Re: JavaScript Bloat in 2024

#203

Post by acdha » Fri, Feb 23, 2024, 3:42 PM UTC

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…

I think you’re using DOM to refer to the entire browser, not just what’s standardized as the DOM. Things like creating or modifying elements will run at tens of millions per second on an old iPhone _but_ there are operations like the one you mentioned which force the browser to do other work like style calculation and layout, and if you inadvertently write code which is something like “DOM update, force recalc, DOM update” in a loop it’s very easy to mistakenly think that the DOM is the source of the performance problem rather than things like the standard web layout process having many ways for different elements to interact.

And, yes, I’m not unaware that different display models have different performance characteristics. Modern browsers can run into into the millions of objects range but fundamentally a web page is doing more work and there’s no way it’s going to match something which does less. This is why there have been various ways to turn off some of the expensive work (e.g. fixed table layout) and when APIs like canvas, WebGL, and WebGPU use different designs to allow people who need more control to avoid taking on costs their apps don’t need.

Re: JavaScript Bloat in 2024

#204

Post by bmacho » Fri, Feb 23, 2024, 4:02 PM UTC

willsmith72 wrote: post #30

SebastianKra wrote: post #4

Any reason why we're looking at uncompressed data? Some of the listed negative examples easily beat GMaps 1.5mb when compressed. Also, I'll give a pass to dynamic apps like Spotify and GMail [1] if (and only if) the navigation after loading the page is fast. I would rather have something like Discord which takes a few seconds to update on startup, than GitLab, which makes me wait up to two seconds for every. single.…

gmail is terrible, idk if it's just me but i have to wait 20 seconds are marking an email as read before closing the tab. otherwise it's not saved as read spotify has huge issues with network connectivity, even if i download the album it'll completely freak out as the network changes. plain offline mode would be better than its attempt at staying online

gmail still has the HTML view: https://mail.google.com/mail/u/0/h?ui=html

They are saying since a while that they will shut it down in February. So it may only work for 1-2 days

Re: JavaScript Bloat in 2024

#205

Post by bmacho » Fri, Feb 23, 2024, 4:08 PM UTC

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.

My friend doesn't want porn to show up in the address bar, that's why she uses a different profile for it. Incognito mode is not good, since it actually forgets history and bookmarks.

Re: JavaScript Bloat in 2024

#206

Post by jitl » Fri, Feb 23, 2024, 4:22 PM UTC

hnarn wrote: post #90

guappa wrote: post #59

Earlier quoted context omitted.

> You can make 1MB of JS perform just as poorly as 10MB. But can you make a 10MB js perform as good as a good 1MB js?

I'm not a JS developer but I imagine that the amount of JavaScript code isn't the most relevant part if most of it isn't being called. I mean, if you have some particularly heavy code that only runs when you click a button, is that really parsed and causes overhead before the button is clicked?

Depending on how the code is loaded, yes.

If all 10mb is in a single JS file, and that file is included in a normal script tag in the page’s HTML, then parsing the 10mb will block UI interaction as the page loads.

Once the browser parses 10mb, it’ll evaluate the top level statements in the script, which are the ones that would set up the click event handler you’re referencing.

If the entire page is rendered by JavaScript in the browser, then even drawing the initial UI to the screen is blocked by parsing JS.

The solution to this for big apps is to split your build artifact up into many separate JS files, analogous to DLLs in a C program. That way your entry point can be very small and quick to parse, then load just the DLLs you need to draw the first screen and make it interactive. After that you can either eagerly or lazily initialize the remaining DLLs depending on performance tradeoff.

I work on Notion, 16mb according to this measurement. We work hard to keep our entry point module small, and load a lot of DLLs to get to that 16mb total. On a slow connection you’ll see the main document load and become interactive first, leaving the sidebar blank since it’s a lower priority and so we initialize it after the document editor. We aren’t necessarily using all 16mb of that code right away - a bunch of that is pre-fetching the DLLs for features/menus so that we’re ready to execute them as soon as you say, click on the settings button, instead of having awkward lag while we download the settings DLL after you click on settings.

Re: JavaScript Bloat in 2024

#207

Post by troupo » Fri, Feb 23, 2024, 4:28 PM UTC

acdha wrote: post #203

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…

I think you’re using DOM to refer to the entire browser, not just what’s standardized as the DOM. Things like creating or modifying elements will run at tens of millions per second on an old iPhone _but_ there are operations like the one you mentioned which force the browser to do other work like style calculation and layout, and if you inadvertently write code which is something like “DOM update, force recalc, DOM u…

> 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 DOM is not fast. It's excruciatingly slow even for the most basic of things. It's, after all, designed to display a small static page with one or two images, and no amount of haphazard hacks that accumulated on top of it over the years will change it. It will, actually, make it much worse :)

There is a reason why the same device that can render a million of objects doing complex animations and logic in under 5ms cannot guarantee smooth animations in DOM. This is a good example: https://twitter.com/fabiospampinato/status/17495008973007301... (note: these are not complex animations and logic :) )

Re: JavaScript Bloat in 2024

#208

Post by npteljes » Fri, Feb 23, 2024, 4:33 PM UTC

wruza wrote: post #189

npteljes wrote: post #181

Earlier quoted context omitted.

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

Yeah, it's not my favorite experience either, and I found it really hard to be indifferent, especially in my earlier years. The goal is almost never a perfect product. And it's also a result of many people's involvement, who often have different values than I do, or what I expect of them.

Re: JavaScript Bloat in 2024

#209

Post by troupo » Fri, Feb 23, 2024, 4:34 PM UTC

ozim wrote: post #136

figmert wrote: post #123

Earlier quoted context omitted.

> It’s like we suddenly and collectively became afraid of the page reload on websites I used to work at a place where page reloads was constantly an issue brought up as a negative. They couldn't be bothered to fix the slow page loads and instead avoided page changes. I argued several times that we should improve performance instead of caring about page reloads, but never got through to anyone (in fairness, it was pro…

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

Browsers have no good way of sandboxing external code. See the trouble that Figma went through to get plugins to work: https://www.figma.com/blog/how-we-built-the-figma-plugin-sys...

Re: JavaScript Bloat in 2024

#210

Post by npteljes » Fri, Feb 23, 2024, 4:44 PM UTC

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…

I think it serves as a generic metric for bloat, because nobody really optimizes for size, thereby making it a good untainted metric. As the web gets bloaty and slow, the size of the websites grow as well, which also invites using size as a metric for bloat.

Smooth, fast, nice, these would be good to measure, but it's much harder. I like an interface response time metric, for example [0]. I always lament that interfaces are getting slow - I get that they are nicer, too, but god damn why am I waiting 1 second for anything, when my Pentium III with Win XP was near instant?

[0] https://www.nngroup.com/articles/response-times-3-important-...