JavaScript Bloat in 2024
tonsky.me
tonsky.me
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.
There are many, many cases of porn websites breaking the law.
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 everything that came before. You’re free to insert Angular/Vue/whatever by the way. But these are designed to replace all the various horrible client/server UIs that came before. For a web-page that’s hardly necessary unless you’re g-mail, Facebook or similar, where you need the interactive and live content updates because of how these products work. But for something like pornhub? Well PHP serves them just fine, and this is true for most web sites really. Just look at HN and how many people still vastly prefer the old.reddit.com site to their modern SPA. Hell, many people still would probably still prefer an old.Facebook to the newer much slower version.
IF and only IF you have at least med- to high-end computer and smartphone. If you have low-end hardware you first have to wait for that 20MB to load AND get to use slow and choppy app afterwards. Worst of both worlds, but hey, it's built according to modern standards!
Kind of fun to make this argument for Pornhub when visiting their website with JavaScript disabled just seems to render a blank page :)
> how many people still vastly prefer the old.reddit.com site to their modern SPA
Also a fun argument, the times I've seen analytics on it, old.reddit.com seems to hover around/below 10% of the visitors to subs. But I bet this varies a lot by the subreddit.
Average people don't disable Javascript. So they predictably don't spend much time trying to make the site work for people who aren't their core audience.
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 probably mostly cos of a senior dev there).
At some point a new feature was being developed, and instead of just adding it to our existing product, it was decided to use an iframe with the new feature as a separate product embedded.
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
IMO the bloat he talks about on the post is not representative of 2024. Pretty much all frontend development of the last 2 years has been moving away from SPAs with smaller builds and faster loading times. Fair enough it's still visible in a lot of sites. But I'd argue it's probably better now than a couple years ago.
When people hate SPAs they actually hate terminally overweight abominations that no one (i.e. google) keeps in check, and that's the reason they are like that. Why should on-page interaction be slow or cost one 20MB of downloads? No reason. replaceChild() uses the same tech as <a href>. SPA is not a synonym for "impotent incompetence 11/10".
If humanity didn't invent SPAs, all these companies would just make half-a-minute loading .aspx-es instead. Because anything else they can not.
They... Don't :) The absolute vast majority of them is a shittier, slower, clunkier version of a native app
> IMO the bloat he talks about on the post is not representative of 2024. Pretty much all frontend development of the last 2 years has been moving away from SPAs with smaller builds and faster loading times.
He literally lists Vercel there. One of the leaders in "oh look at our beautiful fast slim apps". Their front page loads 6.5 megabytes of javascript in 131 requests to those smaller bundles.
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.
countless hours spent on optimising video delivery, live broadcasts (using flash back in the day, and webrtc today), web page sizes... the works.
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.
[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
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. click.
The current prioritisation of cold starts and static rendering is leading to a worse experience on some sites IMO. As an experiment, go to GitHub and navigate through the file tree. On my machine, this feels significantly snappier than the the rest of GitHub. Coincidentally, it's also one of the only parts that is not rendered statically. I click through hundreds of GitHub pages daily. Please, just serve me an unholy amount of JavaScript once, and then cache as much as possible, rather than making me download the entire footer every time I want to view a pipeline.
[1]: These are examples. I haven't used GMail and Spotify
https://infrequently.org/2024/01/performance-inequality-gap-...
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.
Finding those things was only possible by looking at the profiler. I don't think general statements like "less JS = better" help anyone. It helps to examine the size of webpages, but then you have to also put that information into context: how often does this page load new data? once the data is loaded, can you work without further loading? Is the data batched, or do waterfalls occur? Is this a page that users will only visit once, or do they come regularly? ...
I totally agree - my point was simply that people sometimes focus on network bandwidth and forget that a huge JS file can be a problem even if it’s cached. What you’re talking about is the right way to do it - I try to get other developers to use older devices and network traffic shaping to get an idea for those subjective impressions, too, since it’s easy to be more forgiving when you’re focused on a dedicated testing session than, say, if you’re trying to use it while traveling and learning that the number of requests mattered more than the compressed size or that you need more robust error handling when one of the 97 requests fails.
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 twice.
I found the chrome dev tools to be really helpful with spotting those and other stuff. But sure, if you update EVERYTHING anyway, including waiting for the whole data transfer, with any click, when you just want some tiny parts refreshed, you have other problems anyway.
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.
It's faster 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 fast".
> and also that as people started using heavier frameworks they started losing track of what triggers updates.
I don't know if you realise, but on the very same devices where you're complaining about "large pages and oh my god layout" people are routinely rendering millions of objects with complex logic and animations in under 5 milliseconds?
The DOM is excruciatingly slow.
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.
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 :) )
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.
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
With all due respect, if you compare that to 2D layouting and stuff, you don’t know much about the topic.
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
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.
You have to make regular bundle analysis otherwise the cache won't work if you deploy too much and package updates and new additions are likely to break the performance analysis you've just made before.
Less JS = better performance is a simplified model but very accurate in practice in my opinion, especially on large teams.
But can you make a 10MB js perform as good as a good 1MB js?
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.
Substack is particularly infuriating : sometimes it lags so badly that it takes seconds to display scrolled text (and bottom of text references stop working). And that's on a 2016 flagship : Samsung Galaxy S7 ! I shudder to think of the experience for slower phones...
(And Substack also manages to slow down to a glitchy crawl when there are a lot of (text only !) comments on my gaming desktop PC.)
And it's also the only part of it that doesn't work on slow connections.
I've had a slow internet connection for the past week, and GitHub file tree literally doesn't work if you click on it on the website, because it tries to load it through some scripts and fails.
However, if, instead of clicking on a file, I copy it's url and paste it into the browser url bar, it loads properly.
But actually, that first click from the overview is still an HTML page. Once you're in the master-detail view, it works fast even when throttled.
Because for a single page load, decompressing and using the scripts takes time, RAM space, disk space (more scratch space used as more RAM gets used), and power (battery drain from continually executing scripts). Caching can prevent the power and time costs of downloading and decompressing, but not the costs of using. My personal rule of thumb is: the bigger the uncompressed Javascript load, the more code the CPU continually executes as I move my mouse, press any key, scroll, etc. I would be willing to give up a bit of time efficiency for a bit of power efficiency. I'm also willing to give up prettiness for staticness, except where CSS can stand in for JS. Or maybe I'm staring at a scapegoat when the actual/bigger problem is sites which download more files (latent bloat and horrendously bad for archival) when I perform actions other than clicking to different pages corresponding to different URLs. (Please don't have Javascript make different "pages" show up with the same URL in the address bar. That's really bad for archival as well.)
Tangent: Another rule of thumb I have: the bigger the uncompressed Javascript load, the less likely the archived version of the site will work properly.
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
Maybe that’s related?
They are saying since a while that they will shut it down in February. So it may only work for 1-2 days
Yes; this started happening after they rolled out the new version of their UI built with React several months ago.
The data transferred is going to be almost entirely analytics and miscellaneous 3rd party scripts, not the javascript actually used to make the page work (except for the "elephant" category which are lazy loading modules i.e. React). Much of that is driven by marketing teams who don't know or care about any of this.
All devs did was paste Google Tag Manager and/or some other script injection service to the page. In some cases the devs don't even do that and the page is modified by some proxy out in the production infrastructure.
Maybe the more meaningful concern to have is that marketing has more control over the result than the people actually doing the real work. In the case of the "elephant" pages, the bloat is with the organization itself. Not just a few idiots but idiots at scale.
google tag manager is the best tool for destroying your page performance, previous job had google tag manager in the hands of another non-tech department. I had to CONSTANTLY monitor the crap that was being injected in the production pages. I tried very hard to get it removed.
Also if any spotify PMs are here, please review the Offline UX. Offline is pretty much one of the most critical premium features but actually trying to use the app offline really sucks in so many ways
So much agree here, the offline mode is so beyond being annoying so I even started building my own iOS offline first music app.
Sadly ironic that apple used to sell this, in the shape of an ipod!
I hold on to mine, it is perfect in every way that a phone is terrible.
It is tiny and 100% offline, just what I need.
Maybe OP was talking specifically about the behaviour of Spotify?
Also, Spotify (at least on iOS) seems to have fallen into the trap of thinking there is only "Online" and "Offline", so when you're in-between (really high latency, or really lossy connection), Spotify thinks it's online when it really should be thinking it's offline.
But to be fair, this is a really common issue and Spotify is in no way alone in failing on this, hard to come up with the right threshold I bet.
And vow to someday get around to finding a different music solution.
Especially annoying when one is using dns based filtering.
Please Spotify, why do I need to wait 30 seconds for the app to load anything when I don't have signal? All I want to do is keep listening to a podcast I downloaded.
Well, with Youtube Premium you can actually download videos in advance and watch them on the go w/o Internet access required.
It will even download videos in the background it thinks you will enjoy, so you don't even need to manage anything.
Almost none of those are loaded in the initial bundle, are they? All those come as data from the server.
How much JS do you need for `if data.transliteration show icon with audio embed`?
In my testing, at least some input methods are indeed included in the initial requests (!). And that's why I'm stressing it is not "one-interaction" app; it is interactive enough that some (but not all) upfront loading might be justifiable.
Whats worse is some of them are fetched externally rather than bundled with the host code thus increasing latency and potential security risks
Some vendor SDKs can be built and bundled from NPM, but most of them explicitly require you fetch their minified/obfuscated bundle from their CDN with a script tag. This is so they don't have to support older versions like most other software in the world, and so they can push updates without requiring customers to update their code.
Try to use vendors that distribute open-source SDKs, if you have to use vendors.
it would be almost impossible to measure success without it, whether it's a conversion funnel or tracking usage of a new feature
If it is put in by a developer, the budget for that is like an hour to copy paste the code snippet in the right spot. Few are going to pay the hours required for an in house data collection layer that then has to integrate with the third party if that's even an option.
At least that is my experience through agency work. Maybe a product owner company could do it.
Not to be rude to the industry either, but I don't see why the assumption would bet that an in house dev has the chops to not make the same mistakes a third party does.
earlier in the conversation someone talked about pasting a snippet. We're talking about the "chops" to not paste a snippet that is hundreds of thousands of lines long. A snippet so long it would crash many editors.
It is very common to get multiple departments and contracted companies sticking their misc JS in since every marketing SaaS tool they use has it's own snippet. Your SEO guy wants 3 trackers, your marketing has another 5, and you sell on XYZ online market and they have affilliate trackers etc.
No devs engaged at any point and the site performance isn't their responsibility. They can't do their job without their snippets so the incentives are very sticky, and the circus goes on.
It's kind of like an NPM dependency tree of martech SaaS vendors...
The major players here are explicitly not anonymous, they are designed to keep track of people over time so that they can collate habits and preferences across different sites to better target advertising. Yes, your AB test script isn't doing the same thing, but is it really adding any value to be as a consumer, or is it just optimising an extra 0.01% revenue for you?
After those things it is the heavy libs that cause performance problems, like maps and charts, usually some clever lazy loading fixes that. Some things I personally ran into: - QR code scanning lib and Map lib being loaded at startup when it was actually just really small features on the application - ALL internationalisation strings being loaded at startup as a waterfall request before any other JS ran. Never managed to get this one fixed... - Zendesk just completely destroys your page performance, mandated through upper-management, all I could do was add a delay to load it
After that then it comes just badly designed code triggering too many DOM elements and/or rerenders and/or waterfall requests.
After that comes app-level code size, some lazy loading also fixes this, but it is usually not necessary until your application is massive.
- PornHub loads ~10x less JS than YouTube (1.4MB vs 12MB)
- Gmail have an incomprehensible large footprint (20MB). Fastmail is 10x ligthter (2MB). Figma is equivalent (20MB) while being a more complex app.
- Jira has 58MB (whoa)
I just tested my connection to youtube right now, just a tiny bit over 1.2 seconds from not using it for a few days. A fresh, no cache, no cookies, the entire page loaded in 2.8 seconds. A hot reload on either side varied between 0.8s to 1.4 seconds. All done with at most ublock as an extension on desktop chrome with purported gigabit speeds from my ISP.
That speed is just OK, but definitely not the 54ms response time I got to hit google's server to send me the HTML document that bears all the dynamic content on youtube
Figma is very surprising to me, that bullshit somehow is PREFERRED by people, getting links from designers from that dogshit app screeches my browser to speeds I haven't seen in decades, and I don't think I'm exaggerating at all when I say that
Youtube hasn't felt snappy in ages
Maybe you should take a look on the Network Tab, because Atlassian sure does have a crappy network stack.
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?
But I still find going incognito to watch porn paranoid.
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.
Must be fun at work zoom meeting when you share the browser window!
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 reduction. The code is perfectly readable when opened with the "View page source" button.
The trick is - zero dependency policy. No third party, no internal. All the code you need, you get along with the HTML file. Paradoxically, in the long run, copy-paste is a bloat preventor, not a bloat cause.
Is it foolish to say that in 10 more years you wont be able to navigate the web on a circa 2015 PC ? If nothing changes seems like it.
My old macbook from 2013 with latest Firefox is already can not handle loading https://civitai.com web page with 23.98 MB of JavaScript, it is just hangs for half a minute while trying to render this disaster of web frontend.
It is not just web, mobile all in one apps got so large that 2013 phone the same way unable to load them, and guess what, half of them are written on top of web tech stack, why three comma ,,, budget companies can not afford to write native application ?
[1] https://idlewords.com/talks/website_obesity.htm
[2] https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
Would love to see this test with Ublock origin enabled.
Me too. I suspect most of this code is for user tracking and ad management.
What happens when you use modern apps on iphone 3 or first nexus phone? I don't understand, do people think that with better, faster computers and network speed we should focus on smaller and smaller apps and websites?
You may also one day find yourself on a flaky 3G connection needing access to some web app that first loads twenty megabytes of junk before showing the 1 kB of data you need, and then it's clearer what the problem is here.
To the point where the web is mostly unusable if you don't disable ads. I'm not against ads, but the cost is just to high for my day to day use of internet.
Recently I had to add a couple of mechanics into sd-web-ui, but found out that the "lobe theme" I used was an insufferable pile of intermingled React nonsense. Returned to sd-web-ui default look that is written in absolutely straightforward js and patched it to my needs easily in half an hour.
This is a perfect example based on a medium-size medium-complexity app. Most sites in TFA are less complex. The delusions that frontend guys are preaching are on a different level than everything else in development.
The median JS bundle is 600kB on desktop. p90 (“high 10%”) is 1830kB.
I like the conversation about web performance, but you should make sure you practice what you preach
I just measured it on my mbp and "720px" is actually... 1440 physical pixels. I was surprised too!
But is such a high resolution really needed?
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
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.
I don’t understand this claim in the slightest. It seems trivially falsified by the data that follows.
Anything homemade performs faster than ever though, so engines are getting better but my code has stayed as simplest as ever and finding improved performance.
Maybe, just maybe, the problem isn't the size of the javascript, it's how broken the entire web stack (specifically caching & PWA) is, that makes a trivial thing like code size a problem.
But I am old enough to remember Gannt charts didn't use to take that long on old Pentium processors back in school, way before Git was invented.
Another thing is the sheer yuck of it:
If a typical web app was lots of business code, maybe. But when you look at the network tab and it feels like you are looking at the hair ball from a sink drain, lots of intertwined trackers to catch everything that passes, that is another story.
Could you give an example? I was an android app dev over 5 years ago and there was a huge push for lower app size everywhere. Google even made Android App Bundles to fight this issue specifically.
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 size restriction. Fix the root problem with PWA or something.
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 problems is the symptom. However, neither caching nor PWA are the specific main problems in the web's brokenness :)
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.
I just checked my web usage on my work computer. The last 120k opened URLs were on 8300 unique hosts. 8300 * 50MB is not feasible.
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.
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.
If you untick "Disable cache", it's loaded once and gets cached.
The only case when this code gets loaded is the literally the first cold load of the entire site — and it's only used for powering live editable interactive sandboxes (surely you'd expect a in-browser development environment to require some client-side code). It doesn't block the initial rendering of the page.
What is the problem?
Also, FWIW, OP is one of the authors of react.dev and a member of the react core team (not that it's relevant to the objection).
On the other hand, node_modules weighs in at 601M. Sure I've got space to burn on the dev box, but that's reason #1 I'm not doing yarn zero-install and stuffing all that into the repo.
Use pnpm and see the difference
Incredibly small JS / CSS bundles. Only loads what it needs.
Still sucks, but it's 700MB RAM vs 1.4GB just to open a chat.
I've used a number of interoffice communication apps, and was on IRC in the hey days of dialup.
Slack (for work purposes) just nails the experience for a broad set of users.
This is embarrassing...
The author could've scrolled forever and the number would've gone up indefinitely.
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.
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.
2) Rather, we intentionally unload interactive editor preview iframes to improve memory usage when you scroll away from them. We do load them again when you scroll up — and normally that would be instant because the code for them would get cached. But the author has intentionally disabled cache, so as a result they get arbitrarily high numbers when scrolling up and down.
Modern frameworks are definitely needed for large applications, but there is no need all that complexity when the scope is reduced.
The thing is; I didn't use any bundling or minification. Also, it loads faster than most of the websites mentioned in this article and that's with minimal optimizations and my server being located on the other side of the world.
Are you team Google (Angular)? Meta (React)? Are you a hipster (Ember)?
From there things only went downhill faster.
This puts it into perspective. I heard complaints about ClojureScript applications being large, which I think is true if you write a "Hello, world!" program, but not true for complex applications.
Also, Google Closure compiler in advanced compilation mode is a great tool. Of course, since it is technically superior, it is not in fashion, and since it is hard to use correctly, people pretend it isn't there.
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 (hint: look at how big games have become, is it only textures though?).
"But JS is the biggest developer ecosystem in the world!"
These are hard problems and people have been complaining about software size forever. Back in the early 90s, it was bloated C++ code.
You will also see that all software continues to use more ram, more disk space, more network bandwidth etc. This trend has been going on for decades.
For example, why do we use JSON as an interchange format? It’s relatively slow (i.e. creating it and parsing it is slow), nor is it is not space efficient. Back in the 1980s, the Unix community created RPC and the RPC wire formats were much more efficient because they were binary formats. The reason we use JSON is it makes the developer’s life easier and because developers prefer ease of use to performance.
It's very hard to, unless there is a risk to the bottom line.
Let me pose it differently--apparently ZED is ridiculously fast code editor. Do I want to switch from my vscode investment? Or will I deal with the "bloat"
I don't understand why you'd consider this "low hanging fruit". What could the author have done to make it a high quality submission in your eyes?
The alternative is to have more awareness of the amount of dependencies you really need, of when you actually need a framework with a runtime, and so on. He mentioned a fair share of essentially static landing pages that really have no reason to ship so much crap. And even though it's not explicitly mentioned: this isn't just a potential issue for end users. This code likely makes life hard for the developers as well. With every dependency you get more potential for breaking changes. With every layer it gets harder to understand what's going on. The default shouldn't be to just add whatever you want and figure it out later, the default should be to ask yourself what really needs to be added. Both in terms of actual code, but also layers, technologies, frameworks, libraries.
Well if you have static pages you don't need a team of 10 developers… so there is some self interest there.
The article is just a lot of vague pointing at sites and insinuating (not even asserting) that they're too bloated or not. I don't get a sense of whether it's worse that Medium ships 3mb of code or Soundcloud ships 12. There's a lot of bad faith "this is just a text box" for sites which clearly do much more than that too.
No. No it wouldn't. It's not the job of strangers on the internet to do the job of incompetent developers.
> Or to find out why it might be that some landing pages are shipping a lot of JS (could be because they are landing pages for web apps?)
How does being a landing page for a web app excuse downloading 6-10 MB of javascript to show two pages of static text and images?
> Or consider performance more holistically (are pages shipping a lot of code, but lazy loading or otherwise optimising it so that pages still perform well?).
Here's a holistic overview of performance: The Performance Inequality Gap, 2024 https://infrequently.org/2024/01/performance-inequality-gap-...
> There's a lot of bad faith "this is just a text box" for sites which clearly do much more than that too.
Not clearly. Not clearly at all.
---
Edit: note on the incompetence.
If you embed Youtube player in your website, Lighthouse will scream at you for being inefficient and loading too many resources. Nearly all of those issues will come from youtube.
Lighthouse will helpfully provide you with a help page [1] listing wrappers developed by other people to fix this. Chrome's "performance lead" even penned an article[2] on lazy loading iframes and linked to a third-party youtube wrapper which promises 224x speed up over the official embed.
They know. They either are so incompetent that they cannot do the job themselves, or they don't care.
[1] https://developer.chrome.com/docs/lighthouse/performance/thi...
[2] Over at webdev: https://web.dev/articles/iframe-lazy-loading pointing to https://github.com/paulirish/lite-youtube-embed
BTW. web.dev is created by web devs at Google. Promoting web development best practices. It takes it ~3 seconds to display a list of articles and the client-side only navigation is broken https://web.dev/articles
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 alternative.[1]
Now they are slowly evaporating: not because of lack of interest, but because it was affecting the margins of these companies, and they actively blocked the frontends.[2]
So I think of it this way: these megabytes and megabytes of JS do not serve me, the user. It's just code designed to fill the pockets of giant corporations that is running on my computer. Which is, indeed, quite infuriating.
OK, maybe not even that; after all, you get what you pay for. It's just sad that despite the technological possibilities, this is the norm we have arrived at.
[0]: Of course, there is valid use of JS, it's a wonderful technology. I'm talking about cases where you could pretty much write the whole thing in pure HTML without losing core functionality.
[1]: Well, only if there existed a viable financing model besides "selling user data to the highest bidder" :( technologically at least, it's possible.
[2]: See cases of bibliogram, teddit, libreddit, nitter, ...
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.
An absurd, idiotic situation that is endemic to the whole industry deserves every bit of scorn and ridicule. Developers need to be educated about this so they can make the right choices, instead of remaining complacent agents of a shameful situation. It also strengthens my own resolve to support (through my use) those websites that abide by the original principles of the web: they either deliver actual documents (instead of javascript apps), or offer public APIs to access the plaintext data. There is always an alternative out there.
Speaks more to the general Enshitifcation of the web.
Does Web 3.0 fix this? /s
Throttling the network to "Slow 3G", it took over four minutes of a broken interface before ffmpeg finally loads. (It doesn't cache, either.) A port of the Audacity audio editor to web[1] with WASM takes 2.7 minutes on the same connection, so the binary is totally reasonable, but I think claiming less than 2 MB is disingenuous.
Is the problem here that they perform poorly on slower computers/connections? Is it even true? Is there an audience of developers who can't use Vercel or GitLab productively because of that? Any metrics to support that? IMHO optimizing against bundle size/JS sent over the network is one of the worst metrics for performance I could imagine.
Focusing on a particular metric for the sake of the metric - what's the point?
Let's spend a couple months, refactor an app to generate less js just to look cool in the eyes of dev community?
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-...