Shedding some light on the ecosystem

[jtoppine]

There was some talk elsewhere on the less than desired rate of adoption Deno is getting. Just some thought on how to improve or work around what I think is the biggest barrier users have to actually start making stuff with deno - the small, relatively immature the ecosystem around it.

My personal experience with the core deno system has been wonderful. Simple, unopinionated, ergonomic, easy, highly browser compatible, modern, fast, stable-ish, consistently asynchronous, "fun", "clean", what's not to love? I feel like deno is on a point where the developer experience by itself is a great incentive for adoption. Judging from that, developers should be flocking around deno.

The main hurdle is the small amount and immaturity of third party modules. Obviously that situation can only be improved by deno gaining momentum/adoption. What we can do, though, is helping users to find what good there already exist on the ecosystem.

The deno.land/x is a frustrating experience as there so much noise from unmaintained or just plain placeholder modules (early name-grabs and such). The star system does not really tell much whether the module is actually usable, mature or maintained. It's incredibly frustrating, hard detective work to find anything useful from there.

Users need help finding modules they can actually use to accomplish stuff. Rather than finding stuff from random articles around the net, I think it would be super helpful if there was some curated information on the official website. I propose two things:

A manually curated list of the "good stuff" somewhere clearly visibile on deno.land. To be on this list, for ease of maintenance and minimizing noise, the modules should:

• be somewhat stable/mature
• have a big enough scope (no one-liners or other tiny utility classes, but actual libraries)
• have a somewhat wide appeal for developers

Unfortunately at the current state of the ecosystem, this would not be a huge list, and it would be feasible to maintain manually.

I understand if deno does not want to officially enforce some third party packages over others, but at this point I think users gravely need help navigating the ecosystem, and this would be a justified.

Just a few examples of the modules that should be covered: oak, sqlite, canvas

Another page again on deno.land, dedicated for users coming from node/NPM. This would involve identifying and listing the most popular, essential Node modules from NPM. For these, we would have notes on how to accomplish the same task in Deno. If any of the following things apply, it would be explained:

• is there a deno port
• can any of the newer web standard API's supported by deno be used to accomplish the same task (sqlite->webstorage)
• is there a deno package that answers the same problem (express->oak)
• can the NPM module in question be used "as is" in deno through esm.sh or such service, if so, how.

---

Just some thoughts for your consideration, I truly hope deno soon gains the momentum it deserves!