The Most Starred vs Most Downloaded: When GitHub ≠ npm

TL;DR

GitHub stars and npm downloads are measuring entirely different things. Stars measure a moment of enthusiasm at a point in time. Downloads measure ongoing operational usage. The divergence between them — sometimes massive — reveals the lifecycle stages of packages: hype > adoption > commoditization > decline. The most interesting packages are the ones where the two metrics tell contradictory stories.

Key Takeaways

Stars peak 6-18 months after launch then plateau; downloads keep growing if adopted
Create React App: 102K stars, declining downloads — stars outlive the product
semver: zero GitHub hype, 95M dependents — critical infrastructure, not trendy
Zustand vs Redux: similar stars, Zustand growing faster in downloads
Best signal combination: growing downloads + reasonable stars + high issue close rate

The Four Quadrants

                      HIGH downloads
                           |
        Infrastructure    |    Winners
        (boring, critical)|    (both metrics growing)
        semver, lodash    |    React, Vite, Next.js
                          |    Zustand, Tailwind
LOW stars ────────────────┼──────────────────── HIGH stars
                          |
        Dead / Niche      |    Hype > Adoption
        (nobody using,    |    (Starred but not used)
         nobody excited)  |    Create React App (stars high, declining use)
                          |    Many "show HN" projects
                      LOW downloads

High Stars, Low/Declining Downloads

Create React App — 102K Stars, -35% Downloads YoY

# Why the divergence:
# Stars accumulated 2016-2021 when CRA was THE way to start React
# The React team officially deprecated it in 2022
# Stars: don't go down when a project is deprecated
# Downloads: declining as devs migrate to Vite

# The star-to-reality gap:
# Someone landing on github.com/facebook/create-react-app
# sees 102K stars and thinks "this must be the right choice"
# Reality: the React docs don't even mention CRA anymore

# What to do: Always check npm downloads + release date + README
# Stars alone are a trap

Various "Awesome List" Aggregators — Stars in Thousands, Zero Downloads

# GitHub pattern: "awesome-react", "awesome-javascript"
# These repos accumulate stars because people bookmark them
# They're not npm packages at all — just lists of links
# But appear in "trending" alongside actual packages

# Lesson: Stars come from GitHub browsing behavior,
# not from production usage

Ambitious Side Projects — Stars Without Adoption

# Pattern: innovative open source project
# Gets HN front page → 3K stars in a week
# Downloads: ~200/week (developers try it, don't use in production)
# 6 months later: 4K stars, still 200 downloads

# Why downloads don't follow stars:
# - The idea was exciting but the execution wasn't production-ready
# - Better alternatives exist (star was for inspiration, not adoption)
# - Niche use case (impressive but only for specific needs)

# Example pattern: novel state management library with cool demo
# Stars: 8K | Downloads: 1,500/week
# vs Zustand: Stars: 50K | Downloads: 8M/week
# The gap reveals real adoption

Low Stars, High Downloads

semver — 1.2K Stars, 95M Dependents

# The quintessential infrastructure package
# Nobody stars semver. Nobody blogs about semver.
# But every package manager on earth depends on it.

# Why stars ≠ importance:
# - Developers don't star packages they don't notice
# - Infrastructure is invisible when working correctly
# - You "discover" Tailwind. You don't "discover" semver.

# Other packages in this category:
# - glob: ~400 stars, 30M+ dependents
# - minimatch: ~1K stars, 30M+ dependents
# - ms: ~900 stars, 15M+ dependents ("2 days" → ms conversion)
# - bytes: ~600 stars, 5M+ dependents
# - mime-db: ~80 stars, used by literally everything

Transitive Dependencies — Stars Near Zero, Usage Massive

# Packages you've never heard of but are definitely installed:
npm ls --all 2>/dev/null | wc -l  # You have hundreds

# tiny-invariant: 0 GitHub stars listed, ~20M weekly downloads
# Used by React Router, which millions of apps depend on

