A Rant About Javascript Bloat - CourtneyR.dev's 2nd Brain

A Rant About Javascript Bloat ![rw-book-cover](https://img.youtube.com/vi/1t-k6-m50Fc/maxresdefault.jpg) 🔗 **Source:** [A Rant About Javascript Bloat](https://www.youtube.com/watch?v=1t-k6-m50Fc) > [!note]+ Document Notes > tags: #javascript #npm #bloat #performance #dependency-management > author: Theo - t3.gg > source: YouTube > reference: https://www.youtube.com/watch?v=1t-k6-m50Fc > date created: 2025-01-02 10:30 > > # 🏷️ Title: A rant about Javascript bloat >  ## 🧰 Action Inbox - [H1] Audit dependency trees using E18 CLI analyze mode — identify redundant packages #dependency-management - [H2] Install NIP tool to find unused code and dependencies — reduce bundle size #performance - [H3] Support E18 Foundation financially — critical ecosystem cleanup work #open-source ## 🧭 Table of Contents - [[#📝 Summary]] - [[#📖 Main Content]] - [[#🗒️ Notes]] - [[#📚 References]] - [[#🗣️ Paraphrase]] - [[#📰 Newsletter]] - [[#✅ Action Items]] - [[#🧪 Hypotheses]] - [[#📊 Methodology]] - [[#❓ Questions]] - [[#🔮 Future Research]] - [[#💡 Implications]] - [[#🧠 Learning Styles Assessment]] - [[#📊 Accessibility Assessment]] - [[#🌍 DEIB Assessment]] - [[#✅ Logical Validity]] - [[#🛡️ DARVO Analysis]] - [[#🎯 Conclusion]] ### 🔗 References - [Three Pillars of JavaScript Bloat](https://npmjs.dev) by James Garbet - [E18 Foundation](https://eslint.org/blog/2024/09/eslint-officially-becomes-open-collective/) - [Module Replacements Project](https://github.com/es-tooling/module-replacements) ## 📝 Summary - JavaScript ecosystem suffers from massive dependency bloat with millions of unnecessary downloads weekly - Three main causes: legacy runtime support, atomic architecture, and outdated polyfills/ponyfills - Most bloat exists to support tiny niche use cases while entire ecosystem pays the cost - Solutions include E18 Foundation cleanup initiative, NIP tool, and module replacement projects - Community needs to audit dependencies and financially support ecosystem maintenance ## 📖 Main Content JavaScript dependency bloat has reached crisis levels, with packages like `is-string` requiring extensive dependency trees and simple utilities being downloaded millions of times weekly. James Garbet's analysis identifies three primary causes: **Legacy Runtime Support**: Packages maintain compatibility with ancient engines like IE6-7 and Node 0.4, requiring complex polyfills and primordial protections. Companies like Hero Devs specialize in maintaining these legacy codebases, but their requirements shouldn't dictate mainstream package architecture. **Atomic Architecture**: The philosophy of breaking code into microscopic, reusable packages has created absurd situations like `shebang-regex` (2 lines, 133M weekly downloads) and `slash` (96M weekly downloads). These "building blocks" rarely get reused as intended and increase supply chain attack surface. **Outdated Ponyfills**: Packages continue shipping fallback implementations for features supported natively for over a decade, like `Array.prototype.indexOf` (supported since 2010) still getting 2.3M weekly downloads. The E18 Foundation leads cleanup efforts through tools like their CLI analyzer and the Module Replacements project, helping identify and migrate away from bloated dependencies. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/1t-k6-m50Fc?t=0) — [H1] JavaScript bloat crisis introduction - Key idea: Most JavaScript shipped on web is unnecessary bloat costing entire ecosystem - Evidence: "Most of the JavaScript that's being shipped around the web is almost entirely unnecessary" #### ⏱️ [02:14](https://youtu.be/1t-k6-m50Fc?t=134) — [H2] Three pillars article by James Garbet - Key idea: Systematic breakdown of bloat types needed to identify and fix problems - Evidence: James works on "ecosystem performance things, just trying to make our JavaScript ecosystem better" #### ⏱️ [04:23](https://youtu.be/1t-k6-m50Fc?t=263) — [H1] Legacy runtime support pillar - Key idea: Complex dependency chains exist primarily for ancient engine compatibility - Evidence: `is-string` package requires extensive dependency tree just for type checking #### ⏱️ [06:45](https://youtu.be/1t-k6-m50Fc?t=405) — [H2] Hero Devs company example - Key idea: Specialized companies maintain legacy codebases requiring ancient compatibility - Evidence: "They have forks of things like NodeJS 0.8 that bring in security fixes" #### ⏱️ [09:12](https://youtu.be/1t-k6-m50Fc?t=552) — [H2] Node.js primordials protection - Key idea: Node rebinds globals at startup to prevent user code from breaking internals - Evidence: "Node keeps a reference to those original versions of things like map" #### ⏱️ [11:30](https://youtu.be/1t-k6-m50Fc?t=690) — [H3] Cross-realm value problem - Key idea: Values passed between iframes/realms require special instanceof-free checking - Evidence: "new Array in an iframe is not the same thing as Array class as parent page" #### ⏱️ [15:45](https://youtu.be/1t-k6-m50Fc?t=945) — [H1] Atomic architecture pillar - Key idea: Breaking packages into microscopic pieces creates absurd dependency bloat - Evidence: "shebang-regex" is 2 lines downloaded 133 million times weekly #### ⏱️ [18:20](https://youtu.be/1t-k6-m50Fc?t=1100) — [H2] Ridiculous package examples - Key idea: Simple utilities become separate packages with massive download numbers - Evidence: "slash" replaces backslashes, downloaded 96 million times weekly #### ⏱️ [20:15](https://youtu.be/1t-k6-m50Fc?t=1215) — [H2] Sindre Sorhus package statistics - Key idea: Single developer's packages downloaded nearly 10 billion times weekly - Evidence: "his packages are downloaded almost 10 billion times per week" #### ⏱️ [22:30](https://youtu.be/1t-k6-m50Fc?t=1350) — [H3] Single-use package problem - Key idea: Many atomic packages only used by one consumer, defeating reusability purpose - Evidence: "shebang-regex almost solely used by shebang-command by same maintainer" #### ⏱️ [25:10](https://youtu.be/1t-k6-m50Fc?t=1510) — [H1] Ponyfills pillar - Key idea: Polyfill alternatives that overstay welcome after native support widespread - Evidence: "global-this" package gets 49M downloads weekly despite 2019 native support #### ⏱️ [28:45](https://youtu.be/1t-k6-m50Fc?t=1725) — [H2] Solutions and tools - Key idea: E18 Foundation provides tools to identify and replace bloated dependencies - Evidence: CLI can "suggest native style text instead of colors library" #### ⏱️ [30:00](https://youtu.be/1t-k6-m50Fc?t=1800) — [H1] Financial support call - Key idea: Ecosystem cleanup work requires funding to be sustainable - Evidence: Theo donates $5,000 to E18 Foundation with $17,000 total balance ## 📚 References - [Three Pillars of JavaScript Bloat](https://npmjs.dev/blog/the-three-pillars-of-javascript-bloat) - [E18 Foundation](https://eslint.org/) - [NIP - Find unused dependencies](https://github.com/webpro/knip) - [Module Replacements Project](https://github.com/es-tooling/module-replacements) - [npmxs - Package explorer](https://npmjs.dev) ## 🗣️ Paraphrase - JavaScript ecosystem drowns in unnecessary dependencies created for niche compatibility requirements that affect entire community - Three main bloat sources: ancient browser support, over-atomized packages, and outdated polyfills that never got removed - Simple solutions exist through tools like E18 CLI and NIP, but require community effort to audit and migrate dependencies ## 📰 Newsletter **JavaScript Dependency Bloat: Time for Spring Cleaning** The JavaScript ecosystem has a weight problem. Packages downloaded millions of times weekly often contain just 2 lines of code or support browsers from 2006. James Garbet's analysis reveals three main culprits: legacy compatibility, over-atomized architecture, and outdated polyfills. **What This Means for WordPress Developers:** Many WordPress tools and plugins inherit this bloat through their JavaScript dependencies. The E18 Foundation provides tools to audit your dependency trees and find modern replacements. **Action Steps:** - Use NIP tool to find unused dependencies in your projects - Check the Module Replacements project for better alternatives - Support ecosystem cleanup efforts financially when possible **Resources:** [E18 Foundation](https://eslint.org/), [NIP Tool](https://github.com/webpro/knip), [Module Replacements](https://github.com/es-tooling/module-replacements) ## ✅ Action Items #### Community - Contributors: Audit project dependencies using E18 CLI analyze mode - Maintainers: Remove ponyfills for features with widespread native support - Sponsors: Financial support for E18 Foundation ecosystem cleanup work #### WordPress - Core: Review JavaScript dependencies in wp-admin and block editor - Performance: Integrate dependency bloat analysis into performance budgets - Community: Education about dependency management best practices #### OSPO - Software Inventory: Include bloat analysis in SBOM generation - Developer Support: Training on dependency hygiene and modern alternatives - Policy & Governance: Guidelines for dependency selection and maintenance ## 🧪 Hypotheses - Dependency bloat primarily serves edge cases while imposing costs on mainstream users - Atomic package architecture increases security vulnerabilities without providing reusability benefits - Native browser features adoption could eliminate 80% of current polyfill downloads - Financial incentives could accelerate ecosystem cleanup efforts significantly ### 📊 Methodology - Weekly download statistics analysis from npm registry - Dependency tree mapping using tools like npm-graph - Native feature support timeline correlation with package usage - Supply chain attack surface measurement by package count ### ❓ Questions - How can package managers better handle version resolution to reduce duplication? - What governance models would prevent niche requirements from becoming ecosystem defaults? - Could bundlers automatically detect and remove unnecessary polyfills based on target environments? ### 🔮 Future Research - Automated bloat detection and migration tooling development - Supply chain security impact measurement of atomic package architecture - Developer behavior analysis around dependency selection criteria ### 💡 Implications - Practice: Regular dependency audits become essential development hygiene - Policy: Package registry governance needs mechanisms to prevent ecosystem-wide bloat - Security: Smaller dependency trees reduce attack surface and maintenance burden - Education: Developers need training on modern JavaScript features and alternatives - Funding: Ecosystem maintenance requires sustainable financial support models ### 🧠 Learning Styles Assessment Reading level estimate: 12th grade (technical content with clear explanations) #### 👀 Visual learners - Present: Dependency tree diagrams, download statistics charts - Improve: Bloat impact visualizations, before/after migration diagrams #### 🔊 Aural learners - Present: Video format with clear narration and examples - Improve: Podcast version focusing on key concepts #### 🗣️ Verbal learners - Present: Clear explanations of technical concepts, real-world analogies - Improve: Glossary of package management terms, comparison frameworks #### 🧩 Kinesthetic learners - Present: Tool demonstrations, CLI command examples - Improve: Hands-on dependency audit workshop, migration checklists #### 🧠 Logical learners - Present: Systematic categorization of bloat types, cause-effect analysis - Improve: Decision trees for package selection, ROI calculations #### 🧑‍🤝‍🧑 Social learners - Present: Community discussion, collaborative problem-solving - Improve: Dependency review peer groups, shared audit results #### 🧘‍♀️ Solitary learners - Present: Individual analysis tools, self-directed exploration - Improve: Personal dependency hygiene checklists, reflection prompts #### 🌿 Naturalistic learners - Present: Ecosystem health analogies, organic growth patterns - Improve: Environmental impact of code bloat, sustainability metrics ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Clear heading structure, descriptive text for statistics - Improve: Alt text for dependency diagrams, table headers for package data #### Keyboard navigation - Present: Standard video controls, linked resources accessible - Improve: Skip links for long technical sections, focus indicators #### Contrast and readability - Present: High contrast code examples, clear typography - Improve: Color alternatives for syntax highlighting, increased line spacing #### Text resizing and reflow - Present: Responsive design handles zoom appropriately - Improve: Ensure code blocks remain readable at 200% zoom #### Media and captions - Present: Audio content with clear speech - Improve: Captions for technical terminology, transcript with timestamps #### Forms and interactions - Present: Functional links and navigation - Improve: Clear button labels for tool interfaces ### 🌍 DEIB Assessment #### Cultural breadth - Present: Technical content accessible globally - Improve: Examples from diverse development contexts, non-US-centric references #### Inclusive language - Present: Gender-neutral technical discussion - Improve: Define technical jargon, avoid cultural idioms #### Neurodiversity support - Present: Clear section breaks, consistent structure - Improve: Executive summaries, visual content organization #### Representation - Present: Focus on technical merit over personalities - Improve: Acknowledge diverse contributor perspectives #### Psychological safety - Present: Constructive criticism of technical choices - Improve: Frame problems as systemic rather than individual blame ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Clear categorization of bloat types with specific examples - Inductive strength: Pattern recognition across multiple package examples - Causal reasoning: Direct connection between niche requirements and ecosystem costs - Analogical strength: Effective comparisons to supply chain and environmental concepts #### Fallacies - Hasty generalization: Some broad claims about "most JavaScript" could use more statistical backing - Appeal to authority: Heavy reliance on single expert opinion, though well-credentialed #### Tone of voice - Overall tone: Passionate but constructive criticism with clear solution focus ### 🛡️ DARVO Analysis - Deny: No denial patterns present - Attack: No attacks on individuals, focus on systemic issues - Reverse victim/offender: No victim/offender dynamics - Emotional cues and rhetoric: Passionate advocacy for ecosystem health, constructive frustration ## 🎯 Conclusion JavaScript dependency bloat represents a tragedy of the commons where niche requirements impose costs on the entire ecosystem. The path forward requires systematic identification of unnecessary dependencies, migration to modern alternatives, and sustainable funding for maintenance work. The E18 Foundation's cleanup initiative demonstrates that coordinated community effort can address these systemic problems, but success depends on widespread adoption of better dependency hygiene practices and financial support for ecosystem stewardship. ## 🧱 Refactor Appendix ### 📚 Literature Split Pad ### [H1] Legacy compatibility creates ecosystem-wide dependency bloat > [!quote] [A rant about Javascript bloat](https://www.youtube.com/watch?v=1t-k6-m50Fc) by [[Theo - t3.gg]] via [[YouTube]]. Published 2025-01-02. Accessed 2025-01-02. > "The tiny group of people who actually need this stuff should be the ones seeking out special packages for it." Analysis of how Hero Devs and similar legacy maintainers force their requirements onto mainstream packages. [view highlight](https://youtu.be/1t-k6-m50Fc?t=945) #dependency-management #javascript ID:rw_001 ### [H2] Atomic package architecture defeats its own reusability purpose > [!quote] [A rant about Javascript bloat](https://www.youtube.com/watch?v=1t-k6-m50Fc) > "These are separate packages that have no reason to --- ## Full Transcript [00:00] I want to be clear about something. [00:01] JavaScript is far from my favorite [00:02] language. There's a lot of things I like [00:04] about it, but there's a lot that I [00:05] don't. That said, it is almost essential [00:07] because it's one of the few languages [00:08] that's supported everywhere. And I mean [00:10] everywhere. There are some costs to that [00:12] though, and those costs add up, and the [00:15] result often ends up being a lot of [00:17] bloat. Most of the JavaScript that's [00:18] being shipped around the web is almost [00:20] entirely unnecessary. We're talking [00:22] about bloat that just doesn't need to be [00:24] there at all. Some of it's cuz our tools [00:26] are outdated. Some of us is because the [00:27] devs are lazy, but some of it is because [00:29] it made sense at the time and we just [00:31] never took the time to fix it after. And [00:33] the result is a web where most of the [00:35] JavaScript being downloaded isn't [00:37] necessary at all. And that sucks. I [00:39] think it's important for us all to take [00:41] a moment to reflect on this. Why is [00:42] there so much useless JavaScript being [00:44] passed around and what can we do to fix [00:46] it? At the very least, we need to be [00:48] able to identify it. My team just sent [00:49] me a very exciting article from James [00:51] Garbet. The three pillars of JavaScript [00:54] bloat. This is a breakdown of all of the [00:56] different types of bloat that exist in [00:57] our code bases that make it so we end up [01:00] with these giant bundles that are full [01:01] of garbage that nobody needs. If we ever [01:03] want to fix this problem, we need to be [01:05] able to identify it and describe it. And [01:07] there's a lot to dig into there. [01:10] Thankfully, not everything on the web is [01:12] bloat. And one of the things that isn't [01:14] is today's sponsor. I think we all [01:15] understand now that our agents get way [01:17] smarter when they have access to the [01:18] web. But what we usually mean when we [01:19] say that is that they can go to sites [01:21] and get information from them. But if [01:23] you want to do more, if you want to [01:24] actually interact with and navigate the [01:25] web, you need a browser for your agents [01:27] to use. Today's sponsor is Browserbase, [01:28] and they're here to give you the best [01:30] possible experience for building with [01:31] agents and the web. A few days ago, Ben [01:33] was mad at me and he was threatening to [01:34] leave SF, so he built an app using [01:36] Browserbase to give him the best flight [01:38] deals for leaving to go to LA. But [01:39] there's something very interesting here [01:41] that is a new thing as of GPT 5.4. We [01:44] have two versions of this project. We [01:45] have the traditional browser use version [01:47] where it uses browser use primitives to [01:49] trigger clicks and keyboard presses and [01:51] all of those things, but 5.4 was trained [01:53] with a new capability, the ability to [01:55] write JavaScript that is meant to [01:57] execute on the page to fake these [01:59] interactions. And it turns out it's way [02:01] more accurate and way faster. I just [02:02] launched the app and thanks to browser [02:04] base, you can actually watch as the [02:06] browser is used throughout the whole [02:08] process. Here we see it going to the [02:10] flight tracker. It is already [02:11] interacting with the page and we can see [02:12] in the logs in our app what's going on [02:14] and what it is doing. And here we see [02:16] the code that it is writing to execute [02:18] on the page. Pretty cool that it finds [02:20] the button, selects the right button [02:22] from that list, waits for the timeout [02:23] for the focus from the click, and then [02:25] does the next steps. And it's wild to [02:28] watch. For my experience, the JavaScript [02:29] execution method has been so much more [02:32] reliable that I personally went from, [02:34] yeah, I guess this isn't really for me [02:35] to, yeah, I want to start using browser [02:38] use type stuff. These types of tasks [02:39] used to take minutes and now they take [02:41] seconds. If you want your agents to [02:43] really use the web, look no further than [02:44] soyb.link/browserbase. [02:46] I'm actually really, really excited to [02:47] go through this article with you guys. [02:49] Shout out to James, the author. He works [02:51] really hard on ecosystem performance [02:53] things, just trying to make our [02:54] JavaScript ecosystem better. That's why [02:56] he's so involved with things like unjs [02:58] and all these other cool projects, as [02:59] well as npmxdev, which is a really cool [03:01] new like npm registry viewer tool. [03:03] Choked is essential for a shitload of [03:05] stuff that I do. This is the package [03:07] that is used for tracking what changes [03:09] are happening on your file system in [03:10] node for things like hot reloading and [03:12] he's an active contributor to it. It is [03:14] rare that one dev touches that many [03:16] different things in the open source [03:17] world. So very excited to see his [03:19] thoughts here. He knows this [ __ ] better [03:20] than almost anyone. Three pillars of JS [03:22] bloat. Over the last couple years, we've [03:24] seen a significant growth of the E18 [03:25] community and a rise in performance [03:27] focused contributions because of it. A [03:29] large part of this is the cleanup [03:30] initiative where the community has been [03:32] pruning packages which are redundant, [03:34] outdated or unmaintained. One of the [03:36] most common topics that comes up as part [03:37] of this is dependency bloat. The idea [03:39] that mpm dependency trees are getting [03:41] larger over time, often with long since [03:43] redundant code which the platforms now [03:46] provide natively. In this post, James [03:48] wants to briefly look at what he thinks [03:50] are the three main types of bloat in our [03:51] depth trees, why they exist, and how we [03:53] can start to address them. I couldn't be [03:55] more excited for this one. This is one [03:56] of those few people that like really [03:58] knows what they're doing here. Oh [ __ ] [03:59] one of my chatters has actually just [04:01] joined E18 today. That's really cool to [04:04] see. First piece and this is important. [04:05] Older runtime support with safety and [04:08] realms. What the hell is a realm? We'll [04:09] know in a moment. Here's an example [04:11] graph they have. There's the is string [04:13] package. Is string checks has to string [04:16] tag which has a dependency on has [04:18] symbols. It also has a dep on call bound [04:21] which has get intrinsic which has a [04:23] shitload of additional subpackages. A [04:25] handful of which touch call bind apply [04:27] helpers and those touch function bind [04:30] and ES errors. So yeah, quite a [04:32] dependency tree for is string. Graphs [04:34] like this are a common site in many npm [04:36] dependency trees. A small utility [04:38] function for something which seems like [04:39] it should be natively available followed [04:41] by many similarly small deep [04:43] dependencies. So why is this a thing? [04:45] Why do we need is string instead of type [04:47] of checks? Why do we need has own [04:49] instead of object or object.prototype [04:52] hashazone property? Well, there's three [04:54] things. First, there is support for very [04:55] old engines. Second, there's protection [04:57] against global namespace mutation. [04:59] Third, and most importantly, there's [05:00] crossrem values. Oh boy. First, we have [05:04] the support for old engines. Somewhere [05:06] in the world, some people are apparently [05:07] exist who need to support ES3, like [05:10] Internet Explorer 6 and 7 or extremely [05:12] early versions of Node. Fun fact about [05:14] this. Curious what he links as a [05:16] footnote here. He says that he believes [05:18] there are people who need these old [05:19] engines, but he would love to see [05:20] examples. There's actually a company [05:22] that does this. They're named Hero Devs. [05:24] They have what I would consider some of [05:26] the most thankless work in the industry. [05:28] Their job is to come in as contractors [05:31] at companies that have old ancient [05:33] terribly maintained and structured code [05:35] bases that none of the engineers at the [05:37] company want to work on. If they even [05:38] have engineers there, they maintain [05:40] these old endof life projects as well as [05:42] their dependencies. They have forks of [05:45] things like NodeJS 0.8 that bring in [05:48] security fixes while still having the [05:50] weird [ __ ] that the company needs [05:51] for the old version of Node. They also [05:53] will often have to change packages and [05:55] fork them and maintain them themselves [05:57] in order to keep them compatible with [05:58] old versions of node. This has even [06:00] burned some people in the past where [06:01] they took over a poorly maintained repo [06:04] that had a dependency that was being [06:05] used by spelt and when they modified it, [06:08] they wanted it to work for these really [06:10] old things. So they took a package that [06:12] had no dependencies and they ended up [06:14] adding different things that they had [06:16] made in order to let it support old [06:19] ancient unmaintained versions of node. [06:21] But that resulted in a package that used [06:22] to be a single small dependency in [06:24] speltkit becoming like 20 subd [06:26] dependencies. Rich Harris flipped a [06:28] [ __ ] And that was the first time a lot [06:29] of people saw the type of work that [06:31] these devs have to do. I know a couple [06:33] employees at this company, they live in [06:35] the shadows. They like development, the [06:37] science more than the ecosystem. My [06:40] friend who told me when they were going [06:41] to start working there that they were [06:43] interested. I was like, "Oh, you're not [06:44] even like you're joking, right? Like [06:46] there's no way you'd actually want to do [06:47] that type of work." And they were like, [06:48] "No, I love this stuff. I love these [06:50] hard, thankless problems that nobody [06:52] thinks about. Kind of nuts. Yeah, these [06:54] people do actually exist. And to James, [06:56] who seems to not know any of them [06:57] according to his footnote, they are the [06:59] ones you need to talk to if you want [07:00] examples of people using these really [07:02] old things that have this crazy set of [07:05] weird dependencies that aren't needed in [07:08] most places. It's all them. There's a [07:10] bunch of things that we take for granted [07:11] in modern JavaScript that just don't [07:13] exist in these old places. For example, [07:15] for each on arrays or reduce on arrays [07:18] or object.keys. keys, which I use all of [07:20] the [ __ ] time, or object. I use some [07:23] of the time. I do not know how I would [07:24] write JS without these. These are all [07:26] ES5 features, meaning they simply don't [07:28] exist in ES3 engines. For those [07:30] unfortunate souls who are still running [07:32] old engines, they need to reimplement [07:33] everything themselves or be provided [07:35] with polyfills. Alternatively, it'd be [07:36] really nice if they just upgraded. [07:38] Totally agree there. Protection against [07:40] global namespace mutation. The second [07:42] reason for some of these packages is [07:44] safety in quotes. Basically, inside of [07:46] node itself, there's a concept of [07:48] primordials. These are essentially just [07:50] global objects wrapped at startup and [07:52] imported by node from then on to avoid [07:54] node itself being broken by someone [07:56] mutating the global namespace. For [07:58] example, if node itself uses map and we [08:00] redefine what map is, we can break node. [08:03] To avoid this, node keeps a reference to [08:05] those original versions of things like [08:06] map which it imports rather than [08:08] accessing the global. They have a whole [08:10] section about this in the repo. This is [08:13] fascinating. I did not know about this [08:14] that Node rebinds all of the default [08:17] globals in a custom name space early so [08:19] that they can use them without your [08:21] [ __ ] overriding them. Fascinating. [08:23] This also makes a ton of sense as an [08:24] engine because it shouldn't break if [08:26] somebody overrides some core [ __ ] [08:28] Good stuff. As always, the Node project [08:30] is underappreciated for the level of [08:32] complexity that they're operating [08:33] within. Like Node and V8 are two of the [08:35] most crazy complex, generous gifts to [08:38] the software development world that get [08:40] treated like [ __ ] because people just [08:41] hate on JavaScript. always has annoyed [08:43] me, even back when I hated JS. Okay, [08:45] last time I hated JS was like the last [08:46] time I had to write JS to be fair, but [08:48] you you get what I mean. Apparently, [08:49] there are some maintainers that believe [08:50] this is the correct way to build [08:51] packages, too. That's why we have [08:53] dependencies like math intrinsics in the [08:55] graph above, which is just a reexport of [08:57] the various math.star functions in order [08:59] to avoid them being mutated. What? Yep, [09:02] math intrinsics. All that package does [09:04] is reexports the default so if they get [09:06] overridden, you can still rely on them. [09:07] That is obnoxious. And now we get into [09:09] realms crossrem values. This is what [09:12] happens when you want to pass things [09:13] from web pages to iframes and stuff like [09:16] that. In this situation, a new reax in [09:18] an iframe is not the same thing as a [09:20] reax class as one of the parent pages. [09:23] So if you make a reax inside of a page [09:25] and you make a different one inside of [09:26] the iframe, they don't match. So if you [09:29] do something like trying to compare the [09:31] window.reax versus iframe window.reax, [09:33] the values are different and that would [09:35] end up being false if it came from the [09:37] iframe. For example, he's a maintainer [09:38] of chai and we have this exact issue. We [09:41] need to support assertions happening [09:42] across realms. This test runner may run [09:44] tests in a VM or even in an iframe. So [09:46] we can't rely on instance of checks. For [09:48] that reason, we have to use [09:49] object.prototype.2string.all [09:52] val equals object reax to check if [09:55] something's a reax, which works across [09:56] realms. It doesn't rely on the [09:58] constructor. Apparently, it's the same [09:59] thing that is string does because if you [10:01] pass a new string from one realm to [10:03] another, you might not be able to check [10:05] against the global like window string [10:06] because it's a different type because it [10:08] came from a different realm. God, I [10:10] people don't appreciate how hardJS can [10:11] be at these levels. I don't know about [10:13] you guys, I've never had to deal with [10:14] this myself. I've never had to worry [10:16] about what happens if I pass a value in [10:18] out of an iframe and I can't do instance [10:20] of calls on it. That's very different [10:21] from the world I live in personally. I [10:23] like this call out here. All of this [10:24] makes sense for a very small group of [10:26] people. If you're stuck supporting very [10:27] old engines, passing values across [10:29] realms, or you want protection from [10:30] someone mutating the environment, these [10:32] packages are exactly what you need. [10:34] Problem is that the vast majority of us [10:36] don't need any of this. We're running [10:37] modern versions of node that were and by [10:39] modern I mean the last 10 years or we're [10:41] using an evergreen browser that gets [10:42] automatically updated. We don't need to [10:44] support prees5 environments. We don't [10:47] pass values across frames and we [10:48] uninstall packages that break the [10:50] environment. Yes, mostly again hero [10:53] devs. Yeah, these layers of niche [10:55] compatibility somehow made their way [10:57] into the hot path of everyday packages. [11:00] The tiny group of people who actually [11:01] need the stuff should be the ones [11:03] seeking out special packages for it. [11:04] Instead, it is reversed and we all pay [11:06] the cost. Exactly. Thank you to the [11:09] chatters and begrudgingly, thank you to [11:11] Grock for the help finding this example [11:13] from way back. The AX object query [11:16] package, which is used by a bunch of [11:17] things for programmatic detection of [11:20] accessibility issues. It originally had [11:22] almost no dependencies and a different [11:24] developer had just come in to take over [11:26] the project because it wasn't being [11:27] maintained by the original devs anymore. [11:29] they agreed to let him take it over. And [11:30] when he did, he immediately focused on [11:32] backward compatibility maxing, which he [11:35] did by fundamentally changing the [11:37] structure of the dependencies. And here [11:39] you can see they added a bunch of [11:41] additional dependencies that largely [11:43] came from that team in order to try and [11:45] make back compat with really old [11:47] versions of node possible. This change [11:49] pissed off so many people and confused [11:51] them so much they thought it was a [11:52] supply chain attack. Most devs had just [11:55] never seen this type of back [11:57] compatibility being added to a project. [11:59] And it looked like this too since the [12:01] dev LJ Harb was the one who built most [12:03] of the subd dependencies that were added [12:05] because again remember it is his job to [12:08] maintain these ancient code bases and [12:10] build all of the key pieces that are [12:12] needed for things to work in stuff like [12:14] old node 0.4 projects. That said, Sam [12:17] was entirely wrong here. This was not a [12:20] supply chain attack under the guise of [12:22] supporting node 0.4. for nobody would do [12:24] a supply chain attack with something [12:25] that's that obviously stupid. They would [12:27] do it with something that seems more [12:29] promising like performance improvements. [12:31] Nobody would ever do anything under this [12:33] cuz this is not something anyone would [12:35] want to merge. This is something that [12:36] they're doing because they have to [12:38] maintain these old code bases and that's [12:39] the easiest path they've had. My problem [12:41] with her devs and I have told this to [12:43] the people who I know there is that they [12:45] treat these core dependencies as though [12:48] they have to support everything. They [12:50] treat these core dependencies as the [12:52] path to get that legacy support into [12:54] their things, not even through custom [12:56] versions of the packages, but through [12:58] forcing the main versions of these [13:00] packages to continue to be compatible [13:02] with these ancient versions of things. [13:04] And the result is a bunch of unnecessary [13:06] bloat. It's worth noting that of those [13:08] 60 new direct dependencies that were [13:10] added, one of them, which is deep equal, [13:12] which is necessary when using ancient [13:13] versions of node for comparisons of [13:15] things, added 50 by itself. This nearly [13:18] doubled the number of packages that were [13:20] necessary to install SpeltKit. And the [13:22] Spelt team was [ __ ] pissed, as they [13:25] should be. It's kind of crazy that a [13:27] minor version bump of something that [13:28] you're already using can suddenly double [13:30] the number of dependencies that you have [13:32] in your codebase. Again, I want to [13:34] emphasize just how thankless this work [13:36] is, but also that I don't think it is [13:38] appropriate for the Hero Devs team to [13:40] effectively be forcing their unique [13:43] needs onto the default path for other [13:46] devs. These things are so uncommon that [13:48] they probably need to be in either other [13:50] custom branches or tags or ideally even [13:52] a fork with a different name for [13:54] maintaining these old versions of the [13:55] packages. That was all just for the [13:58] first pillar. By the way, we got two [14:00] more other separate things that can [14:02] cause bloat. Thankfully, these ones are [14:04] a little bit simpler. The next is atomic [14:06] architecture. Some folks believe that [14:08] packages should be broken up to an [14:10] almost atomic level creating a [14:12] collection of small building blocks [14:13] which later can be reused to build other [14:15] higher level things. So you end up with [14:17] graphs like this one where you have exec [14:19] a which has a couple subdevs like [14:21] cinders merge streams cross spawn which [14:23] depends on which path key shebang [14:24] command shebang reax etc because all of [14:27] these are really simple things like [14:29] shebang reax a very simple reax for [14:31] checking if it's a shebang or not is exe [14:34] what that does get stream has its own [14:36] separate readable stream implementation [14:37] it references as well as an is stream [14:39] function instead of just having them [14:40] inside you get the idea when there's a [14:43] part that is reusable it is broken out [14:44] to be reusable Although it's funny, I [14:47] just referenced the shebang reax one and [14:50] then that's the example the author gives [14:52] too. This is a package that is a package [14:54] that is downloaded 133 million times a [14:57] week. Do you understand how absurd that [14:59] is? Two lines of code that there are [15:02] four versions of four majors that are [15:04] downloaded 133 million times a week. Two [15:08] lines of code. It's a reax. It's a reax [15:10] and an export. You might start to be [15:12] thinking we did this to ourselves. And [15:14] you know what? I think we did. By [15:17] splitting code up to this atomic level, [15:19] the theory is that we can then create [15:20] higher level packages simply by joining [15:22] the dots. I get this. I am a big fan of [15:25] the Unix philosophy myself. But uh Unix [15:28] philosophy should not be at a line of [15:29] code level. Here are some common [15:31] examples and I'm going to check how [15:32] popular these are in npmjs as we go [15:35] through. We have rfi which converts a [15:36] value to an array. If it's an array, [15:38] then we return the array. If not, then [15:40] we return it with an array wrapper. It's [15:42] one line of code. And this package is [15:44] downloaded [15:46] 32 million times a week. Next, we have [15:49] slash, which replaces backslashes and [15:51] file system paths with traditional [15:53] slashes. This package is downloaded, [15:56] wait for it, [15:58] 96 million times a week. We got CLI [16:01] boxes, which is a JSON file containing [16:03] the edges of a box 40 million times a [16:06] week. It literally is just a JSON blob [16:09] with top left character, top character, [16:12] top right, right, bottom right, bottom, [16:14] bottom left, left. 40 million times a [16:16] week. It's a JSON file. I'm going to [16:18] die. I knew it was bad. I did not know [16:19] it was this bad. Oh, path key. I've used [16:22] this one. I've used this one. Oh no. How [16:26] popular is this? [16:29] 158 million times a week. It's a 4 [16:32] kilobyte of JS file. It is literally [16:35] just a file. Let's look at the JS for [16:38] it. If platform is not wind32, return [16:41] path. Otherwise, we have to go steal the [16:43] path in Windows because Windows has a [16:45] lowercase path. [16:48] I can't believe the world we're in. We [16:50] did this to ourselves. [16:53] Today's sponsor is all about hiring. If [16:55] you need great engineers, look no [16:56] further than G2. That's not G2I. That's [16:59] the AI engineer conference in Miami. [17:02] Yeah, I kind of tricked you guys. G2I [17:04] does a lot more than just hiring. They [17:05] run some of my favorite tech events. [17:07] I've been going to React Miami for three [17:08] years now, and it's consistently my [17:10] favorite tech conference every year. [17:12] They are still doing React Miami. In [17:13] fact, it's right afterwards. If you want [17:14] to hang out with cool engineers like me, [17:16] Prime, and all the other awesome folks [17:17] who show up for this stuff, I highly [17:18] recommend checking out the AI engineer [17:20] World Fair in Miami as well as React [17:22] Miami from April 20th to 24th. If you [17:24] don't have the time for a conference, [17:25] it's probably because you need to hire [17:26] more. And if you do, I highly recommend [17:28] hiring at soy. [17:30] Chat made a good call out. The dev who [17:33] wrote this article is also working on [17:34] npmx, so I should definitely be using [17:36] that for these searches. It's a lot [17:37] quicker when I search one time, which [17:39] ensures a function is only called once, [17:41] which is 131 million downloads a week. [17:46] And it's once again Cinder. Poor Cinder [17:49] has had to write so much random [ __ ] [17:51] that we all rely on. He wrote Kai, which [17:53] is still my favorite fetch rapper, as [17:55] well as a ton of these thankless small [17:58] projects that are necessaryish when you [18:00] want to reuse things and have them be [18:02] simpler. Kind of h a lot of respect for [18:05] the work he does. I rely on so much of [18:06] his [ __ ] regularly, but some of these [18:08] things it hurts that they exist. Oh, [18:11] this is cool. String width. This is how [18:13] long the string actually is, not just [18:16] how long the binary is. Thankfully, this [18:19] one's relatively small for what it is. [18:21] And it's actually kind of annoying to do [18:23] this, right? Because like is a character [18:24] like this is one care, but it is [18:27] actually longer when you print it. And [18:29] if you put a bunch of these tags around [18:31] it, it's still only two cares long. And [18:33] string width handles it. That's actually [18:35] a good example of a thing that's kind of [18:36] annoying to calculate and do, right? [18:38] Especially with emojis and [ __ ] Yeah. [18:40] One of the cool things I didn't realize [18:42] on the site is that npmx will show you [18:44] the total downloads per week of [18:45] someone's packages. and his packages are [18:47] downloaded almost 10 billion times per [18:49] week. That is insane. Oh god, how [18:53] popular is Windows? Okay, it's only 27 [18:55] mil. It's not as bad as some of the [18:57] others, but you get the idea. These are [18:58] all very, very, very, very, very, very [19:01] popular packages. Absurdly. So, you want [19:04] to build a new CLI, for example, you can [19:05] pull a few of these in and not worry [19:07] about implementation. You don't need to [19:09] do env path or envase [19:12] path or cells. You can just pull a [19:13] package for that. Great. I actually have [19:15] a whole video about why I think [19:16] libraries are kind of dying as a result [19:17] of vibe coding. It's really cool that [19:19] it's a lot easier to write this solution [19:21] than it ever was before because AI will [19:23] know this mistake or at the very least [19:25] find the package and hopefully read the [19:26] code and realize it shouldn't be using [19:28] it. TBD, but you get the idea. So why is [19:30] this a problem? In reality, most or all [19:33] of these packages did not end up as the [19:35] reusable building blocks they were meant [19:36] to be. They're either largely duplicated [19:38] across various versions in a wider tree [19:40] or they're single-use packages which [19:41] only one other package uses. For [19:44] example, shebang reax it's almost solely [19:46] used by shebang command which is by the [19:48] same maintainer. CLI boxes is used [19:50] almost solely by boxin and ink also both [19:53] by the same maintainer. One time is used [19:55] almost solely by restore cursor which is [19:56] again the same maintainer. These are [19:58] separate packages that have no reason to [20:00] be separate packages. Each of these [20:02] having only one consumer means they are [20:04] equivalent of inline code but cost us [20:06] more to acquire because of npm requests, [20:08] tar extraction, bandwidth, etc. Yep. If [20:11] three different things you used required [20:12] shebang reax, having it as a single [20:14] shared package could theoretically make [20:16] sense. The fact that it's one line makes [20:17] it less so, but hypothetically speaking, [20:20] but that's not the case. This is just [20:21] dumb. And then we have the duplication [20:23] problem. Taking a look at the Nux [20:24] dependency tree, we can see a few of [20:26] these building blocks that are [20:27] duplicated because they have two [20:28] different versions of the same thing. [20:30] Another fun problem. There's two [20:32] versions of his Docker. There's two [20:33] versions of his stream. There's two of [20:35] is Windows Subsystem for Linux. There's [20:36] two of his exe two of npm run path two [20:39] of path key and two of path scurry [20:41] that's because they have packages that [20:42] they're relying on that both rely on is [20:45] docker or is stream and they rely on [20:46] different versions so you end up with [20:48] two versions of the same thing [20:51] inlining these does not mean we no [20:52] longer duplicate the code but it does [20:54] mean we don't pay the cost of things [20:55] like version resolution conflicts cost [20:57] of acquisition etcing makes duplication [21:00] almost free while packaging makes it [21:02] expensive yep entirely correct and one [21:04] of the biggest issues especially [21:06] recently is the larger supply chain [21:08] surface area makes it easier to attack [21:11] and hijack people's [ __ ] It's so common [21:13] that people now speculate that when [21:15] somebody is trying to make something [21:16] work in older projects that it is a [21:17] supply chain attack because we just [21:19] expect this now. The more packages you [21:21] have, the larger the supply chain [21:22] surface area is. Every package is a [21:24] potential point of failure for [21:26] maintenance, security, and so on. For [21:28] example, a maintainer of many of these [21:29] packages was compromised last year. This [21:31] meant that hundreds of tiny building [21:33] blocks were compromised, which meant [21:34] that the higher level packages we [21:36] actually install were also compromised. [21:38] Logic as simple as array.isarray [21:40] probably doesn't need to be its own [21:42] package. Security, maintenance, and so [21:44] on. It can just be inlined and we can [21:46] avoid the risk of it being compromised. [21:48] Absolutely agree. Similar to the first [21:50] pillar, which is the older runtime [21:51] support, this ended up being a thing [21:53] that made its way into the general hot [21:56] path. So, the thing most people do [21:58] happens to now involve this. Even though [21:59] these are more conceptually good things [22:01] that are useful in niche specific [22:03] places, it became the thing we're all [22:05] doing whenever we install [ __ ] And the [22:07] result is that we all have to pay this [22:09] cost without getting any benefit [22:10] ourselves. I'm going to turn off the [22:12] dark mode for a sec. So, uh, prepare [22:14] your eyes. It just happened to break [22:16] this particular view because canvases [22:18] are hard. This is the pony fills [22:20] section. Pony fills that overstayed [22:22] their welcome. There's a lot of things [22:23] in here that were really useful in 2010 [22:26] like is array that still gets 160 [22:28] million installs a week or object.keys [22:31] or string prototype trim that are way [22:32] too popular and these dates by the way [22:34] are effectively when the native support [22:36] occurred. So in 2010 all these things [22:38] became common in JS package are still [22:40] huge is nan got built in in 2013 package [22:43] still gets millions of installs a week. [22:44] array prototype fine, string prototype, [22:46] repeat, object sign, you get the idea. [22:48] All of these features that have been in [22:49] JavaScript for 15 plus years for some of [22:53] them still have packages being installed [22:55] that are entirely unnecessary. If you [22:57] were looking away because of the lack of [22:58] dark mode, you can look back now. You're [23:00] building an app, you might want to use [23:01] some future features that your chosen [23:02] engine doesn't support yet. In that [23:04] situation, a polyfill can come in handy. [23:06] For all of you guys who really wanted [23:08] temporal, you've probably been using a [23:09] polyfill for a while now. Polyfills [23:11] provide fallback implementations where [23:12] the feature should be so you can use it [23:14] as if it was natively supported. Very [23:16] very cool thing. Typescript used to even [23:18] introduce certain polyfills for things [23:20] themselves so that features that most [23:22] people wanted especially TypeScript [23:23] focused ones could be in early so you [23:25] could have access to them. Generally, I [23:27] think that's an okay to good pattern. [23:29] For example, temporal polyfill will [23:31] polyfill the new temporal API so you can [23:33] use it regardless of if the engine [23:34] supports it or not. I swear when I [23:36] started doing JavaScript heavily back in [23:38] 2018, we were still talking about how [23:40] exciting temporal was. It's just [23:41] starting to ship now 8 years later, [23:42] which is kind of crazy. And here we are. [23:44] You're building a library instead. What [23:46] should you do? In general, no library [23:49] should load a polyfill as that is a [23:51] consumer's concern and the library [23:52] should not be mutating the environment [23:54] around it. Again, polyfills add things [23:56] to like globals so they will work in [23:59] your environment. If you are personally [24:01] writing code in your project that's [24:03] userfacing and you want temporal, go [24:06] install the polyfill. That's totally [24:07] kind. It's a top level depth that makes [24:08] sense. Polyfills sneaking in through [24:10] other things makes way less sense. [24:13] Thankfully, there are very few projects [24:14] that do that that bring in a polyfill [24:16] that can [ __ ] up your environment. [24:18] There's a lot of devs who wanted that [24:19] and I can sympathize here. There's a lot [24:21] of devs that are using features that [24:22] might be kind of new in their packages [24:24] and those features are probably causing [24:25] bugs for a lot of their users. The users [24:28] being developers implementing them. So [24:30] if you made a package that uses temporal [24:32] person installs that package and it [24:34] breaks because they don't have temporal [24:35] installed, you're probably tired of [24:36] telling all of them, make sure you [24:37] install the polyfill, make sure you [24:39] install the polyfill. So the solution [24:40] for this is called a pony fill. It's [24:42] kind of like a polyfill, but it gives [24:44] you a different import path. So instead [24:45] of changing the runtime, instead of [24:47] binding things to globals, it just lets [24:48] you import a fake temporal that you can [24:51] call directly instead. I can absolutely [24:53] sympathize with this cuz I had a lot of [24:54] weird problems when I was maintaining [24:56] projects at Twitch. There's only an [24:57] internal dashboard for managing reports [24:59] when users report people on Twitch. And [25:01] almost all of the safety ops people that [25:02] actually went through those reports were [25:04] using Chrome, as were the devs. [25:06] Everything worked great in Chrome. If [25:08] you ever wonder where my disdain for [25:10] Firefox started, it was then, because we [25:12] had one single person who really wanted [25:15] to use Firefox, and the amount of random [25:17] [ __ ] that broke was horrifying. [25:20] Backwards reax just wasn't supported. [25:23] And it didn't even give good errors when [25:24] you tried. That meant I had to polyfill [25:27] reax for Firefox. Yes, really. [25:31] This is the world we live in. Pony fills [25:33] are basically polyfills that you import [25:35] rather than mutating the environment. [25:37] This kind of works since it means a [25:38] library can use future tech by importing [25:40] an implementation and it can pass that [25:42] around so it can use the native one if [25:44] it needs to, if it exists. Otherwise, [25:46] it'll use its pony fill otherwise. None [25:48] of this mutates the environment, so it's [25:49] safe. So, why is this a problem? It [25:51] seems fine if they're not mutating the [25:53] environment, right? Well, the code's [25:54] still there. These pony fills did their [25:56] job at the time. They allowed library [25:57] authors to use future tech without [25:58] mutating your environment and without [26:00] forcing consumers to know what polyfills [26:02] they have to install. Problem comes with [26:03] the pony fills when they outstay their [26:05] welcome. When the feature they fill in [26:07] for is now supported by all major [26:09] engines that we care about, the pony [26:10] fill should be removed. However, this [26:12] often doesn't happen and the pony fill [26:14] remains in place long after it's needed. [26:17] We're now left with many, many packages [26:19] which rely on pony fills for features [26:21] we've all had for a decade or more, [26:23] including global this because global [26:24] this didn't used to exist, but it's been [26:26] widely supported since 2019. The [26:28] globalist package still gets 49 million [26:30] downloads a week. Or index of, are you [26:32] kidding? That's been supported since [26:34] 2010 and it still gets 2.3 million [26:36] downloads a week. And then object [26:38] entries, which has been supported since [26:40] 2017, still getting 35 million downloads [26:42] a week. Unless these packages are being [26:44] kept alive because of pillar one, which [26:46] is the support for the old things, [26:48] they're usually still just used because [26:50] nobody ever thought to remove them. When [26:52] all long-term support versions of [26:53] engines have a feature, the pony fill [26:55] should definitely be removed. Absolutely [26:57] agree. Oh boy, the index of package. The [26:59] description is great. Lame index of [27:01] thing. Thanks, Microsoft. This clearly [27:03] was only built to support Internet [27:05] Explorer at the time. We look at the [27:07] code, the very complex code. If index of [27:10] does exist in your runtime, which is [27:11] checked with the empty array index of, [27:13] if it exists, we just use the [27:15] array.index of that you passed looking [27:17] for the object. And if it doesn't, then [27:18] we for loop across it to get you the [27:20] index. This is 10 lines of code that are [27:23] downloaded millions of times a week that [27:25] aren't only stupid and easy to write, [27:28] they're entirely unnecessary. The author [27:30] of this package is TJ, who is the [27:33] creator of Express, who left JavaScript [27:35] a decade ago. Dogpaw and Steven are [27:37] helping a ton here. Thank you both, by [27:39] the way. Huge shout out to you guys for [27:41] making sure I get all the fun facts in [27:43] this one. So, now the most important [27:45] part. What can we do about all of this? [27:47] Much of this bloat is so deeply nested [27:49] in dependency trees today that it's a [27:50] fairly hefty task to unravel it all and [27:53] get to a good place. It will take time [27:54] and it will take a lot of effort for [27:56] both maintainers and the consumers of [27:57] these libraries. Having said that, I do [27:59] think we can make significant progress [28:01] on this front if we all work together. [28:03] Start asking yourself, why do I have [28:04] this package and do I really need it? [28:06] This is especially important for [28:08] maintainers. If you find something which [28:10] seems redundant, raise an issue with the [28:12] maintainer asking if it can be removed. [28:13] You encounter a direct dependency which [28:15] has many of these issues, have a look [28:17] for an alternative which doesn't. A good [28:19] start for this is the module [28:20] replacements project which is also part [28:22] of E18. I already liked these guys. I [28:25] very quickly am realizing they are [28:27] essential to this ecosystem. Another [28:29] great recommendation is NIP. We use this [28:30] in all of our projects now. It has been [28:32] an incredibly helpful thing. NIP will [28:35] find unused code and imports in your [28:37] project and make it easy to get rid of [28:39] them. It also helps with unused depths, [28:40] dead code, and many other random things. [28:43] Be a great tool to find and remove [28:44] depths you no longer use. It doesn't [28:46] solve all these problems necessarily, [28:47] but it's a great starting point to help [28:48] clean up depth trees before doing the [28:50] more involved work. Oh, E18 has a CLI [28:53] that is an analyze mode that can [28:55] determine which depths are no longer [28:56] needed or have community replacements [28:58] that are recommended. Apparently, chalk [28:59] can be replaced with native [29:00] functionality. That's really cool. This [29:02] is a great little package here. That's [29:04] so cool. They even have a migration [29:06] command that can migrate for a handful [29:07] of these things that are automatable. In [29:09] this case, it'll migrate from chalk to [29:10] Pico colors, which is a much smaller [29:12] package that provides the same [29:13] functionality. CLI will even recommend [29:15] based on your environment. For example, [29:17] it can suggest the native style text [29:18] instead of a colors library if you're [29:20] running a new enough node. That's really [29:21] cool. Also, npm graphs. This is really, [29:24] really useful. Using npm graphs to [29:26] figure out what the dependencies are of [29:27] your [ __ ] That's really good. [29:30] Yeah. [29:31] Yeah, I had a feeling the T3 package has [29:35] uh built up a little bit. We got some [29:38] effect. We got the diffs library. We got [29:41] open and websocket node pointer and the [29:44] claw agent SDK package is so heavily [29:46] offuscated that they're also using [29:48] what's the package that versel has? NCC. [29:51] That's what I'm thinking of. NCC is a [29:53] package by Forcell that takes all your [29:54] dependencies and bundles them into a [29:56] single JS file. And I'm almost positive [29:58] Anthropic is using that here because [29:59] they don't want us to know anything [30:00] about how the Asian SDK is implemented [30:02] because they are kind of evil. So I [30:03] would bet this has lots of other [30:05] subdeps. We just can't see them. [30:06] Apparently Pierre diffs library has a [30:09] lot of subdeps. I did not realize that [30:11] like half our dependency graph comes [30:13] from the diffs library. Interesting. To [30:16] be fair, there are some core depths in [30:17] here that have to be a little complex [30:18] like shiki for the syntax highlighting. [30:20] Like that's just not a trivial thing. [30:22] And then the has to util HTML that turns [30:24] the syntax tree into HTML has a lot of [30:28] these subp packages too. Interesting. [30:30] You learn something every day. And I'm [30:32] learning about my own dependency graph [30:33] right here. See this is a really good [30:35] example here too with ESLint where [30:37] there's this find up package that is a [30:40] bunch of sub things around six total. [30:42] And if you can replace that package then [30:44] you can trim out six packages from your [30:46] npm install. That's a great thing. [30:48] There's also the module replacements [30:49] project which has a set of replacements [30:52] that are modern, simpler, and more [30:54] well-maintained than these old things [30:56] that makes it really easy to identify [30:58] and replace anything that could be [31:00] replaced. This has been an awesome [31:01] article. Huge shout out again to James. [31:02] Let's read the closing thoughts and do [31:04] one last important thing at the end [31:05] here. We all pay the cost for an [31:06] incredibly small group of people to have [31:08] an unusual architecture that they like [31:09] or a level of backwards compatibility [31:11] that they specifically need. It's not a [31:13] fault of the people who made the [31:14] packages as each person should be able [31:15] to build however they want. Many of them [31:17] are an older generation of influential [31:18] JS devs building packages in a darker [31:20] time where many of the nice APIs and [31:22] cross-co compatibility that we have [31:23] today simply didn't exist. They built [31:25] the way they did because it was possibly [31:26] the best way at the time. The problem is [31:28] that we never moved on from there. We [31:30] still download all of this bloat today. [31:32] Even though we've had these features for [31:33] several years, I think we can solve this [31:35] by reversing things. The small group [31:37] should pay the cost. They should have [31:39] their own special stack that pretty much [31:40] only they use. Everyone else should get [31:42] the modern, lightweight, widely [31:44] supported code. Hopefully things like [31:45] the E18 Foundation and npmX can help [31:48] with that through documentation, [31:49] tooling, etc. You can help by taking a [31:51] closer look at your dependencies and [31:52] asking why. Raise issues with your [31:54] dependencies, asking them if and why [31:55] they need these packages anymore. We can [31:57] fix it. E18E is one of the most [32:00] essential things happening in the JS [32:01] world. I already thought highly of them, [32:03] but now I am convinced that we need them [32:04] in order for JS to survive. As such, I'm [32:07] going to do the most important thing to [32:08] support a project like this, money. I [32:11] just contributed $5,000. I think this is [32:14] important. I hope this helps prove just [32:16] how important I think this is. And I [32:18] hope many of y'all take the opportunity [32:20] to do the same. These projects are no [32:22] joke. These are the things that actually [32:23] make the ecosystem survivable. These are [32:25] the things that make the web better and [32:27] keep things from getting worse. If we [32:29] want the web to win, and I hope we all [32:31] do, I hope you guys who have money, and [32:32] I know many of you have money, take the [32:34] opportunity to contribute, or at the [32:36] very least tell your boss that it's [32:38] probably worth including in your open [32:39] source financial contributions. [32:40] Obviously, not everybody needs to donate [32:42] this much money, but if you have a [32:43] couple bucks to throw their way, you'd [32:45] be amazed how far it goes. The team [32:46] doesn't actually need too much money to [32:48] survive right now, and they're very, [32:50] very, very lean. I would argue more so [32:53] than they should be because these devs [32:54] are doing some of the hardest work, and [32:55] they are being paid like [ __ ] They [32:57] currently have a total balance of [32:59] $17,000, which in my opinion is enough [33:02] to pay one dev like once. These devs [33:04] should be paid very generously because [33:06] this is very, very important work. The [33:08] fact that an organization that is this [33:09] important literally only has about [33:12] $17,000 there is terrifying and I am [33:15] thankful I just got to meaningfully [33:16] increase that myself. I got nothing else [33:18] to say. Just go support these guys. [33:19] They're doing important work. And until [33:21] next time, peace nerds.  📄 **Full text:** ![[Full Document Contents/Articles/A Rant About Javascript Bloat|A Rant About Javascript Bloat, YouTube]] ## Highlights - at companies that have old ancient terribly maintained and structured code bases that none of the engineers at the company want to work on. If they even have engineers there, they maintain these old endof life projects as well as their dependencies. They have forks of things like NodeJS 0.8 that bring in security fixes while still having the weird [ __ ] that the company needs for the old version of Node. They also will often have to change packages and fork them and maintain them themselves in order to keep them compatible with old versions of node. This has even ([View Highlight](https://read.readwise.io/read/01kmzkqqcj1w7nq4sb6jjza8yr)) - Tags: 👻 ai highlighted - examples of people using these really old things that have this crazy set of weird dependencies that aren't needed in most places. It's all them. There's a bunch of things that we take for granted in modern JavaScript that just don't exist in these old places. For example, for each on arrays or reduce on arrays or object.keys. keys, which I use all of the [ __ ] time, or object. I use some of the time. I do not know how I would write JS without these. These are all ES5 features, meaning they simply don't exist in ES3 engines. For those ([View Highlight](https://read.readwise.io/read/01kmzkqqeztsajehps22rgethm)) - Tags: 👻 ai highlighted - unfortunate souls who are still running old engines, they need to reimplement everything themselves or be provided with polyfills. Alternatively, it'd be really nice if they just upgraded. Totally agree there. Protection against global namespace mutation. The second reason for some of these packages is safety in quotes. Basically, inside of node itself, there's a concept of primordials. These are essentially just global objects wrapped at startup and imported by node from then on to avoid node itself being broken by someone mutating the global namespace. For example, if node itself uses map and we ([View Highlight](https://read.readwise.io/read/01kmzkqqgpr1ez05y4vv9tdf66)) - Tags: 👻 ai highlighted - is underappreciated for the level of complexity that they're operating within. Like Node and V8 are two of the most crazy complex, generous gifts to the software development world that get treated like [ __ ] because people just hate on JavaScript. always has annoyed me, even back when I hated JS. Okay, last time I hated JS was like the last time I had to write JS to be fair, but you you get what I mean. Apparently, there are some maintainers that believe this is the correct way to build packages, too. That's why we have dependencies like math intrinsics in the graph above, which is just a reexport of the various math.star functions in order to avoid them being mutated. What? Yep, ([View Highlight](https://read.readwise.io/read/01kmzkqqjfh35emzrk2m0fnx5b)) - Tags: 👻 ai highlighted - of this package is TJ, who is the creator of Express, who left JavaScript a decade ago. Dogpaw and Steven are helping a ton here. Thank you both, by the way. Huge shout out to you guys for making sure I get all the fun facts in this one. So, now the most important part. What can we do about all of this? Much of this bloat is so deeply nested in dependency trees today that it's a fairly hefty task to unravel it all and get to a good place. It will take time and it will take a lot of effort for both maintainers and the consumers of these libraries. Having said that, I do think we can make significant progress ([View Highlight](https://read.readwise.io/read/01kmzkqqx3j7z7wzhvvshast20)) - Tags: 👻 ai highlighted - Even though we've had these features for several years, I think we can solve this by reversing things. The small group should pay the cost. They should have their own special stack that pretty much only they use. Everyone else should get the modern, lightweight, widely supported code. Hopefully things like the E18 Foundation and npmX can help with that through documentation, tooling, etc. You can help by taking a closer look at your dependencies and asking why. Raise issues with your dependencies, asking them if and why they need these packages anymore. We can fix it. E18E is one of the most ([View Highlight](https://read.readwise.io/read/01kmzkqr1m4410r924fe7761zv)) - Tags: 👻 ai highlighted