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

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

Для такого рода вещей обычно рано или поздно появляются сервисы, которые фильтруют откровенный мусор и делают рейтинги. Для того же руби первая остановка для любого программиста www.ruby-toolbox.com который тоже показывает все эти залежи говн, но дают возможность ориентироваться в них.

Для npm есть github.com/sindresorhus/awesome-nodejs где перечислено 305 отборных пакета. 81 человек смогли найти в 115 194 пакетах, ТРИСТА ПЯТЬ стоящих. ~0.3% от всего что есть.

Согласен, в выдачу попадают и хорошие пакеты. Все равно на пересечении результатов по словам «example», «just test», «don't use», «warning» всплывает под 60к мусорных пакетов. Я боюсь что если серьезно проанализировать npm то будет картинка будет еще хуже.

Задач много: приложения баз данных, автоматизация производства, сетевая безопасность, медицина, телевидение, образование. В понедельник утром с меня статья про новый инструментарий, а про внедрения чуть позже )

Обещанная статья, даже раньше, habrahabr.ru/post/247543/

Если хотите побольше опыта, то тут это будет немного оффтопиком, а я готовлю подробнейшую статью, про свой проект в открытом коде, который уже 2 года пилю вместе с командой. Дело в том, что если на ноде прототипировать или делать пилоты, использовать для сборки клиентской (браузерной) части или для скриптования и автоматизации задач, закрывать узкие места в других технологиях, например, делать чаты или уведомления через вебсокеты, то нодой вполне можно пользоваться в том виде, в котором она есть. А вот если нужно делать прикладное приложение, с богатой серверной логикой, имеющей много слоев абстракции и собирать десятки машин в кластер, обеспечивать их согласованную работу как одного целого приложения, иметь серверное API из тысяч методов или объединить в проекте много разных протоколов, хостов, портов, обслуживание многих доменных имен и т.д., то оказывается, что нода очень низкоуровневая штука, и вдруг вы понимаете, что у вас в одном файле идет формирование http заголовков, объявлен класс пациент, происходит валидация формы, прописан роутинг урлов да еще и веб-сокеты тут же. То есть, произошло смешивание прикладного и системного кода, потому, что фреймворки не скрыли от прикладного приложения весь системный слой, они слишком низкоуровневые. Часто, разные npm модули, подключенные к проекту имеют разный уровень абстракции кода, один более высокоуровневый, другой более системный, все выравнивание лежит на плечах приложения, отсюда опять усиление этого же чудовищного смешения слоев абстракции. Ну и, окончательно возвращаясь к топику про npm, из-за того, что в JS слишком незащищенный код, т.е. имея ссылку на тот же res, кто-то может сделать к нему примесь или перекрыть оригинальную функцию своей и даже самые лучшие пакеты, если их использовать в одном проекте, часто конфликтуют и ведут себя менее предсказуемо, чем хотелось бы. Вот поэтому, перед тем, как делать крупные приложения, я был вынужден сначала сделать свой сервер приложений Impress, закрывающий большинство этих проблем. Обещанная статья про него будет тут в течении 10 дней.

Если говорить откровенно, то переход поначалу немного сложноват. Но со временем как-то привыкаешь и все кажется естественным. Это, скорее субъективное мнение, но мне удобнее сейчас писать на node.js, чем, на том же php. Хотя приходится паралельно и на том и на том писать. Другими словами, если появилось желание, то однозначно стоит попробовать.