Since this specifically calls out Front End frameworks, I'm going to offer feedback as to what I feel about the "suggestions"
First, any such curation comes down to who does the curation, and what the criteria are for making the list or not. This isn't disclosed in any meaningful way I can discern. Personally, I tend to favor modules backed by a company or organization, not falling to a single person. I will also look at open issues, and how old issues are. Beyond all of this, I will look at download counts and age of the source. I avoid modules that don't have corresponding source code publicly available.
Second, looking through a lot of suggestions, they aren't needed most of the time, and the listed suggestions only add a lot of unneeded abstraction and bulk to your payload. There's a lot of bad advice here.
HTTP Requests: Don't use a 3rd party module. Just create a thin wrapper around fetch as needed. If you *must* support legacy browsers, use the official shim. You don't need additional modules for this. Axios is nice enough, but even then, it's really overkill a lot of the time.
Web Frameworks: While I personally like Koa a LOT more for creating my own workflows for a number of request wrappers for common API handling, Express has pretty much won. I feel tooling like Hapi and Sails just serves to add complexity without enough benefit to really justify it.
Validation: I don't have strong opinions here. I'd much rather see edge validation than ORM/ODM in practice.
Authentication: While passport works, and has a lot of flexibility, it's also complicated and may be overkill for your needs. Use lower level libraries and/or roll your own at least once, so you understand it better before going in and just doing what everyone says. My advice here is a lot like all of the "Enterprise" patterns I've seen used in .Net and Java. Most of the time, you really don't need them.
Asynchronous: Native Async functions, and Promises. Don't bother with the Async library. All modern browsers now support ES2017's async functions and promises well enough, including the past couple years of Node. If you're using babel, make sure that async/generator transforms are explicitly disabled.
Database: Once again, use the native adapter and avoid ORM use. ORM are a ton of boilerplate for very little real world benefit, especially if you're dealing with a structured database. I *do* suggest using a tagged template string library, this lets you do query injection that looks like native string handling...
const result = await query`
SELECT * from Foo WHERE bar = ${baz}
`;
It's incredibly effective in practice. There are a few libraries that separate the template composition from the database library, but I'll usually wrap them to combine them so it can be used like above.
Process Management: use these for local development, defer to system options for actual deployments. With Linux systemd and even windows, you can establish restart options and output redirection at the OS layer. They also have options to restart after failure. I suggest nodemon for local Node development, however Webpack already has it's own listener in the box, and I suggest that for front end dev.
Web Sockets: Grr, just no to Primus... it's yet another bluky enterprisey abstraction almost for its' own sake. Look at the underlying supported frameworks and just pick one.
API Documentation: I have mixed feelings here, getting swagger compliant docs takes a *LOT* of effort, and without static typing, you won't get it for nearly free like you can with say .Net or Java. I'm not sure if there are any TypeScript libraries that would give you this for free. You may be better off with clearly written documentation for your authentication, and have `curl` examples for your access methods or rest endpoints.
Utilities: Lodash or Ramda, only if you really need theme, and cherry pick the methods you need. Try to stick with the functional versions as they'll work better for composition.
Moment - *NO*, don't do it, this library is massive and there are better options. date-fns or look at Luxon which is a similar/smaller library from the developers that made Moment JS.
UUID - as to the "hard to crack" comment, not sure where that comes in.
NVM - note, this really only works well in *nix environments. You can actually `npm install node@version` in your project to use a specific version tethered to your application. All node scripts will do that... Related tip, prefix ./node_modules/.bin to your PATH environment. This way you can use localized utils without needing to call via npm scripts.
fs-extra - it's a really nice library... I often just fallback to shelljs when I need more system level interactions. Often for build/automation scripts etc, you shouldn't be relying on this type of functionality inside your application.
DotEnv - yes. All your external configuration options should be injected via .env, also, use fallbacks to default to local development. Reduce friction for your teams and the people you work with.
CLI: I don't have a lot of immediate input here, both suggestions work.
Logging: Suggestions are suitable, but you may or may not need that level of complexity.
Templating: The suggested options are fine... depending on your needs, you can also use lodash templates (ES6 Syntax works).
Testing: Jest all day... even if you aren't doing React, getting everything configured in the box is so much nicer than trying to get code coverage working with the other options. Sinon is fine as a utility to use with. Add Enzyme if you're doing React.
Tooling: suggestions are fine... for eslint, I'd use the prettier defaults and add prettier. There's plugins for VS Code etc to adjust the autoformating as well. Husky to run lint as a precommit hook.
In the end, take articles and suggestions like these with a grain of salt. The more you do, the less you really need to bring in a lot of the suggested modules which can add a lot of overhead.
Im happy this worked for your projects but saying dont use this or that sounds pretty bossy. There are use cases for every library suggested in the article. Saying something like dont use an ajax lib or ditch orm and write sql queries by hand is just not a sound advice without explaining when one would work better over another.
Axios is probably fine, however fetch is in all modern browsers, and using it directly is generally a better option.
ORM in a dynamic language is generally more boilerplate than it is worth, and doesn't integrate nearly so well at the API level for type checking or input consistency. It adds a lot of work for almost no advantage at all. It also creates layers of abstraction and complexity that make it harder to onboard developers and more costly to support in the long term.
Since this specifically calls out Front End frameworks, I'm going to offer feedback as to what I feel about the "suggestions" First, any such curation comes down to who does the curation, and what the criteria are for making the list or not. This isn't disclosed in any meaningful way I can discern. Personally, I tend to favor modules backed by a company or organization, not falling to a single person. I will also look at open issues, and how old issues are. Beyond all of this, I will look at download counts and age of the source. I avoid modules that don't have corresponding source code publicly available. Second, looking through a lot of suggestions, they aren't needed most of the time, and the listed suggestions only add a lot of unneeded abstraction and bulk to your payload. There's a lot of bad advice here. HTTP Requests: Don't use a 3rd party module. Just create a thin wrapper around fetch as needed. If you *must* support legacy browsers, use the official shim. You don't need additional modules for this. Axios is nice enough, but even then, it's really overkill a lot of the time. Web Frameworks: While I personally like Koa a LOT more for creating my own workflows for a number of request wrappers for common API handling, Express has pretty much won. I feel tooling like Hapi and Sails just serves to add complexity without enough benefit to really justify it. Validation: I don't have strong opinions here. I'd much rather see edge validation than ORM/ODM in practice. Authentication: While passport works, and has a lot of flexibility, it's also complicated and may be overkill for your needs. Use lower level libraries and/or roll your own at least once, so you understand it better before going in and just doing what everyone says. My advice here is a lot like all of the "Enterprise" patterns I've seen used in .Net and Java. Most of the time, you really don't need them. Asynchronous: Native Async functions, and Promises. Don't bother with the Async library. All modern browsers now support ES2017's async functions and promises well enough, including the past couple years of Node. If you're using babel, make sure that async/generator transforms are explicitly disabled. Database: Once again, use the native adapter and avoid ORM use. ORM are a ton of boilerplate for very little real world benefit, especially if you're dealing with a structured database. I *do* suggest using a tagged template string library, this lets you do query injection that looks like native string handling... const result = await query` SELECT * from Foo WHERE bar = ${baz} `; It's incredibly effective in practice. There are a few libraries that separate the template composition from the database library, but I'll usually wrap them to combine them so it can be used like above. Process Management: use these for local development, defer to system options for actual deployments. With Linux systemd and even windows, you can establish restart options and output redirection at the OS layer. They also have options to restart after failure. I suggest nodemon for local Node development, however Webpack already has it's own listener in the box, and I suggest that for front end dev. Web Sockets: Grr, just no to Primus... it's yet another bluky enterprisey abstraction almost for its' own sake. Look at the underlying supported frameworks and just pick one. API Documentation: I have mixed feelings here, getting swagger compliant docs takes a *LOT* of effort, and without static typing, you won't get it for nearly free like you can with say .Net or Java. I'm not sure if there are any TypeScript libraries that would give you this for free. You may be better off with clearly written documentation for your authentication, and have `curl` examples for your access methods or rest endpoints. Utilities: Lodash or Ramda, only if you really need theme, and cherry pick the methods you need. Try to stick with the functional versions as they'll work better for composition. Moment - *NO*, don't do it, this library is massive and there are better options. date-fns or look at Luxon which is a similar/smaller library from the developers that made Moment JS. UUID - as to the "hard to crack" comment, not sure where that comes in. NVM - note, this really only works well in *nix environments. You can actually `npm install node@version` in your project to use a specific version tethered to your application. All node scripts will do that... Related tip, prefix ./node_modules/.bin to your PATH environment. This way you can use localized utils without needing to call via npm scripts. fs-extra - it's a really nice library... I often just fallback to shelljs when I need more system level interactions. Often for build/automation scripts etc, you shouldn't be relying on this type of functionality inside your application. DotEnv - yes. All your external configuration options should be injected via .env, also, use fallbacks to default to local development. Reduce friction for your teams and the people you work with. CLI: I don't have a lot of immediate input here, both suggestions work. Logging: Suggestions are suitable, but you may or may not need that level of complexity. Templating: The suggested options are fine... depending on your needs, you can also use lodash templates (ES6 Syntax works). Testing: Jest all day... even if you aren't doing React, getting everything configured in the box is so much nicer than trying to get code coverage working with the other options. Sinon is fine as a utility to use with. Add Enzyme if you're doing React. Tooling: suggestions are fine... for eslint, I'd use the prettier defaults and add prettier. There's plugins for VS Code etc to adjust the autoformating as well. Husky to run lint as a precommit hook. In the end, take articles and suggestions like these with a grain of salt. The more you do, the less you really need to bring in a lot of the suggested modules which can add a lot of overhead.