Cached at:
07/28/26, 04:29 PM
### TL;DR
Richard Feldman compares dependency graphs across different programming language websites and game projects, showing that most dependency choices are cultural norms rather than technical necessities.
## Historical Context: From Bare Metal to Abstraction Stack
Feldman recalls the tech stack of a startup around 2006: self-assembled physical servers running Debian Linux, Apache HTTP server with Perl, a forked MW forum for authentication, Postgres, Memcached, sendmail for email, and jQuery with jQuery UI on the frontend. Forking was common back then.
Compare with Viaweb (the first web application) in 1996: they used bare-metal servers, FreeBSD, Common Lisp and C, with no CSS, JavaScript, or database—they used flat files. Investors demanded a database, but they refused. After Viaweb was acquired by Yahoo, the proceeds funded Y Combinator.
Today's modern stack: Firecracker on AWS Lambda, Vercel as an abstraction, TypeScript on Node.js, Next.js blending client and server state, Prisma ORM, Neon distributed Postgres, Upstash distributed Redis, Resend replacing sendmail, S3+CloudFront, and on top of that Tailwind CSS, React, Next.js, Tanstack, shad cn/ui, etc. Many of these Feldman only learned for this talk.
## Dependency Graphs of Eight Programming Language Websites
Feldman compared the official static websites of TypeScript, Node.js, Python, Ruby, Rust, Zig, Go, and Rock (all doing essentially the same job: documentation, syntax highlighting, examples). In the eight bar charts, one has a height of zero pixels (zero dependencies), while another has nearly 1,800 dependencies (almost all indirect). Two of the websites (TypeScript and Rock) run a compiler in the browser (no server send), but they don't correspond to the largest bars—in fact, TypeScript and Rock have small dependency counts, while the huge one comes from Gatsby (used by the TypeScript website).
Feldman notes: "Do you need to run a compiler on your website? Turns out, no; you just need a compiler itself." Those 1,500+ indirect dependencies come almost entirely from choosing one framework.
## Cultural Groupings
- **npm camp** (TypeScript, Node.js): Many direct and indirect dependencies, with a high ratio of indirect.
- **Ruby and Rust**: Similar shape—few direct, many indirect, but far fewer than npm.
- Interestingly, Rust's package manager was built with help from the Ruby gems team.
- **Python and Go**: Each with independent philosophies; Python direct:indirect ratio nearly 1:1; Go also has its own style.
- **Zig and Rock**: Almost zero direct dependencies, and very small indirect parts—Zig compiler written in Zig, Rock compiler written in Zig, sharing culture.
Conclusion: "These are cultural norms, not technical necessities."
## Game Dependency Comparison
Feldman picked nine open-source/source-available games and plotted direct vs. indirect dependencies. Two bars are huge (Rust and C# games), two are smaller, others near zero. Two are remakes of the same game: one in the Rust ecosystem (~29 direct deps, many indirect), the other in the C# ecosystem (30 direct deps, also many indirect). The C++ game has zero indirect dependencies and extremely low direct dependencies (just LLVM, etc.).
- **npm culture**: Adding dependencies is easy; lots of indirect ones are customary.
- **C++ game culture**: No standard package manager; dependencies are often vendored/forked and committed to source control, resulting in very few indirect deps.
Feldman suggests this explains why apps with similar functionality can differ in dependency counts by orders of magnitude—it's culture that shapes choices.
## Technology vs. Culture
Feldman asks: "How much is technical? How much is cultural?" Looking at the data, the same category of functionality (static website, game remake) naturally doesn't require vastly different dependency counts. The differences stem from ecosystem habits: npm's "everything is a package" vs. C++'s "self-sufficient" approach, and the package management philosophies inherited by each language community.
Source: https://www.youtube.com/watch?v=E82ly38YEEQ