# @babel/runtime: ~500 stars, 30M+ downloads
# Every Babel-compiled app installs this

# These packages don't need stars.
# Stars are for discovery. These are already discovered — by other packages.

The Interesting Cases: When They Diverge Mid-Life

Moment.js — Stars Accumulated, Downloads Declining

# Moment.js trajectory:
# 2015-2020: Both growing. Stars: 0 → 47K. Downloads: growing fast.
# 2020: Maintainers post "We recommend not using Moment.js anymore"
# 2020-2026: Stars: stagnant at 47K. Downloads: -28% YoY but still 14M/week.

# What this tells us:
# - Stars: frozen in time (nobody new starring a deprecated library)
# - Downloads: slowly declining as teams migrate away
# - The tail: enterprises move slowly, legacy apps persist
# - Why still 14M/week: every app that started with Moment and hasn't migrated

# The star plateau happened when the "star as bookmark" stopped
# The download decline will take 5-10 more years to fully play out

Redux vs Zustand — Similar Stars, Diverging Downloads

# Redux: 60K stars | Zustand: 50K stars (similar)
# Redux downloads: ~8M/week (but ~60% are Redux Toolkit indirect installs)
# Zustand downloads: ~8M/week and growing +25% YoY

# The star comparison: "Redux and Zustand are equally popular"
# The download reality: Zustand is growing; Redux direct usage is flat/declining

# What's happening:
# Redux stars: accumulated over 10 years, from when Redux was mandatory React state
# Zustand stars: accumulated over 4 years, from active enthusiasm today

# Younger stars = more signal. The velocity of star accumulation matters.
# Zustand got 50K stars in 4 years. Redux took 10 years to get 60K.
# Zustand is growing faster in both metrics.

The Right Way to Use Both Metrics

# Stars are useful for:
✅ Initial discovery ("is this a real project?")
✅ Relative standing at a point in time
✅ Community interest level when a project launched

# Stars are NOT useful for:
❌ Evaluating current maintenance status
❌ Comparing packages of different ages
❌ Measuring actual production usage
❌ Deciding if a package is actively growing

# Downloads are useful for:
✅ Actual adoption measurement
✅ Growth trajectory (week-over-week, year-over-year)
✅ Ecosystem health (more downloads = more users finding bugs)
✅ Comparing alternatives at the same time

# Downloads are NOT useful for:
❌ Separating new adoption from legacy usage
❌ Comparing different categories (testing vs state management)
❌ Small packages in specialized niches (100 downloads = the whole niche)

# The best combination:
→ Stars: "Does this have community legitimacy?"
→ Downloads + TREND: "Is this actually being adopted?"
→ Release date + GitHub activity: "Is this maintained?"
→ PkgPulse health score: combines all of the above

# Quick evaluation:
npm view package-name --json | jq '{
  latest: .version,
  modified: .time.modified,
  weeklyDownloads: .["dist-tags"].latest
}'
# Then check npmtrends.com for the trend chart

Package Discovery: The Star Funnel

How developers discover packages (estimated):

1. GitHub Trending / HN / Dev.to post     → Stars spike
2. Tutorial / video / blog post            → Star growth continues
3. Mentioned in popular project (shadcn uses X) → Download spike
4. Included in popular starter template    → Large download jump
5. Appears in "State of JS" survey        → Stars + downloads grow together
6. Becomes the "default choice" in category → Downloads grow, stars plateau

The funnel explains the divergence:
→ Early: stars > downloads (excitement before adoption)
→ Middle: both growing together
→ Mature: downloads > rate of star growth (usage continues, novelty fades)
→ Legacy: stars fixed, downloads slowly declining

Read stars as: "how exciting was this package at its peak?"
Read downloads as: "how many teams are running this today?"
Both matter, but for different questions.

Compare stars, downloads, and health scores side-by-side at PkgPulse.