Синдре Сорхус — автор более, чем 600 модулей npm (666, Карл!). В недавнем AMA (кто не знает, это такой формат, когда кто-либо известный/интересный предлагает позадавать ему вопросы, например, в виде тикетов к гит-репозиторию, хотя, конечно, известнее /r/AMA и фуршет у Лебедева) он пояснил свою позицию по поводу модулей-однострочников, которые зачастую вызывают критику в адрес node.

Я собирался написать пост в блоге на эту тему, но, к сожалению, в этом я не так продуктивен, как в написании кода.

tl;dr Небольшие специализированные модули нужны для повторного использования и для того, чтобы делать большие и сложные штуки, которые легко понять.

Люди слишком озабочены количеством строк кода. LOC вообще не имеет никакого значения. Не важно, состоит модуль из одной строчки, или из сотен. Все дело в сокрытии сложности. Думайте о модулях node как о кубиках лего. Вас не интересует, из чего и как они сделаны. Все, что вам требуется знать — как использовать эти кубики для постройки своего лего-замка. Делая маленькие и специализированные модули, вы можете легко строить большие и комплексные системы без контроля за тем, как каждая отдельная деталь работает. Наша кратковременная память конечна. Эти модули могут повторно использовать другие люди и каждое улучшение и исправленный баг получат все из них.

Представьте себе, если бы производители ПК производили процессоры сами. Большинство делали бы это плохо. Компьютеры были бы дороже, а инновации происходили бы медленнее. Вместо этого большинство использует Intel, ARM и прочие.

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

Несколько лет назад, до Node.js и npm у меня была большая база сниппетов, которые я копипастил в проекты, когда в этом была нужда. Это были небольшие полезности, которые иногда пригождались. Теперь npm — моя база сниппетов. Зачем копипастить, если можно зареквайрить модуль и получить именно то, что нужно. Исправление бага в «сниппете» — всего лишь обновление одного модуля, а не исправление «руками» всех мест, где сниппет вставлялся бы.

К примеру, у меня есть модуль negative-zero. Его работа — сказать мне, что число равно -0. Обычно это не требуется, но случается. И как нам определить, что число — -0. Вполне легко, x === 0 && 1 / x === -Infinity. Так? Вам действительно надо знать, как и почему это работает так? Я бы предпочел подключить negative-zero и сконгцентрироваться на других вещах.

Другой пример. Один из самых популярных модулей на npm — Chalk. Возможно, вы не знаете этого, но, на самом деле, это набор модулей. Он использует модули для определения поддержки цветов в терминале, для получения ansi-кодов и т.д. Все это можно было бы включить в основной модуль, и так и есть, скорее всего, в большинстве случаев. Но это означало бы, что кто-то создаст еще один модуль для работы со строками в терминале и переизобретет колесо. С этим же набором модулей, люди легко получают выгоду от использования в своих проектах Chalk'а и, может быть, даже помогают косвенно улучшить сам Chalk, улучшая одну из его зависимостей.

И еще пример. Мой модуль user-home нужен только для того, чтобы получить домашнюю директорию пользователя. Вы можете подумать, что может быть проще, чем написать process.platform === 'win32' ? process.env.USERPROFILE : process.env.HOME. И большинство так и сделает. Но, правда, зачем каждому из нас знать, как получить домашнюю директорию? Почему бы не использовать готовый «кубик лего»? Ну и, конечно же, вы можете и не знать, что эта проверка — неполная. В Windows вам надо также посмотреть process.env.HOMEDRIVE + process.env.HOMEPATH, а еще вы могли бы также захотеть сделать дополнительные проверки. Лего.

Вы же не шьете себе собственные ботинки? Нет, вы покупаете их в магазине. Большинство не заботит, как изготавливаются их ботинки. Только то, как они хорошо сидят на ноге.

Я хочу, чтобы программировать было проще. Делать программирование более простым — это строить надежные системы. И практический путь в моем видении — это перестать переизобретать все подряд и делать одни и те же глупые ошибки снова и снова.