My understanding is that npmx aims to be "A fast, modern browser for the npm registry. Speed first, URL compatible, and simple", therefore, I think it should not be picking winners. If npm shipped something similar, I would ask the same to them.
Registries sit on a trust monopoly
A package registry occupies a position of near-total leverage over an ecosystem. It is the single point through which almost every install flows, and the text it displays is read by millions of developers who reasonably assume they are seeing neutral infrastructure rather than editorial opinion. That trust is the registry's actual product. The moment it starts telling people which of two actively maintained projects they should be using, it stops being a distribution channel and becomes a kingmaker, and every subsequent recommendation carries the suspicion of politics, commercial relationships, or the personal taste of whoever holds commit access to the recommendation list.
Facts and opinions are not the same signal
There is a clear line between factual metadata and editorial judgment, and it is worth being precise about where it falls. Stating that a package has not published in four years, that its repository is archived, that its maintainers have publicly stepped away, or that it carries an unpatched advisory, all of these are verifiable facts about the state of the world. They reduce information asymmetry and help a developer make a decision. Stating that a maintained framework has a preferred successor is a different act entirely. It is a claim about which technical tradeoffs matter, made on behalf of a user whose constraints the registry cannot possibly know.
The registry cannot see the constraints that matter
Those constraints are the crux of it. A developer choosing between two live frameworks is weighing bundle size, cold start behavior, plugin ecosystems, hiring pool, migration cost across a codebase with hundreds of call sites, and internal expertise that took years to build. A registry sees download counts. Download counts measure incumbency and tutorial gravity far more than they measure fitness for any particular use case, and elevating them into a recommendation creates a feedback loop where popular things become more popular because they were flagged as popular. That loop actively suppresses the newer, smaller, better-designed project that the ecosystem needs in order to advance.
The cost lands on maintainers
The consequences fall hardest on maintainers, and they are not evenly distributed. A registry-level suggestion pointing away from a healthy project is a direct hit to its adoption curve, delivered without appeal, without a defined standard, and without the maintainers having done anything wrong. Anyone who has watched a corporate-backed project and a volunteer-run alternative compete for the same niche understands what happens when the platform puts its thumb on the scale. It also invites exactly the lobbying you would expect, since influencing one registry field becomes cheaper and more effective than winning users on merit. Maintainer burnout is already the ecosystem's chronic condition, and telling people their working software is the wrong choice is a fast way to accelerate it.
Registries publish facts, communities publish opinions
The healthy division of labor is that registries publish facts and communities publish opinions. Deprecation notices, archived-repository signals, advisory data, last-publish dates, and maintainer-declared successors all belong in the registry, because they are either objective or explicitly authored by the people who own the package. Comparative recommendations belong to blog posts, conference talks, benchmarks, framework documentation, and the ordinary argumentative churn of a technical community, where claims can be contested, context can be supplied, and nobody has a monopoly on distribution. A registry that stays inside its lane keeps its credibility, and its credibility is what makes the genuinely important warnings, the abandoned packages and the unpatched vulnerabilities, actually get read.
The reason for this post is this page:
and possibly more like this. Express is a well-maintained library that powers a significant part of the ecosystem. It does not deserve this, and there are plenty of good reasons to use it today. More importantly, there are plenty of alternatives to choose from, and it's not the registry's business to pick one.
There are plenty of other similar packages listed as replaceable, but there are plenty of reasons to keep using them, and, more importantly, they are not abandoned and support a large part of the ecosystem.
I recommend limiting the suggestion of alternatives to packages that are clearly abandoned.
My understanding is that npmx aims to be "A fast, modern browser for the npm registry. Speed first, URL compatible, and simple", therefore, I think it should not be picking winners. If npm shipped something similar, I would ask the same to them.
Registries sit on a trust monopoly
A package registry occupies a position of near-total leverage over an ecosystem. It is the single point through which almost every install flows, and the text it displays is read by millions of developers who reasonably assume they are seeing neutral infrastructure rather than editorial opinion. That trust is the registry's actual product. The moment it starts telling people which of two actively maintained projects they should be using, it stops being a distribution channel and becomes a kingmaker, and every subsequent recommendation carries the suspicion of politics, commercial relationships, or the personal taste of whoever holds commit access to the recommendation list.
Facts and opinions are not the same signal
There is a clear line between factual metadata and editorial judgment, and it is worth being precise about where it falls. Stating that a package has not published in four years, that its repository is archived, that its maintainers have publicly stepped away, or that it carries an unpatched advisory, all of these are verifiable facts about the state of the world. They reduce information asymmetry and help a developer make a decision. Stating that a maintained framework has a preferred successor is a different act entirely. It is a claim about which technical tradeoffs matter, made on behalf of a user whose constraints the registry cannot possibly know.
The registry cannot see the constraints that matter
Those constraints are the crux of it. A developer choosing between two live frameworks is weighing bundle size, cold start behavior, plugin ecosystems, hiring pool, migration cost across a codebase with hundreds of call sites, and internal expertise that took years to build. A registry sees download counts. Download counts measure incumbency and tutorial gravity far more than they measure fitness for any particular use case, and elevating them into a recommendation creates a feedback loop where popular things become more popular because they were flagged as popular. That loop actively suppresses the newer, smaller, better-designed project that the ecosystem needs in order to advance.
The cost lands on maintainers
The consequences fall hardest on maintainers, and they are not evenly distributed. A registry-level suggestion pointing away from a healthy project is a direct hit to its adoption curve, delivered without appeal, without a defined standard, and without the maintainers having done anything wrong. Anyone who has watched a corporate-backed project and a volunteer-run alternative compete for the same niche understands what happens when the platform puts its thumb on the scale. It also invites exactly the lobbying you would expect, since influencing one registry field becomes cheaper and more effective than winning users on merit. Maintainer burnout is already the ecosystem's chronic condition, and telling people their working software is the wrong choice is a fast way to accelerate it.
Registries publish facts, communities publish opinions
The healthy division of labor is that registries publish facts and communities publish opinions. Deprecation notices, archived-repository signals, advisory data, last-publish dates, and maintainer-declared successors all belong in the registry, because they are either objective or explicitly authored by the people who own the package. Comparative recommendations belong to blog posts, conference talks, benchmarks, framework documentation, and the ordinary argumentative churn of a technical community, where claims can be contested, context can be supplied, and nobody has a monopoly on distribution. A registry that stays inside its lane keeps its credibility, and its credibility is what makes the genuinely important warnings, the abandoned packages and the unpatched vulnerabilities, actually get read.
The reason for this post is this page:
and possibly more like this. Express is a well-maintained library that powers a significant part of the ecosystem. It does not deserve this, and there are plenty of good reasons to use it today. More importantly, there are plenty of alternatives to choose from, and it's not the registry's business to pick one.
There are plenty of other similar packages listed as replaceable, but there are plenty of reasons to keep using them, and, more importantly, they are not abandoned and support a large part of the ecosystem.
I recommend limiting the suggestion of alternatives to packages that are clearly abandoned.