I agree that stars alone don't equate to reliability, which is why I used (the very much imperfect, but better) stars/issue as part of the evidence.
While I'm unaware of research supporting stars/issue, it's a useful rule-of-thumb at the extremes. With React (318), if something isn't working, your code is almost certainly wrong. With Bun (24), if something isn't working, it's likely Bun (sorry, Jarred).
The assertion the Remix creators are "extremely hostile to anything resembling stability" should place Remix at the lowest extreme, but that isn't so.
If you use a metric or rule-of-thumb for evaluating reliability, I'm curious to hear it.
Gotcha so that is sort of a precursor to a deeper inquiry it sounds like. I'm concerned it sounds like there may be a strong bias in favor of popularity. Maybe that is less of an issue for developers already shopping within a specific stack/philosophy though.
I tend to try and ignore stars, because I've been burned by popular and unpopular projects alike. They also seem to be gamed at times. For an initial evaluation of something I might actually use I look at who the owners are, when the project was last updated, and explore the issue tracker (including closed tickets). That is usually enough to identify projects with major problems. If they pass the initial audit, then the process continues.
While I'm unaware of research supporting stars/issue, it's a useful rule-of-thumb at the extremes. With React (318), if something isn't working, your code is almost certainly wrong. With Bun (24), if something isn't working, it's likely Bun (sorry, Jarred).
The assertion the Remix creators are "extremely hostile to anything resembling stability" should place Remix at the lowest extreme, but that isn't so.
If you use a metric or rule-of-thumb for evaluating reliability, I'm curious to hear it.