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 ca…
JavaScript Bloat in 2024
231–240 of 266 posts
Re: JavaScript Bloat in 2024
#232Re: JavaScript Bloat in 2024
#233Incredibly small JS / CSS bundles. Only loads what it needs.
Re: JavaScript Bloat in 2024
#234Earlier 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 worked in IT throughout high school and college. Trust me: Old married dudes it's a coin flip on if you're gonna get Pornhub or one of its neighbors that MindGeek owns in their bookmarks; if they didn't have it bookmarked, there's still a 50% chance that it's in the history. A surprising number of women had at least some porn in their history.
Re: JavaScript Bloat in 2024
#235Re: JavaScript Bloat in 2024
#236Earlier quoted context omitted.
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 DO…
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 on the order of hundreds of thousands element creations or updates per second in the mid-2010s – checking my logs, I was seeing 600k table rows added per second on Firefox in 2015 on a 2013 iMac (updates were much faster since they didn’t have as much memory allocation), and browsers and hardware have both improved since then.
To be clear, 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 – but that’s like complaining that a semi truck isn’t as fast as a Tesla. The web is centered on documents and text layout, so the better question is which one is fast enough for the kind of work you’re doing. If you need to move rectangles around, use WebGL - that’s why it exists! - but also recognize that you’re comparing unlike tools and being surprised that they’re different.
Re: JavaScript Bloat in 2024
#237> JavaScript is a universal metric for “complexity of interactions”. I don’t understand this claim in the slightest. It seems trivially falsified by the data that follows.
Re: JavaScript Bloat in 2024
#238Not surprised at all that JIRA is 50 MB, but still... What the fuck
Re: JavaScript Bloat in 2024
#239Earlier quoted context omitted.
however big, you're only required download an app once. Next time there is an update that you cannot download, generally that won't block you from using the app at that point in time.
It actually depends, developer can block you from using the app until you update, either themselves or through Play Store's 'Immediate updates'.
Re: JavaScript Bloat in 2024
#240Earlier quoted context omitted.
are you deliberately not getting the point for some reason? How big is considered bloated in native apps, how big can a native app can get before it hurts accessibility because people cannot download it? Is it a few MB? Web apps are soon going to be if not already matching native apps in terms of complexity yet we are still distracted from the real problem and quibble about some arbitrary and frankly pathetic code si…
> How big is considered bloated in native apps, how big can a native app can get before it hurts accessibility because people cannot download it? I'd say if it takes more than 50 megabytes to display a list of text, it's a problem :) > yet we are still distracted from the real problem Yes, I agree, "how broken the entire web stack" is the main problem. And the ungodly amounts of javascript you end up for the simplest…
replace javascript with any native programming language, this has been always a problem with UI programming, but it's not THAT big of a problem because in other platforms people download the app once, instead of every time. There is a long list of problems in software engineering, but sorry to disagree with you, "the binary/script is too big" is no where near the top.