Эффективное использование process.env

Я еще могу добавить что черезмерное обращение к переменным окружения через `process.env` может негативно сказаться на производительности.
github.com/nodejs/node/issues/3104
github.com/facebook/react/issues/812

Если надо часто обращаться к значению в переменных окружения — лучше закешировать.

Глупый JS. Делаем фильтры «по красоте»

Консоль ни при чем, это понятно.
Вот тут, ИМХО, гораздо понятнее и нету сомнительных трюков с битовыми операторами:

function filter(val, list){
  console.time('test')
  return list.filter( i => i.includes(val) )
};

Глупый JS. Делаем фильтры «по красоте»

Array.prototype.filter — это ES5, а не ES6

Если говорить об ES6 то почему бы не использовать Array.prototype.includes вместо вот этого

~i.indexOf(val)

в

function filter(val,list){
console.time('test')
  return list.filter(i=>(~i.indexOf(val)))
};

?
И красоты, тут, честно говоря, лично я не наблюдаю.

Используем async/await в nodejs уже сегодня

Речь шла про пол года назад.

Статья опубликована сейчас. И комментарий вы писали сейчас, а не пол года назад.
1. Я не считаю try-catch целесобразным ВЕЗДЕ, но придумывать какие-то механизмы, что бы их не использовать, но возвращать ошибку в качестве второго аргумента, и не использовать механизмы, которые предоставляет язык, это я считаю неверным. Как я уже писал причина — в языке используются другие подходы для обработки ошибок и, я уверен, большая часть программистов, привыкла использовать их, а не придуманные решения только что бы не использовать try-catch т. к. это часть оптимизации (по факту — микрооптимизация, высока вероятность, что в будущем этот механизм в V8 будет оптимизирован еще сильнее).
2 — Приведенная вами конструкция, призванная заменить Promise.all — опять же зачем, если есть инструмент языка, зачем эти велосипеды?

Используем async/await в nodejs уже сегодня

8.3 еще небыло

Это о NodeJS?
тогда советую проверить nodejs.org/en
8.9.1 уже в LTS, и 9-я подоспела.

Используем async/await в nodejs уже сегодня

3. Цитата из приведенной вами статьи

Однако, в Node 8.3+ вызов функции из блока try на производительность практически не влияет.

И еще раз. Программы пишутся в первую очередь для людей. Я нигде не видел, что бы подход, приведенный вами практиковался в JS, зачем усложнять жизнь другим программистам?
Да, try-catch может влиять на производительность, если это узкое горлышко, то задача не для NodeJS.

4) Promise.all возвращает результат (либо в .catch(), либо в try-catch(e) {} ) если хотя бы один из промисов вернул ошибку, и не надо будет дожидаться всех остальных.

Используем async/await в nodejs уже сегодня

2. Promisify отдаст Promise (точно так же как и ваша функция). Что мешает делать await для промиса? Более того, async-функция возвращает promise с then и catch.

const {promisify} = require('util');
const {readFile} = require('fs');
const readFilePromise = promisify(readFile);
async run() {
  const fileData = await readFilePromise('./package.json', 'utf8');
}
run().catch(console.error);

3. Если нагрузка такова, что try-catch играет роль — это задача ИМХО не для NodeJS. При таком подходе (предложенном вами) читаемость сильно страдает.
4. Не понял чем мешает Promise.all. Если выполняется несколько запросов к бд внутри транзакции, то что мешает сделать что-то вроде (не уверен, кстати, будет ли это вообще иметь смысл, т.к. возможно внутри транзакции все запросы выполняются последовательно)

try {
  // только если запросы между собой независимы, что бывает далеко не всегда.
  const result = await Promise.all(arrayWithDBQueriesPromises); 
  await transaction.commit();
} catch() {
  await transaction.rollback();
}

в сетевых запросах, в чтении файлов и множестве других сценариев, Promise.all вообще не мешает, а только помогает.

Используем async/await в nodejs уже сегодня

1. async-await в NodeJS завезли уже достаточно давно, раньше, чем 8 версия.
Если не ошибаюсь — еще с 6.* с --harmony было.

