Comments 24
Мой вариант cabal =)
Я пользуюсь Bun в последнее время, преимущественно из-за скорости и совместимости с npm.
В продакшн? Как Bun себя показывает, помимо скорости, хватает ли текущих возможностей? Есть же гипотеза, что когда Bun допилит всё то что умеют другие сборщики/менеджеры/Node.js и тп, то по скорости он уже не так сильно выигрывать будет
Будет
Банально потому что он не написан на JS
Npm, yarn, pnpm все написаны на JS, так что написанный на Zig (условно, современном эквиваленте C) Bun, очевидно, будет намного быстрее
Bun транспилирует Typescript немного быстрее esbuild (написанно на go), поскольку лучше оптимизирован
Bun немного медленнее NodeJS, поскольку JSCode немного медленнее V8, но на простых примерах когда сравнивается скорость рантайма а не JS-движка (http-запросы, в которых JS не занимает 80% времени) Bun может быть в несколько раз быстрее
Скорость это один из критериев выбора инструмента, и мне было бы очень интересно увидеть чей-нибудь реальный опыт переезда с Node.js на Bun в SSR проекте и посмотреть на разницу в rps, если и тут будет ощутимый прирост, то это весомый аргумент посмотреть в его сторону. Но нельзя забывать про другие критерии вроде безопасности и возможностей
Как уже говорилось, на реальных приложениях самые медленные процессы будут задавать производительность всей системы. Работы с сетью, БД, файловой системой - это будет давать 95% времени выполнения скрипта микросервиса или бэкенда, и разница между Node.js и Bun будет в пределах 5%-10% в итоге. Сложные вычислительные вещи на JS вряд ли кто-то будет писать.
Так вроде bun это аналог node?
Yarn же так же имеет возможность pnp.
Недавно много раз тестировал установку проекта. Выяснилось, что Window 10 удаляет директорию node_modules медленней, чем потом pnpm её ставит. Из кэша, конечно, но тем не менее впечатляет.
pnpm давно уже лучший однозначно.
Монорепы - зло
Такой риск присутствует во многих инструментах, в идеале обезопасить себя внутренним хранилищем Nexus. То что Pnpm открыл доступ к документации это обнадёживает, ну и хочется верить что этот тренд прошлого года прошел и программирование затрагиваться больше не будет. Тем более если действительно автор что-то вредоносное сделает с исходниками, то это прецендент и он быстро потеряет популярность и аудиторию не только России.
Тем более если действительно автор что-то вредоносное сделает с исходниками, то это прецендент и он быстро потеряет популярность и аудиторию не только России.
Ой, сомнительно. Например (а это один пример из многих), после февраля 22го пакет event-source-polyfill в российских часовых поясах в части окружений показывал алерт о злых русских, блокировав страницу, а в части окружений её просто крашил. Особенно весело, когда подобное приходит как зависимость зависимости. ЕМНИП, NPM отказался это дело удалять, сочтя приемлемым protestware. Через полгодика, вроде, после срача на MDN, изменения откатили назад. И что, хоть как-то сказалось на популярности? Мало того, слишком многие западные коллеги писали, что так и надо. А некоторые, в десятки раз более популярные пакеты (es5-ext, например), до сих пор не откатились.
Да и по поводу тренда сомнительно - везде гайки закручиваются, вполне может и сюда опять перекинуться.
Интересно что event-source-polyfill от российского разработчика. Мой посыл в том что вредоносное ПО было всегда и везде, сейчас просто некоторые люди просто себе нашли дополнительный повод, и ранее и в дальнейшем надо защищаться и проверять абсолютно весь код устанавливаемый из open source.
в каждом readme на гитхабе первой строкой везде идёт yarn, а уже потом npm. Никогда этого не понимал. Какое то насильное пропихивание не самого лучшего инструмента
npm overrides для решения вашей проблемы с версиями не помог?
Что выбрать: Npm, Yarn или Pnpm?