Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 33
А хороших пакетов всего десятки…
Это всё Mortal Wombat…
Зря минусуете. Человек правду говорит.
Больше половины пакетов имеют примерно ~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.
Больше половины пакетов имеют примерно ~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.
Да, реально проблема.
Особенно при выборе нового пакета. К примеру, is object. Что взять: underscore/lodash, jquery, amp, is-object/isobject, mutype, ...? Миллионы их. И так по каждой мини-задаче. Есть некоторые штуки, упрощающие поиск нужного пакета или показывающие best practice, типа sister для эмиттеров, но это исключения.
В итоге при сборке разные модули используют свои is-object, бандл получается раздутый.
Начал собирать информацию на тему попыток как-то обуздать энтропию npm. Пока что пришел к списку аналогичных пакетов package-analogs, подбираемых вручную. Автоматизировать оценку схожести пакетов можно, по-видимому, каким-нибудь кросс-тестингом и системой поиска функциональных клонов.
Есть еще западные проекты на эту тему, по мотивам Армстронга: cafe-js, но это уж совсем футуризм.
Особенно при выборе нового пакета. К примеру, is object. Что взять: underscore/lodash, jquery, amp, is-object/isobject, mutype, ...? Миллионы их. И так по каждой мини-задаче. Есть некоторые штуки, упрощающие поиск нужного пакета или показывающие best practice, типа sister для эмиттеров, но это исключения.
В итоге при сборке разные модули используют свои is-object, бандл получается раздутый.
Начал собирать информацию на тему попыток как-то обуздать энтропию npm. Пока что пришел к списку аналогичных пакетов package-analogs, подбираемых вручную. Автоматизировать оценку схожести пакетов можно, по-видимому, каким-нибудь кросс-тестингом и системой поиска функциональных клонов.
Есть еще западные проекты на эту тему, по мотивам Армстронга: cafe-js, но это уж совсем футуризм.
Это вообще глобальная проблема, во всех децентрализованных системах, где нет единого органа планирования и управления разработкой. Я называю эффект появления похожих альтернативных решений, не основанных на специфике, на существенных отличиях или конструктивных особенностях — неспецифической конкуренцией. Она сейчас везде, это зараза.
В теории, если бы в closurecompiler-подобный минификатор был встроен не только детектор мертвого кода, но и детектор функциональных клонов (что весьма несложно ему со своей системой нормализации кода), то решить проблему наличия [неспецифично-]конкурентных модулей в сборках можно было бы достаточно эффективно.
К сожалению, для императивного программирования и, главное — для декларации структур данных, аналогичного решения нельзя реализовать в принципе. Один объект предметной области любые два человека опишут и смоделируют в структурах данных совершенно по-разному, а на основе структур данных появляются и разные алгоритмы их обработки, это даже на ФП существенно влияет. Только введение стандартов тут поможет, например, помните что было с зарядными устройствами, пока не ввели обязательный usb? С другой стороны стандарты замедляют развитие. Но я бы согласился на замедление, очень уж велик поток дерьма.
Для такого рода вещей обычно рано или поздно появляются сервисы, которые фильтруют откровенный мусор и делают рейтинги. Для того же руби первая остановка для любого программиста www.ruby-toolbox.com который тоже показывает все эти залежи говн, но дают возможность ориентироваться в них.
Для npm есть github.com/sindresorhus/awesome-nodejs где перечислено 305 отборных пакета. 81 человек смогли найти в 115 194 пакетах, ТРИСТА ПЯТЬ стоящих. ~0.3% от всего что есть.
Для npm есть github.com/sindresorhus/awesome-nodejs где перечислено 305 отборных пакета. 81 человек смогли найти в 115 194 пакетах, ТРИСТА ПЯТЬ стоящих. ~0.3% от всего что есть.
«Just test» находит много нормальных пакетов: test-agent, lab, chai, даже grunt.
Кто пишет на Node — поделитесь, пожалуйста, примерным числом строк в ваших проектах. Интересует, главным образом, пишется ли что-то на нем крупное, или же это все в основном небольшое нишевые сервисы и подсистемы.
Использую 2 года как основной инструмент. Прямо сейчас в разработке проекты на 3100, 6500, 17200 строк. Но это же не показатель их масштаба, для меня лично серьезность ноды подтвердилась, когда я запустил нагрузочный тест одного приложения на 3 серверах, и получил производительность (rps, кол-во соединений, latency, отзывчивость), для которой мне бы понадобилось на старых моих инструментах, страшно сказать — от 100 до 250 серверов той же мощности. Это по опыту масштабирования прикидываю, грубо деля суммарную нагрузку на суммарную нагрузку серверов приложений, с которыми имел дело и/или разрабатывал. На такие масштабы я даже не покушался. Но программировать на ноде сложно, не верьте кто говорит, что там быстрый старт и все как по маслу, говнокодить очень просто, а написать что-то существенное на JS гораздо сложнее, чем на других языках (сознательно не называю, чтобы холевар не затеять).
Интересно что за инструменты были раньше… Да и в целом задачу интересно узнать.
Задач много: приложения баз данных, автоматизация производства, сетевая безопасность, медицина, телевидение, образование. В понедельник утром с меня статья про новый инструментарий, а про внедрения чуть позже )
Обещанная статья, даже раньше, habrahabr.ru/post/247543/
Есть множество крупных проектов, которые используют в той или иной мере Node.js
Одним из примеров может служить PayPal
Одним из примеров может служить PayPal
Около 20к строк. Это крупное?
Если это — число строк именно на JS, то в моем понимании — достаточно крупное, чтобы попросить вас дать независимый комментарий (с точки зрения практического опыта сугубо) на замечание комментатора MarcusAurelius выше, вот на это: «Но программировать на ноде сложно, не верьте кто говорит, что там быстрый старт и все как по маслу, говнокодить очень просто, а написать что-то существенное на JS гораздо сложнее, чем на других языках (сознательно не называю, чтобы холевар не затеять)». Хочется вообще привнести в вопрос побольше практического опыта, очень интересна эта тема.
Если хотите побольше опыта, то тут это будет немного оффтопиком, а я готовлю подробнейшую статью, про свой проект в открытом коде, который уже 2 года пилю вместе с командой. Дело в том, что если на ноде прототипировать или делать пилоты, использовать для сборки клиентской (браузерной) части или для скриптования и автоматизации задач, закрывать узкие места в других технологиях, например, делать чаты или уведомления через вебсокеты, то нодой вполне можно пользоваться в том виде, в котором она есть. А вот если нужно делать прикладное приложение, с богатой серверной логикой, имеющей много слоев абстракции и собирать десятки машин в кластер, обеспечивать их согласованную работу как одного целого приложения, иметь серверное API из тысяч методов или объединить в проекте много разных протоколов, хостов, портов, обслуживание многих доменных имен и т.д., то оказывается, что нода очень низкоуровневая штука, и вдруг вы понимаете, что у вас в одном файле идет формирование http заголовков, объявлен класс пациент, происходит валидация формы, прописан роутинг урлов да еще и веб-сокеты тут же. То есть, произошло смешивание прикладного и системного кода, потому, что фреймворки не скрыли от прикладного приложения весь системный слой, они слишком низкоуровневые. Часто, разные npm модули, подключенные к проекту имеют разный уровень абстракции кода, один более высокоуровневый, другой более системный, все выравнивание лежит на плечах приложения, отсюда опять усиление этого же чудовищного смешения слоев абстракции. Ну и, окончательно возвращаясь к топику про npm, из-за того, что в JS слишком незащищенный код, т.е. имея ссылку на тот же res, кто-то может сделать к нему примесь или перекрыть оригинальную функцию своей и даже самые лучшие пакеты, если их использовать в одном проекте, часто конфликтуют и ведут себя менее предсказуемо, чем хотелось бы. Вот поэтому, перед тем, как делать крупные приложения, я был вынужден сначала сделать свой сервер приложений Impress, закрывающий большинство этих проблем. Обещанная статья про него будет тут в течении 10 дней.
Хоть это и оффтоп, но Вы так любите в каждом посте упоминать это изделие (impress), активно использующее глобальные переменные, что мне стало интересно: кто-то использует его в реальных живых проектах?
Ну скачиваний много )
Скачивания ни о чем не говорят, я не знаю чего их так много, у многих проектов их значительно больше, чем вообще возможно, я прикидывал по новым проектам и по самым разным, в любым случае, ни какие здравые расчеты и прикидки не могут объяснить такого кол-ва скачиваний в npm, то ли он глючит и где-то дублируется статистика, то ли кто-то массово использует continuous integration и это все тесты накручивают, но я себе не представляю тесты в таких гиганских масштабах.
Не могу ничего сказать насчет фейковых скачиваний, но это пока что только догадки.
Но насчет настоящих — к примеру, есть твит-бот npm_tweets, который постит твиты с последними обновленными пакетами в npm. На него подписано определенное число людей (немного). Так что каждый ваш npm publish репостится им в твиттер, что обеспечивает некоторый пиар.
Уверен, есть еще подобные штуки.
Как показывает мой опыт, любой мало-мальски полезный package набирает определенное изначальное число скачиваний, и как правило, это каким-то образом пропорционально «серьезности» или «полезности» пакета. Я сомневаюсь, что это делается автоматически или по ошибке. Скорее похоже на обычный трафик.
Но насчет настоящих — к примеру, есть твит-бот npm_tweets, который постит твиты с последними обновленными пакетами в npm. На него подписано определенное число людей (немного). Так что каждый ваш npm publish репостится им в твиттер, что обеспечивает некоторый пиар.
Уверен, есть еще подобные штуки.
Как показывает мой опыт, любой мало-мальски полезный package набирает определенное изначальное число скачиваний, и как правило, это каким-то образом пропорционально «серьезности» или «полезности» пакета. Я сомневаюсь, что это делается автоматически или по ошибке. Скорее похоже на обычный трафик.
Кроме двух десятков текущих проектов моей команды есть постоянные пользователи, они беспорядочно пишут в почту, скайп, вк, фб, ни как не могу заставить писать в гитхаб вопросы и запросы на доработку. Самая большая проблема сейчас в том, что нет документации, она только готовится, проект так быстро изменялся, особенно за последние 6-8 месяцев, что документация устаревала бы каждую неделю. Но вот сейчас я уже чувствую, что архитектуру приложений можно зафиксировать и переходить на оптимизацию и продвижение.
Клиенту как правило всеравно, есть там глобальные переменные или нет. Проблемы начинаются, когда начинается поддержка не авторами данного изделия.
Вся суть таких вот стеков/серверов приложений, как хотите называйте — это подсадить на «иглу» (это очень распространено в JEE) поддержки.
Вся суть таких вот стеков/серверов приложений, как хотите называйте — это подсадить на «иглу» (это очень распространено в JEE) поддержки.
Если говорить откровенно, то переход поначалу немного сложноват. Но со временем как-то привыкаешь и все кажется естественным. Это, скорее субъективное мнение, но мне удобнее сейчас писать на node.js, чем, на том же php. Хотя приходится паралельно и на том и на том писать. Другими словами, если появилось желание, то однозначно стоит попробовать.
Уже давно использую ноду и npm для деплоя фронт-енда, лучше npm, grunt/gulp для этого ничего не нашёл, тем более такого удобного и универсального, большая база модулей на все случаи жизни, один раз только что-то писал специфичное для grunt, свой плагин. В конечном итоге начали повторяться какие-то шаблонные вещи, тогда сделал отдельный npm-пакет как обёртку над gulp, которая настраивается с минимальным порогом вхождения через package.json в локальном проекте, научить нюфагов делать `npm install` и `gulp`/`gulp --production`/`gulp watch` гораздо проще, чем проделывать дополнительные манипуляции, свойственные некоторым другим яп и их дефолтным менеджерам пакетов.
Используем npm + browserify для сборки фронтенда. Идет как по маслу, лучше и не представить.
Не очень ясно про число строк — если используются внешние компоненты или модули — смысл их считать? Сборка может получиться толстая, но управляющего кода весьма немного — ~1k строк на весь сайт.
Не очень ясно про число строк — если используются внешние компоненты или модули — смысл их считать? Сборка может получиться толстая, но управляющего кода весьма немного — ~1k строк на весь сайт.
Писали на node.js платёжную систему, строки не считал, но проект достаточно крупный. Есть хорошие решение уже сейчас, но для некоторых вещей приходится придумывать велосипеды.
Это всё хорошо, но никогда не вспоминают, что сервис может перестать работать, и для поддержки запуска одной командой нужно зеркало или сборник пакетов для определённого проекта.
npm config set registry http://registry.npmjs.org/
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Год npm в цифрах: 2014