NodeJS and Javascript libraries are overwhelming students

Question

I started teaching NodeJS to some of the students in the computer science major at my school (these students know the basics of Java and OOP).

The idea is for them to make a small web project (such as a grades and averages calculator or a display for a timetable etc.) using javascript.

I plan to teach about javascript, client-server separation, http requests etc. The main problem is the vast number of JS libraries in existence. I intend to emphasize that most of the code is already written. E.g. the code for creating nice graphs exists in charts-js, and responsive client side frameworks (angular, react) exist.

This project is also meant to teach the notion that programmers rarely write programs from scratch, and that they should often see if there exists a library\framework that give a functionality they need.

However, with Javascript, the vast number of libraries makes it somewhat difficult to know which ones to pick. It's not impossible, but I'd rather students not waste time on that.

I ran this by a handful of students, to see whether students actually get overwhelmed. From what I saw, students are likely to waste time reading up about the library they are checking (somewhat like reading a review for a PC before buying it). Research is great, but the amount of wasted time was quite big.

So, what can I do to teach them how to "sniff" the "correct" library more efficiently? In other words, how can I teach them which metrics are significant (and why those metrics are important) when deciding whether a library is useful? Bearing in mind that the time it takes is to be considered, I'd prefer ways and metrics that are generally faster (e.g. reading up the documentation of a library is somewhat slower when compared to checking npm's download in the last day)

---

¹Unless they program in Scratch.

Answer 1

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.

Answer 2

How would you do it yourself? If you are already effective at it, then show them how you approach it. Tell them where you look, and tell them how you decide that it is ok to stop exploring further for an individual resource or for the overall search.

Otherwise, assuming you are less skilled at this than you'd like to be, give them (paper or electronic) a list of resources you have found with some added metrics that you would find useful for judgement. It needn't be comprehensive, but complete enough to cover their own needs at the moment. In the latter case, along with your list of resources, you can list one or two advantages and one or two disadvantages of each.

Since you want them to learn how to acquire resources, rather than just pick one of yours, you could also say where you found the resource and where you got the most important information about it.

It might be worth some face-to-face time for discussion of your list and your criteria with opportunities for students to ask questions.

---

Let me note that this question is actually more general than the presented context. It also applies to, say finding an IDE and to finding a suitable language for some project. Finding useful tools is a good skill to have.

Answer 3

This sounds like a question of vetting. Here are some things I do when evaluating Node.js libraries:

1. Find the package in npmjs.com and view the stats (e.g., daily/weekly/monthly downloads). You can sort of gauge its popularity that way.
2. Look for similar libraries and compare their stats.
3. Look at the package in GitHub. View those stats (e.g., # of contributors, # of releases, # of stars).
4. View the GitHub documentation (README.md). Is it helpful, mature, professional?
5. Look at the GitHub commits. Are they recent? Is the repo actively maintained?
6. Finally, just try it out. Sometimes you need to test a few libraries to see which one is better for your application.

These are just some rules of thumb. But it helps the weed out process.