2. Для оборачивания callback кода есть util.promisify

3. Возвращать объект с ошибкой и полезными данными — ИМХО очень плохо. async-await позволяет обрабатывать ошибки в асинхронных функциях в try-catch

4. А вот это вообще ни в какие ворота

var files = ['1.csv', '2.csv', '3.csv'];
var results = [];
// всех вызываем
for(let i = 0;i<files.length;i++){
  results.push( promise(fs, fs.readFile, files[i]) );
}
// а потом дожидаемся всех (при это все 3 могут придти одновременно, тоесть не нужно ждать каждый отдельно. Если третий прочитается быстрее чем первый, он уже будет готов )
for(let i = 0;i<files.length;i++){
  results[i] = await results[i];
}

используйте developer.mozilla.org/ru/docs/Web/JavaScript/Reference/Global_Objects/Promise/all

FYI пакеты, которые предоставляют promise-api:
www.npmjs.com/package/mysql2
www.npmjs.com/package/request-promise-native
www.npmjs.com/package/fs-extra

Десять вопросов о Node.js, на которые вы не сможете ответить

nodejs.org/api/fs.html

In busy processes, the programmer is strongly encouraged to use the asynchronous versions of these calls. The synchronous versions will block the entire process until they complete--halting all connections.

Десять вопросов о Node.js, на которые вы не сможете ответить

нельзя передать callback в readFileSync

Среда выполнения — однопоточная (на самом деле нет, но программисту доступен только 1 поток). Если внутри callback асинхронной функции выполнить длительное синхронное действие (а чтение файла именно таким и может быть), то это заблокирует обработку всех остальных функций и они будут ждать своей очереди.

попробуйте выполнить что-то вроде

  setTimeout(() => {while (true) {}}, 0)

это приведет к тому, что функция-callback, которая передана в setTimeout, когда до нее дойдет очередь, заблокирует основной поток навсегда (ну, до принудительного прерывания).

Десять вопросов о Node.js, на которые вы не сможете ответить

Чтение файла происходит в отдельном потоке, который вызывает callback после завершения операции.

Видимо есть недоразумение.
Есть, например, функция fs.readFile и fs.readFileSync.
Вторая работает без callback и возвращает результат операции.
Именно вторая и блокирует основной поток выполнения.

Так же есть другие fs.*Sync функции

Что общего у разработки программного обеспечения с разработкой настольных игр?

Как мне кажеться, «бумажные» настольные игры это, не в последнюю очередь, об общении. Игра на устройстве убивает это преимущество.

Объясняем современный JavaScript динозавру

Видимо речь идет о том, что для обновления библиотеки (по какой бы причине такая необходиомость не возникла) не нужно искать сайт библиотеки / репозиторий, а достаточно сделать, например,
npm up lib@42

JavaScript ES8 и переход на async / await

согласен, но это не то, что я хотел показать.
В этом примере вообще я не вижу смысла делать 2 промиса последовательно, а если `r1` нужен для `action2()` то его надо туда явно передать.

JavaScript ES8 и переход на async / await

так получиться Promise-hell
ИМХО так лучше.

function withPromises() {
  return action1()
  .then(r1 => action2())
  .then(r2 => r1 + r2);
}

Понятно, что если на каждом этапе надо делать больше, чем просто вызвать следующую функцию или сложить 2 значения, то надо будет разворачивать стрелочные функции в нормальные или выносить этот функционал в отдельные именованные функции.

Все тайное становится явным. Беспилотные авто Google используют технологии Intel

Срочная новость. Беспилотные автомобили Google используют колеса!

«Паттерны» функционального программирования

Разве чистые функции — это единственная концепция ФП?

Что за черт, Javascript

С какой целью пустая строка приводится к 0, а не к NaN?

Так прописано в стандарте. А вот почему так в стандарте прописано мне неизвестно :-)

Что за черт, Javascript

потому что [].toString() === ""
developer.mozilla.org/en-US/docs/Web/JavaScript/Equality_comparisons_and_sameness

Что за черт, Javascript

php — repl.it/LGBB
java — repl.it/LGBf