The Paradox of Node Module Choice

Update: @ginger_beered points out that I could simply wrap the modules that concern me. This is a great, and simple, solution to my issue. For some reason, this wasn't obvious to me. I still think my post stands. I love the large selection of modules but I need to build more confidence in myself as a Node developer and gain more experience interacting with the community so I'm not wrapping every module I use.

I'm slowly building a web service in Node.js and learning to work with Node as I go. The most interesting part of this process for me has been seeing how the community works and how new developers are on-boarded through documentation and other materials. There are a couple of general observations I've made so far.

  • I don't remember anything about Javascript syntax or library functions. I'm guessing I never actually learned these things very well to begin with. I wrote a lot of client-side Javascript around 13 years ago but I probably did more copy-and-paste coding than anything else at that time.
  • The process of writing Javascript code hasn't really changed too much even though I'm writing server-side. Write some code. Restart the server or clear the REPL module cache. Check the results. Rinse and repeat. There may be better tools for developing Node apps beyond a text editor and the terminal but I haven't looked. I'm not complaining (too much), I'm just spoiled by IDEs.
  • Do I call it Node.js or just Node? Do I capitalize Node?
  • NPM is magical (except when it isn't) in the same way that APT feels magical on Linux. I have no complaints about NPM itself and, despite what I'm about to say, I plan on publishing some of my own modules.

My biggest issue at this point has to do with the sheer quantity of modules available for Node. I want to pick well maintained highly-used modules that will have minimal bugs and maximum performance optimizations (who wouldn't?). Since I plan to build a service that I will charge money to use I'm extra concerned about the reliability and maintainability of my codebase. As a new Node developer I'm having a hard time differentiating the good modules from the bad modules based on my criteria.

"Autonomy and Freedom of choice are critical to our well being, and choice is critical to freedom and autonomy. Nonetheless, though modern Americans have more choice than any group of people ever has before, and thus, presumably, more freedom and autonomy, we don't seem to be benefiting from it psychologically." — quoted from Ch.5, The Paradox of Choice, 2004 via Wikipedia

I'm currently using Express for the core of my app, PG because I'm using Heroku with Postgres, and several other standard built-in Node modules. I don't see myself going much beyond that in terms of community-built modules. I think I've identified a pretty good bcrypt module based upon the number of recent downloads, dependent modules, and Github activity. I hope to have the bcrypt module integrated into my app shortly and I'm curious to see how that goes. Maybe it's just me, but I'm finding it hard to evaluate modules and feel good about my choices with my limited Node experience. I wish choosing every module was as easy as choosing Express.

There are some strong aspects of the Node module ecosystem. It's great that I can fork a module and continue to maintain it as long as I need into the future. I'm happy to contribute bug fixes and updates to modules where I think I can be of help. I love the strong role that Github plays in the Node community and I already mentioned how great of a tool I think NPM is.

With that said, I'm getting older and the idea of needing to maintain a library that falls out of favor is not where I want to focus my energy. I also don't like the idea of needing to constantly refactor my application to accomodate the new module-of-the-month if there isn't some level of stability in a given category. I would rather pick a strong codebase that appears to have a long life ahead of it and put my time and energy into building my product. I would prefer a library system that supports longevity and promotes quality modules with the most potential for stability. Maybe the Node ecosystem does this already and I just don't have the experience to see it yet? Maybe the process I used to choose a bcrypt module is the way I'm supposed to pick all modules? Maybe there is an opportunity for a company to write Node modules that are closed-source, well maintained, well documented, and supported for the long-term? Maybe I just haven't participated in the Node community long enough to trust the community? Maybe I'm missing something obvious? I'm usually missing something obvious.