Очередная node.js-библиотека…

Все правильно.
Это подход, реализующий здравый смысл и лучшие практики работы с node.js, оформленный в небольшую библиотеку.

Очередная node.js-библиотека…

Если сравнивать с  koa, то все верно.
Но идея была все таки взглянуть по новому на архитектуру с учетом всех новых возможностей node.js.
Здесь ближе подход Promise based.
Пример с промежуточным ПО (middleware) я привел для сравнения с express / koa. Но это не сама суть идеи.
Чтобы объяснить что-то новое, легче взять что-то старое и показать отличие.

И я представил, как должен выглядеть действительно «фреймворк нового поколения»:

const server = http.createServer( (req, res) => {
    Promise.resolve({ req, res }).then(ctx => {

        ctx.res.writeHead(200, {'Content-Type': 'text/plain'});
        ctx.res.end('OK');

        return ctx;
    });
});

Очередная node.js-библиотека…

Это не избавляет вас от необходимости обрабатывать ошибки асинхронных функций. Напишите trow Error в таймауте и Promise.all его не в поймает.

Я старался как раз и избавиться от callback, заменив их на Promise / aasync / await. Ошибки в такой реализации не теряются. А заменить setTimeout можно Promise обберткой, например promise-pause-timeout.

Фишку с непоследовательным выполнением миддлеваре вообще не понял, в этом как раз и профит что запрос обрабатывается последовательно всеми миддлварями и это последовательность никак не мешает асинхронности.

И да и нет. Если промежуточное ПО является, например, static server, здесь результат параллельной работы очевиден (обращение к файловой системе). Если нам нужно создать клиенты, например к  mysql / redis, и дождаться их соединения — тоже (сетевые запросы). Но если нам нужно обработать например request (body-parser), здесь особо выигрыша не будет, но мы можем этим пожертвовать ради единой архитектуры и выигрыша от предыдущих примеров. В итоге суть подхода делать неблокирующие операции везде — один из важнейших паттернов асинхронной работы node.js.

Очередная node.js-библиотека…

Спасибо за комментарий. Как по мне он самый интересный и показывает несовершенство yesp документации.

По первому вопросу — как раз я и учел особенности node.js.
Node.js не однопоточная, она работает в одном процессе (если не учитывать кластеризацию и child_process). Многопоточность и обеспечивает libuv.

Библиотека yesp позволяет контролировать последовательность или параллельность выполнения кода.

app.then();
app.all();
app.all();
app.then();
app.catch()

фактически даст нам

Promise.resolve()
.then()
.then(() => Promise.all())
.then(() => Promise.all())
.then()
.catch();

Поэтому можно группировать промежуточное ПО по смыслу и сделать их работу параллельной (например сервер статики и favicon запустить параллельно, если они смотрят в разные папки, затем параллельно запустить создание logger, error handler, redis client, mysql client...). Пример можно посмотреть в yeps-boilerplate.

UX-дизайн: флажки и переключатели в формах

Хочу немного дополнить.

Стараюсь использовать минимализм в дизайне — не позволять пользователю сделать действие, которое нужно проверять на сервере, например валидация данных.

Сохранение возможно только при наличии заполненных полей, при этом заполненных правильно.
Только после этого показываю кнопку «Сохранить» (не забываю о сообщениях об ошибке).

В момент сохранения показываю индикатор загрузки (spinner), при этом отключаю (disable) все элементы на форме.
Таким образом пользователь видит, что процесс идет, что нужно подождать.

Очень помогает material дизайн от Google.
Любые действия, такие как нажатие кнопки, включение или выключение переключателя, имеют свой визуальный эффект.
И вместе с отключением элементов формы, индикацией загрузки делают действительно интерфейс отзывчивым.

UX-дизайн: флажки и переключатели в формах

Использовал react и material-UI.
Сделал форму с переключателями и кнопкой «Сохранить».

Если элементы формы соответствуют сохраненному на сервере состоянию — я прячу кнопку.
И наоборот, если одно из полей имеет состояние отличное от сохраненного — я показываю кнопку.

Таким образом отлично видно, включены или нет переключатели и сохранено ли это состояние на сервере.

Анонсирован Cubieboard 5/Cubietruck Plus и HDD-RAID Shield

Похожая история. Много работаю с php и composer. То для сборки проекта с symfony нужно минимум 1gb памяти, минимум, и это без учета ОС, субд, redis… Для сервера 2 gb довольно мало. Хотя на nodejs проекты отлично себя чувствуют.

Создание блога на Symfony 2.8 lts [ Часть 2 ]

И на них можно вешать события, например, для для изменения данных перед обработкой или удаления лишних полей. symfony.com/doc/current/components/form/form_events.html