Год npm в цифрах: 2014

http://blog.npmjs.org/post/106746762635/npms-year-in-numbers-2014
  • Перевод
npm — это пакетный менеджер Node.js. С его помощью можно управлять модулями и зависимостями.

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

Ниже представлен набор показателей. Некоторые из них я отслеживаю, а некоторые просто решил посмотреть. Еще указано то, насколько они изменились с 1 января по 31 декабря 2014 года.

Количество пакетов в реестре:


1 января: 53 459
31 декабря: 115 194
Темпы роста: 2.1x.

Скачиваний за предыдущие 30 дней:


1 января: 149 822 000 (примерно)
31 декабря: 648 620 794
Темпы роста: 4.3x (рост на самом деле немного больше, это связано с тем, что недавно проходили новогодние праздники)

Количество талисманов:


1 января: 0
31 декабря: 1

Это долгая история, но у нас теперь есть вомбат и мы его любим. Спасибо, Джон!

Количество загрузок в будние дни (примерно):


1 января: 6 024 000
31 декабря: 25 000 000

Количество загрузок в выходные дни (примерно):


1 января: 3 000 000
31 декабря: 12 000 000

Мы перечислили их отдельно, потому что многих людей до сих пор удивляет то, что Node.js больше популярен в будние дни, чем на выходных. Люди используют npm чтобы делать по-настоящему серьезные вещи!

Почему число скачиваний растет в два раза быстрее, чем число пакетов? Потому что людей, просто использующих пакеты, больше, чем людей, участвующих в их разработке. Насколько точно — сказать довольно сложно. Вот некоторые показатели, которые мы попытались измерить:

Зарегистрированные разработчики:


1 января: 21 000 (очень грубая оценка)
31 декабря: 83 317
Темпы роста: 4x. На текущий момент регистрируются только те, кто собирается публиковать пакеты.

Еженедельные число уникальных посетителей сайта npm:


18 января (первый день, за который мы имеем данные): 113 000
20 декабря (последняя неделя перед праздниками): 264 000
Темпы роста: 2.3x

Всего уникальных пользователей на сайте npm в 2014 году:


5 444 000

Всего просмотров страниц в 2014 году:


35 000 000

Топ-10 стран, использующих npm:


1. США
2. Великобритания
3. Индия
4. Германия
5. Франция
6. Канада
7. Китай *
8. Россия
9. Япония
10. Бразилия

(* Китайские пользователи npm запускают множество зеркал, поэтому фактическое использование npm в Китае, вероятно, выше)

Как насчет программного обеспечения самого npm?

Общее количество коммитов во все репозитории npm:


2013: 919
2014: 3 360
Темпы роста: 3.6x

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

Уникальные IP-адреса, обращающиеся к реестру, за последние 7 дней:


1 402 000 (примерно)

Уникальные посетители сайта за последние 90 дней:


2 100 000

Всего репозиториев:


154

Открытых вопросов:


1173

Закрытых вопросов:


6889

Количество штатных сотрудников:


1 января: 0
31 декабря: 11

Остается только добавить: это был очень хороший год, и все это благодаря прекрасным пользователям, таким как вы, которые каждый день появлялись и пользовались нашими программами и сервисами! Мы очень счастливы, что вы это делали. С Новым 2015 Годом!
Поделиться публикацией

