Yarn
Статья от Джареда Вилкарта про Bun в моём любимом жанре «дедовское брюзжание». Как многие опытные программисты знают — выбирать надо скучные технологии. И сидя на берегу дождаться, пока мимо проплывут останки недавно хайповой штуки.
И вот Джаред проводит параллели между Yarn и Bun:
— продают «скорость»,
— раскалывают экосистему,
— не про обратную совместимость,
— в стабильной 1.0 версии не поддерживают Windows.
Yarn на старте был быстрее npm. Но npm догнал его по скорости, а создателям Yarn пришлось объяснять, что вообще-то они были не про перформанс, а про фичи. Сложно конкурировать с владельцем npm-серверов.
В итоге, все фичи yarn внедрены в npm и npm ещё и быстрее (тут Джаред почему-то забывает про Plug'n'Play, который пусть не сразу, но появился в Yarn, но так и не был реализован в npm). Да, есть нюансы, кому-то они важны, но для большинства людей подходит npm.
Вот и Bun — он не делает ничего, что нельзя было бы достичь в Node.js не ломая обратную совместимость. Так что в какой-то момент Node.js скорее всего получит паритет по скорости. И маркетинговая шумиха про скорость сойдёт на нет.
Ок, Yarn пришёл, пошумел и умер. В процессе подстегнул npm. В чём проблема? В том, что пока Yarn шумел и продавал функции, которые на самом деле в большей степени были нужны только Facebook, команде npm пришлось гнаться за ним и добавлять схожие фичи, чтобы экосистема не раскололась сильно. При этом были изменены приоритеты, фактически Facebook косвенно повлиял на порядок внедрения фичей в npm.
А дальше Yarn проник в Readme. Куча проектов стала ориентироваться на Yarn и писать инструкции, как развернуть их с помощью Yarn. Смущая новичков и тратя время синьоров на объяснения, почему в наш конкретный проект так ставить зависимости не нужно.
Вместо того, чтобы контрибьютить в npm Facebook потратил силы на создание собственной его копии. И ради чего?
Но bun гораздо опасней
Bun предлагает скорость и опасные фичи:
1. Макросы — ваша сборка теперь гвоздями прибита к Bun
2. bun.x API. Собственные «более быстрые» API. Ваш код будет «отравлен» ими. Придётся ставить зависимости — полифиллы. Ура, ещё одна зависимость.
3. Встроенную поддержку мета-языков. Тут подробнее.
Мета-языки временны. Их задача сделать программирование удобней, пока основной язык не дотягивает. Как только возможностей основного языка достаточно, мы отстреливаем мета-язык. Как выкинули CoffeeScript, как многие отказываются от Sass, потому что CSS сам по себе уже достаточно неплох. Но вот в Bun теперь встроен ужасный JSX и TypeScript.
А TS уже прошёл свой пик. Графики показывают первые признаки разворота сообщества с сторону более лёгких альтернатив, таких как eslint-plugin-jsdocs, а на горизонте маячит добавление статической типизации на комментариях в ES202X. В какой-то момент TS может сказать, что его работа закончена. Sass тут отличный пример — из популярнейшего дефолтного инструмента для всех он уходит в сторону узкоспециализированного продвинутого инструмента для профи.
А если бы Bun вышел в 2019 году на пике популярности Sass, то Sass был бы встроен в него. И что бы они делали в момент смены API? Вы уже не можете написать npm install <версия Sass>. Не нужно прибивать мета-языки к рантайму.
Bun приносит абстракции для кучи технологий, но он не абстрагируется от этих технологий. Он не берёт что-то сложное и делает это проще и универсальней — нет, он засовывает это в себя как есть. И всегда будет отставать от оригиналов (нужно следить за изменениями API и добавлять код в свою реализацию). При этом абстракции эти находятся в критически важных местах: установка зависимостей, тесты и сборка.
Дальше Джаред пишет про Windows. Сборка под неё экспериментальная и обещают позже дать стабильную. И Джаред сомневается, что столь небольшая команда сможет одновременно догонять фичи для Windows и пилить новые в Linux/OSX. А не пилить фичи нельзя. И как-то придётся выравнивать версии. Возможно через год у нас будет v1.8 для Linux и v1.0 для Win.
Странно немного. Там команда вроде не такая маленькая - и денег они набрали будь здоров - еще протянут долго
Обсуждают сегодня