Echo JS 0.11.0

Shameless plug: https://github.com/foss-haas/rotunda

I think the examples are not very useful. I don't think many people make high-level tool or framework choices based on arbitrary metrics -- APIs are far more important than GitHub stars.

But this might be useful when trying to find a library where the APIs are mostly irrelevant (e.g. because you just want to solve a specific problem), e.g. comparing lodash vs underscore vs ramda (vs ...). Or even comparing various different packages providing implementations of underscore's/jQuery's extend function when you don't want to add a major dependency like underscore or jQuery just for that function (my current preference is the `extend` package -- the obvious name certainly helps).

I've been in that situation several times -- trying to decide between multiple nearly identical packages and figuring out which one is the safest bet. However I think the most time consuming part is *finding* the different alternatives, not comparing their stats. A difference between 2M and 3M downloads barely matters while a difference between 10k and 10M certainly does.

> If you choose to use class, I hope I never have to try to maintain your code. In my opinion, developers should avoid the use of constructors, class, and new, and use methods of inheritance which more closely follow the language architecture.

How quaint.

Unlike `with` and its ilk, using `class` in and of itself is not a problem. It's a smell at best. And relying on smells alone can lead to false positives.

I'm a JS programmer. My use of (modern) JS was not preceded by a class-based language like Java or C# but Python, which itself frequently prompts discussions about the merits of classes over functions and plain objects (although Python has no other form of inheritance than classes).

I don't see new/class-style inheritance as a problem. It's another gun in the weapons rack and like all guns it provides plenty of ways to shoot yourself and/or others. But unlike `with` and other things that should be avoided no-questions-asked, it's not a pure footgun.

Crying foul at the introduction of a more sugary syntax for the constructors-and-prototypes idiom and deriding "this" as evil is reactionary at best, xenophobic at worst. JS "classes" are not the devil and they are here to stay. You can limit yourself to a "class-free" subset of JS if you find them so appalling but a stubborn wilful ignorance of idioms you personally object to does not make you a better programmer -- it only lets you stagnate in isolation.

You can pretend JavaScript is Haskell and use broken implementations of monads, you can pretend constructors and methods don't exist and drown in a low-level sea of factories and prototypes, you can cast rocks at anyone who dares consider jQuery, but at the same time the rest of us will be out there, using the right tools for the job and getting shit done.

EDIT: I think it's important to realize that it's not classes but inheritance that causes the most problems and is most abused. It doesn't matter whether your inheritance is prototypal or classical (emulated through prototypes -- a feat that can not be achieved the other way around). Most cases of inheritance would be better served by composition. JS classes are just a nice way to create thin object factories -- inheriting between them should be considered meta-programming and thus be used sparingly and carefully.

The question about port 80 is *not* a trick question. There are ways to listen on port 80 without superuser rights on *nix systems. Whether your code should be listening on port 80 in the first place is a different question. In any case I wouldn't expect a candidate (who is likely nervous and not thinking straight) to catch that low ports are special and infer you're asking about running apps in production.

I'd also say that the use of NPM shrinkwrap is not universally accepted as a best practice for actual deployment. Running "npm install" in production deployment is contentious for all the same reasons relying on GitHub is. Plus, even with shrinkwrap there are some situations in which the installs will be slightly different. A common alternative is just committing `node_modules` as well -- while this is definitely not a best practice for libraries, it avoids a lot of problems with deployment, as long as your development and production environments are sufficiently similar.

Also, the term "stub" isn't unambiguous. I would rephrase the question as "What are stubs, spies or mocks?" (the exact differences between them being less important than familiarity with the general idea behind their use).

I wouldn't have known what the term "test pyramid" is supposed to mean despite being familiar with the concept -- the exact differences between integration and acceptance tests and unit and integration tests tend to be contentious issues (the term "unit" is difficult to define) and not everything can be meaningfully tested in isolation.

Other than that, I mostly agree with the questions. It's probably more important to consider these as conversation starters to get a feeling for the candidate's general aptitude and opinions rather than a checklist to base a hiring decision on -- but these checklists tend to be worthless in real life anyway.