169 похожих чатов

Как мы ничему не научились на примере жизни и смерти

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.

1 ответов

36 просмотров

Странно немного. Там команда вроде не такая маленькая - и денег они набрали будь здоров - еще протянут долго

Похожие вопросы

Обсуждают сегодня

30500 за редактор? )
Владимир
47
Недавно Google Project Zero нашёл багу в SQLite с помощью LLM, о чём достаточно было шумно в определённых интернетах, которые сопровождались рассказами, что скоро всех "ибешни...
Alex Sherbakov
5
вы делали что-то подобное и как? может есть либы готовые? увидел картинку нокода, где всё линиями соединено и стало интересно попробовать то же в ddl на lua сделать. решил с ч...
Victor
8
Подскажите пожалуйста, как в CustomDrawCell(Sender: TcxCustomGridTableView; ACanvas: TcxCanvas; AViewInfo: TcxGridTableDataCellViewInfo; var ADone: Boolean); получить наз...
A Z
7
Ребят в СИ можно реализовать ООП?
Николай
33
https://github.com/erlang/otp/blob/OTP-27.1/lib/kernel/src/logger_h_common.erl#L174 https://github.com/erlang/otp/blob/OTP-27.1/lib/kernel/src/logger_olp.erl#L76 15 лет назад...
Maksim Lapshin
20
Как передать управляющий символ в открытую через CreateProcess консоль? Собсна, есть процедура: procedure TRedirectThread.WriteData(Data: OEMString); var Written: Cardinal;...
Serjone
1
Он в одиночку это дело запилил или была какая-то команда?
Aquinary
12
~ 2m21s  nix shell github:nixos/nixpkgs#stack ~  stack ghc -- --version error: … while calling the 'derivationStrict' builtin at /builtin/derivation.nix:...
Rebuild your mind.
6
Всем привет, нужна как никогда, нужна помощь с IO в загрузчике. Пишу в code16 после установки сегментных регистров, пишу вывод символа. Пробовал 2 варианта: # 1 mov $0x0E, %a...
Shadow Akira
14
Карта сайта