Комментарии 33

    +2
    А хороших пакетов всего десятки…
      +1
      Это всё Mortal Wombat…
        +9
        Зря минусуете. Человек правду говорит.

        Больше половины пакетов имеют примерно ~3 скачивания в месяц, т.к являются откровенно мусором. www.npmjs.com/search?q=hello+world <= 7к пакетов хелло ворлд. www.npmjs.com/search?q=just+test 37k пакетов просто мусора. ТРИДЦАТЬ СЕМЬ ТЫСЯЧ. Это порядка 30% от всех опубликованных пакетов.

        На главной странице в блоке промоута 15 пакетов, которые безусловно являются тузами в этой колоде. Всем им больше года и даже 2х. По субъективным ощущениям в NPM порядка 14к пакетов, которые несут хоть какую-то смысловую нагрузку. Это легко посчитать через список most depended-upon packages, где перечислены порядка 14к пакетов с зависимостями > 0.
          +2
          Да, реально проблема.
          Особенно при выборе нового пакета. К примеру, is object. Что взять: underscore/lodash, jquery, amp, is-object/isobject, mutype, ...? Миллионы их. И так по каждой мини-задаче. Есть некоторые штуки, упрощающие поиск нужного пакета или показывающие best practice, типа sister для эмиттеров, но это исключения.

          В итоге при сборке разные модули используют свои is-object, бандл получается раздутый.

          Начал собирать информацию на тему попыток как-то обуздать энтропию npm. Пока что пришел к списку аналогичных пакетов package-analogs, подбираемых вручную. Автоматизировать оценку схожести пакетов можно, по-видимому, каким-нибудь кросс-тестингом и системой поиска функциональных клонов.

          Есть еще западные проекты на эту тему, по мотивам Армстронга: cafe-js, но это уж совсем футуризм.
            +1
            Это вообще глобальная проблема, во всех децентрализованных системах, где нет единого органа планирования и управления разработкой. Я называю эффект появления похожих альтернативных решений, не основанных на специфике, на существенных отличиях или конструктивных особенностях — неспецифической конкуренцией. Она сейчас везде, это зараза.
              0
              В теории, если бы в closurecompiler-подобный минификатор был встроен не только детектор мертвого кода, но и детектор функциональных клонов (что весьма несложно ему со своей системой нормализации кода), то решить проблему наличия [неспецифично-]конкурентных модулей в сборках можно было бы достаточно эффективно.
                +1
                К сожалению, для императивного программирования и, главное — для декларации структур данных, аналогичного решения нельзя реализовать в принципе. Один объект предметной области любые два человека опишут и смоделируют в структурах данных совершенно по-разному, а на основе структур данных появляются и разные алгоритмы их обработки, это даже на ФП существенно влияет. Только введение стандартов тут поможет, например, помните что было с зарядными устройствами, пока не ввели обязательный usb? С другой стороны стандарты замедляют развитие. Но я бы согласился на замедление, очень уж велик поток дерьма.
              +1
              Для такого рода вещей обычно рано или поздно появляются сервисы, которые фильтруют откровенный мусор и делают рейтинги. Для того же руби первая остановка для любого программиста www.ruby-toolbox.com который тоже показывает все эти залежи говн, но дают возможность ориентироваться в них.

              Для npm есть github.com/sindresorhus/awesome-nodejs где перечислено 305 отборных пакета. 81 человек смогли найти в 115 194 пакетах, ТРИСТА ПЯТЬ стоящих. ~0.3% от всего что есть.
              +1
              «Just test» находит много нормальных пакетов: test-agent, lab, chai, даже grunt.
                0
                Согласен, в выдачу попадают и хорошие пакеты. Все равно на пересечении результатов по словам «example», «just test», «don't use», «warning» всплывает под 60к мусорных пакетов. Я боюсь что если серьезно проанализировать npm то будет картинка будет еще хуже.
            • НЛО прилетело и опубликовало эту надпись здесь
              0
              Кто пишет на Node — поделитесь, пожалуйста, примерным числом строк в ваших проектах. Интересует, главным образом, пишется ли что-то на нем крупное, или же это все в основном небольшое нишевые сервисы и подсистемы.
                +5
                Использую 2 года как основной инструмент. Прямо сейчас в разработке проекты на 3100, 6500, 17200 строк. Но это же не показатель их масштаба, для меня лично серьезность ноды подтвердилась, когда я запустил нагрузочный тест одного приложения на 3 серверах, и получил производительность (rps, кол-во соединений, latency, отзывчивость), для которой мне бы понадобилось на старых моих инструментах, страшно сказать — от 100 до 250 серверов той же мощности. Это по опыту масштабирования прикидываю, грубо деля суммарную нагрузку на суммарную нагрузку серверов приложений, с которыми имел дело и/или разрабатывал. На такие масштабы я даже не покушался. Но программировать на ноде сложно, не верьте кто говорит, что там быстрый старт и все как по маслу, говнокодить очень просто, а написать что-то существенное на JS гораздо сложнее, чем на других языках (сознательно не называю, чтобы холевар не затеять).
                  0
                  Интересно что за инструменты были раньше… Да и в целом задачу интересно узнать.
                    0
                    Задач много: приложения баз данных, автоматизация производства, сетевая безопасность, медицина, телевидение, образование. В понедельник утром с меня статья про новый инструментарий, а про внедрения чуть позже )
                      0
                      Обещанная статья, даже раньше, habrahabr.ru/post/247543/
                    0
                    Есть множество крупных проектов, которые используют в той или иной мере Node.js
                    Одним из примеров может служить PayPal
                      0
                      Несомненно. Но это не отменяет вопрос. Paypal же не весь на ноде написан (или весь?).
                      0
                      Около 20к строк. Это крупное?
                        0
                        Если это — число строк именно на JS, то в моем понимании — достаточно крупное, чтобы попросить вас дать независимый комментарий (с точки зрения практического опыта сугубо) на замечание комментатора MarcusAurelius выше, вот на это: «Но программировать на ноде сложно, не верьте кто говорит, что там быстрый старт и все как по маслу, говнокодить очень просто, а написать что-то существенное на JS гораздо сложнее, чем на других языках (сознательно не называю, чтобы холевар не затеять)». Хочется вообще привнести в вопрос побольше практического опыта, очень интересна эта тема.
                          0
                          Если хотите побольше опыта, то тут это будет немного оффтопиком, а я готовлю подробнейшую статью, про свой проект в открытом коде, который уже 2 года пилю вместе с командой. Дело в том, что если на ноде прототипировать или делать пилоты, использовать для сборки клиентской (браузерной) части или для скриптования и автоматизации задач, закрывать узкие места в других технологиях, например, делать чаты или уведомления через вебсокеты, то нодой вполне можно пользоваться в том виде, в котором она есть. А вот если нужно делать прикладное приложение, с богатой серверной логикой, имеющей много слоев абстракции и собирать десятки машин в кластер, обеспечивать их согласованную работу как одного целого приложения, иметь серверное API из тысяч методов или объединить в проекте много разных протоколов, хостов, портов, обслуживание многих доменных имен и т.д., то оказывается, что нода очень низкоуровневая штука, и вдруг вы понимаете, что у вас в одном файле идет формирование http заголовков, объявлен класс пациент, происходит валидация формы, прописан роутинг урлов да еще и веб-сокеты тут же. То есть, произошло смешивание прикладного и системного кода, потому, что фреймворки не скрыли от прикладного приложения весь системный слой, они слишком низкоуровневые. Часто, разные npm модули, подключенные к проекту имеют разный уровень абстракции кода, один более высокоуровневый, другой более системный, все выравнивание лежит на плечах приложения, отсюда опять усиление этого же чудовищного смешения слоев абстракции. Ну и, окончательно возвращаясь к топику про npm, из-за того, что в JS слишком незащищенный код, т.е. имея ссылку на тот же res, кто-то может сделать к нему примесь или перекрыть оригинальную функцию своей и даже самые лучшие пакеты, если их использовать в одном проекте, часто конфликтуют и ведут себя менее предсказуемо, чем хотелось бы. Вот поэтому, перед тем, как делать крупные приложения, я был вынужден сначала сделать свой сервер приложений Impress, закрывающий большинство этих проблем. Обещанная статья про него будет тут в течении 10 дней.
                            +1
                            Хоть это и оффтоп, но Вы так любите в каждом посте упоминать это изделие (impress), активно использующее глобальные переменные, что мне стало интересно: кто-то использует его в реальных живых проектах?
                              0
                              Ну скачиваний много )
                                0
                                Скачивания ни о чем не говорят, я не знаю чего их так много, у многих проектов их значительно больше, чем вообще возможно, я прикидывал по новым проектам и по самым разным, в любым случае, ни какие здравые расчеты и прикидки не могут объяснить такого кол-ва скачиваний в npm, то ли он глючит и где-то дублируется статистика, то ли кто-то массово использует continuous integration и это все тесты накручивают, но я себе не представляю тесты в таких гиганских масштабах.
                                  0
                                  Не могу ничего сказать насчет фейковых скачиваний, но это пока что только догадки.
                                  Но насчет настоящих — к примеру, есть твит-бот npm_tweets, который постит твиты с последними обновленными пакетами в npm. На него подписано определенное число людей (немного). Так что каждый ваш npm publish репостится им в твиттер, что обеспечивает некоторый пиар.
                                  Уверен, есть еще подобные штуки.

                                  Как показывает мой опыт, любой мало-мальски полезный package набирает определенное изначальное число скачиваний, и как правило, это каким-то образом пропорционально «серьезности» или «полезности» пакета. Я сомневаюсь, что это делается автоматически или по ошибке. Скорее похоже на обычный трафик.
                                0
                                Кроме двух десятков текущих проектов моей команды есть постоянные пользователи, они беспорядочно пишут в почту, скайп, вк, фб, ни как не могу заставить писать в гитхаб вопросы и запросы на доработку. Самая большая проблема сейчас в том, что нет документации, она только готовится, проект так быстро изменялся, особенно за последние 6-8 месяцев, что документация устаревала бы каждую неделю. Но вот сейчас я уже чувствую, что архитектуру приложений можно зафиксировать и переходить на оптимизацию и продвижение.
                                  0
                                  Клиенту как правило всеравно, есть там глобальные переменные или нет. Проблемы начинаются, когда начинается поддержка не авторами данного изделия.
                                  Вся суть таких вот стеков/серверов приложений, как хотите называйте — это подсадить на «иглу» (это очень распространено в JEE) поддержки.
                                0
                                Если говорить откровенно, то переход поначалу немного сложноват. Но со временем как-то привыкаешь и все кажется естественным. Это, скорее субъективное мнение, но мне удобнее сейчас писать на node.js, чем, на том же php. Хотя приходится паралельно и на том и на том писать. Другими словами, если появилось желание, то однозначно стоит попробовать.
                              +1
                              Уже давно использую ноду и npm для деплоя фронт-енда, лучше npm, grunt/gulp для этого ничего не нашёл, тем более такого удобного и универсального, большая база модулей на все случаи жизни, один раз только что-то писал специфичное для grunt, свой плагин. В конечном итоге начали повторяться какие-то шаблонные вещи, тогда сделал отдельный npm-пакет как обёртку над gulp, которая настраивается с минимальным порогом вхождения через package.json в локальном проекте, научить нюфагов делать `npm install` и `gulp`/`gulp --production`/`gulp watch` гораздо проще, чем проделывать дополнительные манипуляции, свойственные некоторым другим яп и их дефолтным менеджерам пакетов.
                                0
                                Используем npm + browserify для сборки фронтенда. Идет как по маслу, лучше и не представить.
                                Не очень ясно про число строк — если используются внешние компоненты или модули — смысл их считать? Сборка может получиться толстая, но управляющего кода весьма немного — ~1k строк на весь сайт.
                                • НЛО прилетело и опубликовало эту надпись здесь
                                    0
                                    Писали на node.js платёжную систему, строки не считал, но проект достаточно крупный. Есть хорошие решение уже сейчас, но для некоторых вещей приходится придумывать велосипеды.
                                    +1
                                    Это всё хорошо, но никогда не вспоминают, что сервис может перестать работать, и для поддержки запуска одной командой нужно зеркало или сборник пакетов для определённого проекта.
                                    npm config set registry http://registry.npmjs.org/
                                    
                                    , где в указанном УРЛ будет сервис реестра и все пакеты.

                                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                    Самое читаемое