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

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

Думаю, я знаю почему: это потому, что философия небольших модулей благоприятствует авторам библиотек (например, Синдре) за счет конечных расходов пользователей библиотеки. Поскольку у авторов библиотек обычно больше мегафонов (больше подписчиков в Твиттере, больше доверия на GitHub, Hacker News и т. Д.), Их голоса слышны чаще.

Но пользователей библиотеки больше, и поэтому их потребности более важны.

Прежде чем я начну

Я тот, кто извлек большую пользу из npm и изобилия кода, доступного в нем. В частности, я частый пользователь некоторых модулей Синдре. Благодаря ему Интернет стал лучше, и - хотя модули узлов имеют определенные недостатки дизайна с точки зрения клиента, - node и npm сделали больше для представления концепции модульности разработчикам JavaScript, чем тысячи сообщений в блогах. Спасибо, Синдре, и спасибо всем, кто участвовал в создании node и npm.

Далее следует не абсолютистское утверждение, что маленькие модули `` плохие '' или что мы должны явно стремиться создавать `` большие модули '', а скорее попытка выявить некоторые нюансы, которые часто замалчиваются сторонниками малых модулей. философия.

Почему npm - самый популярный менеджер пакетов

Вы часто будете видеть презентации, показывающие, что npm имеет больше модулей, чем любой другой менеджер пакетов, и переживает более быстрый рост. Естественно предположить, что это потому, что а) это лучший менеджер пакетов и б) сообщество JavaScript является наиболее энергичным и продуктивным.

Я предлагаю дополнительное объяснение: мы в мире JavaScript более терпимы к чепухе и вздору. Пожалуй, мой любимый пакет npm - peter, который при необходимости выводит на консоль следующее:

Жил-был человек по имени Питер ДеМартини
Он классный…
Хорошего дня…

Это крайний случай, но npm изобилует пакетами схожей ценности - пакетами без документации или README, которые никогда не выходили за рамки версии 0.0.1 и которые имеют около дюжины загрузчиков в месяц, большинство из которых, скорее всего, являются ботами. Я должен знать, я написал несколько.

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

Возникающая проблема обнаруживаемости

Обнаруживаемость часто называют самым большим недостатком npm. Многие сообщения в блогах - ну и целые веб-сайты - были созданы, чтобы попытаться уменьшить сложность поиска того, что вам нужно, на npm. У всех есть идея, как упростить поиск иголок в стоге сена, но никто не удосуживается спросить, что вообще здесь делает все это сено.

В конце концов, вы найдете пакет, который более или менее соответствует вашим потребностям. Но ваши проблемы только начались. Вы должны оценить библиотеку: есть ли в ней тесты? Вы понимаете исходный код? Это активно поддерживается? Легко ли найти документацию и проконсультироваться?

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

Ностальгия

Раньше, когда разработка JavaScript была почти синонимом разработки jQuery, наша работа была намного проще. В jQuery есть сотни функций, но, изучив несколько, можно с высокой степенью точности предсказать, как будут работать большинство остальных: библиотеку можно изучить. Если вы все же застряли, перейдите на api.jquery.com и за несколько секунд найдете нужные ответы. Хипстерские лидеры тысячелетия (в том числе и ваш покорный слуга) в наши дни могут предпочесть другие инструменты, но jQuery действительно является шедевром дизайна.

Он также достаточно велик, чтобы вокруг него существовало сообщество - сообщество, которое поддерживает его в актуальном состоянии, пишет учебные пособия и сообщения в блогах, организует встречи и конференции и отвечает на ваши вопросы о Stack Overflow. Вы можете пройти долгий путь в качестве разработчика, имея в кармане швейцарский армейский нож jQuery.

Приверженец «малых модулей», напротив, может использовать лучшие в своем классе инструменты для удовлетворения своих нишевых требований. Но она должна узнать, где они могут быть найдены, и развить энциклопедические знания о них, и если она застрянет, скорее всего, она останется одна.

Но что насчет…?

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

Этот шаблон проявляется в другой форме: небольшие модули позволяют авторам библиотек лениться. Зачем включать эту шестистрочную вспомогательную функцию, если можно выполнить однострочное `require`? Неважно, что требуемый модуль имеет свои собственные зависимости со своими собственными зависимостями, пока ваши пользователи внезапно не обнаружат, что `npm install` включает в себя загрузку 70 МБ куббинов, разделенных на 15000 файлов. Я преувеличиваю, но едва ли.

Назад в будущее

Недавно мне было интересно, что потребуется, чтобы маятник качнулся в другую сторону, чтобы мы снова могли использовать библиотеки, такие как jQuery (широкие, обучаемые, проверенные в боях, хорошо документированные, активно разрабатываемые), не подвергаясь посрамлению модульности.

Я считаю, что ответ кроется в модулях ES6. Я работал над инструментом под названием Rollup, который представляет собой один из возможных способов использования преимуществ большой служебной библиотеки, такой как jQuery (или D3, или Underscore / Lodash, или даже Three.js), без добавления ненужного объема в наши проекты, включая только тот код, который вы действительно используете. (Он делает это путем статического анализа вашего кода и его зависимостей - конфигурация не требуется, и это очень быстро. Эффект резкий.)

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