One of the things I’ve seen people remark on is that it can be difficult to figure out whether there’s a package that does what you need. Is there a UI framework? What’s the best way to do CSS? What about a date picker?
Especially when you’re starting out with Elm, it can be a frustrating process of fumbling around in the dark. Not only you’re learning the language, but you also have to find the relevant packages. If I want to animate the UI, are the packages to help me? Or should I roll my own? What do I search for, and where? Package index, Google, GitHub, Discourse? And which packages are the most popular?
I thought, what if there was a catalog that simply organised packages into categories? That would make it easier to find what you need!
So I rolled my sleeves up, and with the help of my favourite Elm package, mdgriffith/elm-ui, set it up:
Another thing I was interested in is making it easier to find gaps in package availability. If somebody is looking for a project, they can easily find something that’s not already been done. For example, is there a package that helps you work with the Google Maps API? No, there doesn’t seem to be one in the Maps section – that was easy!
I’ve only included ~260 packages in the catalog so far, which is a small portion of all the published packages (~1400 I believe). Nonetheless, it shows there’s already quite a lot of different categories covered: from UI widgets to text processing packages.
But how do I choose the best package?
Inevitably, the question of metrics comes up. When there are multiple packages that parse CSVs, for example, how do I choose the best one? Wouldn’t it be nice if there was a metric of package quality, so that popular and well supported packages float up to the top?
The obvious idea is to start pulling in star counts, release information, issue activity and so on from GitHub. However, metrics may also promote certain behaviours from package authors, and I’m wary of recreating the NPM rat race in Elm.
For example, if the latest release date was used as a proxy signal for package quality, it might encourage authors to make more releases. I think a valuable aspect of Elm is that it’s sort of the frontend programming equivalent of the “slow food” movement, and we should be careful not to disrupt it. (Mind you, I don’t know if it’s ultimately the way to go about software development, but it’s certainly a worthy experiment.)
So for now I’m thinking about what metrics might be useful, and whether it’s still OK to do without them.
