Post

I don’t get what it represents. One of those packages has 2 releases in 6 months but you’d never guess which one. It’s not like it’s a complete project either, it has a ton of open issues. How would you balance a “done” solution vs something new in active development anyway? This shouldn’t exist imo

There are larger packages because they do more, packages that can be tree-shaked to be smaller, and larger packages with faster runtime performance. Bundle size matters mostly on the client anyway, assuming it’s not a devDependency like my example. This feature just isn’t helpful and should be gone

check quadrant graphs here, and find hidden gems by playing with other set of packages

it seems the most important thing in this graph is install size on disk (any package that happens to bring along some cli tools who they themselves have some tech debt really tanks the ranking here) :(

When a Moob user prioritizes quick downloads and minimal storage, could those factors then become part of *their* definition of 'ergonomics'?

I suppose we could play tricks with the package layout and try to arrange modules to share ones that are the same across dev, prod, and node builds. That would save some disk space but hurt developer ergonomics by making the installed source harder to navigate.

Dependencies is an unfortunately vague metric. Lit is published as a main `lit` pkg that composes 3 other core packages. This is so people can use the other packages, like `lit-html`, without pulling in all of Lit. So overall, we're trying to reduce dependencies, but `lit` will get dinged for it 😟

My lib is a hidden gem! 🤗