NodeJS and Javascript libraries are overwhelming students
Summary


Node.js has an unusually complex ecosystem which you don't get in some other languages.
Your students spending time to intelligently pick the best libraries is great, but you might need to stop them from being bogged down.
If time is really a problem, simply take away the choice, but keep in mind that you take away a powerful (and necessary) learning experience.
Remember that not every problem needs a library; it's fine to re-implement simple things yourself!




Node.js (and the JavaScript world in general) seems particularly prone to short-lived, highly popular libraries and frameworks which re-invent existing features in different ways. You need only see the Stack Overflow blog which illustrates this trend well enough:


  


I've developed web applications in the past where I've agonised over the choice of libraries for hours — even days — trying to find that perfect combination which will avoid all these potential future issues... issues which, it turned out, weren't likely in the first place at the scale I was working at.

Initially, I heard great things about React, so I decided to add that to my project. Then I need a 'Flux framework' too so I can handle events in a React way. So I pick one like Redux. But React doesn't degrade so well for clients without JavaScript — oh no! Luckily, there's already a solution for that — server-side rendering. So I plan to use that too. I'm sending a lot of assets at once now, which is starting to get slow, so for HTTP clients I want to bundle my assets with Webpack. But I don't want to do that for HTTP/2 clients because that's actually slower again.

That's not even the end of the story, but you're starting to get the picture of just how many pieces exist in the JavaScript world. I honestly don't know many other languages that are so chaotic vibrant with their library ecosystem.



Honestly, your suggestion of just going by the download counts seems unwise in some respects. While popularity does probably offer a good indication of maturity and stability, it doesn't tell you whether the library actually does what you want, in the way you want.

Let's take my React example again. Yes, it's popular, and indeed, it is a front-end framework, but it requires a lot of 'buy-in' — you have to deliberately design your pages around React to get much out of it. jQuery might fit my use-case perfectly, despite being a little less popular, but by just picking the popular library, I'm stuck with even more work.

As an analogy, how do you pick which car you want to buy? You probably don't buy a Ford Fiesta just because everyone else did. You probably take a look at the specifications, fuel economy, and perhaps give it a test drive.

Putting that investment in and learning a little about the popular libraries is well worth it. You only have to do it once to learn the philosophy and the goals of that project, and once it's done, you know when you want to pick that library above the others.

You can try and tell them metrics to look at... or you can accept that you need to dedicate time to trying the popular libraries, and getting that 'test drive'. Spend a lesson trying React, and get your students to tell you what they think. Going beyond the trivial 'Hello world' might be helpful (I hear the TodoMVC example is fashionable and more complex).

Or, if you can't afford the time, I think you'll simply have to tell your students which library you want them to use. What your students are doing now is great, if a little inefficient. You can help by prodding them in the right direction — share what you know, and give them a nudge if they start burying themselves in too many libraries. 

Sometimes, I think all that's needed is a little poke to say that not all JavaScript projects need to handle every possible future concern, and to Keep it Simple, Stupid.