Week 12 at an Unbootcamp

The things Learners are learning at Learners Guild is, in substantial part, “packages”, designed to make commonly performed operations easier than just writing the code for them from scratch. But they also add to the complexity of the ecosystem we are learning to work in.

Packages

The week ending on 28 July was my 12th week of study at Learners Guild in Oakland. I worked on 6 different projects. Through them, I learned how to apply more basic techniques of JavaScript web application development.

Some of what we learn is the JavaScript language itself—a language that changes once per year, so that learning never ends.

But it seems that more of what we learn, and will increasingly learn, is packages. They basically do things that you, the programmer, could do with the raw languages and protocols of web programming (mainly HTTP, HTML, CSS, JSON, and JavaScript), but they (allegedly) make it easier to do those things.

During the week my projects required me to learn how to use these packages:

fs, which handles directories and files

http, which handles transactions between computers

cheerio, which interrogates and manipulates documents written in HTML

request-promise-native, which manages a computer’s requests to other computers

pg, which manages a program’s use of PostgreSQL databases

express, a system for combining programs into an application delivered on the web

Some of these packages, in turn, are entire ecosystems to which other developers have contributed packages. For example, the express package has about 12,000 related packages, and the express website names 12 “popular” frameworks built on express. It’s been dawning on me that learning to use packages is only part of the challenge posed by packages. Another part is figuring out which packages to learn to use. This is not trivial, because there are many to investigate, and it can take hours of study and testing before one discovers that a package is not as good for one’s purposes as it had seemed.

As a result, wise folks advise us to choose popular packages. They argue that popular packages are not only vetted by others, but also likely to stay alive long and be updated often. It’s not hard to learn which packages are popular. At the npm site, where most significant JavaScript packages are distributed, you can order the search results by popularity. In a search for “express”, express itself is at the top of that list, and you can see, today at least, that it has been downloaded 543,571 times in the last day. There are also surveys with published statistics on the popularity and “mind share” of JavaScript frameworks. If, however, you want to do something unpopular (e.g., innovative), an unpopular package may be best, or perhaps you should develop your own, or just write your code in the basic languages of the web.

The modules we work on at Learners Guild take various stances on packages, reflecting the diversity of environments we can expect to face in the outside world. They sometimes tell us not to use any package; or to use plain JavaScript to reimplement functions that a package performs; or to use a particular package; or to use any package(s) we may wish to use. In most cases, they prescribe particular packages that are widely used, and that we therefore should become familiar with.

Perhaps some have fantasies of “mastering” a language such as HTML or JavaScript. The more I learn of them, the less plausible such aspirations seem. But the idea of mastering the universe of JavaScript-based programming, including all its packages, is absurd. We are aiming to know a lot, but above all to know how to learn what we need but don’t know. And to ask for help in moderation, and to give help usefully. And to be good collaborators. That’s plenty.