PS: Пожалуйста, не забудьте оценить этот пост и поделиться своим мнением ????
Несмотря на обширный список преимуществ Bun 1.0 - (https://habr.com/ru/articles/760002/), в этой статье мы сосредоточимся на некоторых его недостатках и ограничениях. Это поможет вам более объективно оценить, подходит ли Bun 1.0 для вашего проекта.
Проблемы совместимости с Windows и экспериментальными функциями:
Некоторые разработчики выразили беспокойство ограниченной поддержкой Windows и экспериментальными функциями в Bun 1.0. Это может вызвать трудности для пользователей Windows и повышает риск нестабильной работы в экспериментальных частях бандлера. Также стоит отметить, что на данный момент Bun 1.0 не поддерживает HTTP/2, что является значимым аспектом, учитывая его растущую популярность в веб-разработке.
Ограниченная настройка бандлера:
Еще одним недостатком Bun 1.0 является ограниченная возможность настройки бандлера. Например, разработчики выразили желание настраивать бандлер на основе файла tsconfig, но в текущей версии такая функциональность отсутствует. Важно отметить, что в Bun 1.0 весь код собирается в ES5, что может вызвать проблемы при компиляции и привести к утечкам переменных (var), требуя дополнительного времени на отладку.
Ограниченная поддержка Node.js API:
Bun 1.0 не обеспечивает полной поддержки Node.js API, что может означать, что некоторые модули не будут доступны для использования. Это может быть проблемой для проектов, зависящих от конкретных частей Node.js API.
Проблемы совместимости с библиотеками:
Существуют проблемы совместимости с некоторыми библиотеками, такими как gRPC и Nest, вызванные использованием reflect-metadata. Это может ограничивать ваш выбор библиотек и создавать сложности при интеграции с существующими проектами.
Отсутствие поддержки хвостовой рекурсии:
Один из основных минусов Bun 1.0, который вероятно будет актуален и в будущих обновлениях, - это отсутствие полноценной поддержки хвостовой рекурсии (Tail Call Optimization, TCO).
Стоит отметить, что хвостовая рекурсия является важной оптимизацией для рекурсивных функций, которые могут вызывать сами себя множество раз. Она позволяет избежать переполнения стека, оптимизируя вызовы функций в "хвостовой" позиции.
В этом контексте, многие разработчики ожидали, что Bun 1.0 предоставит поддержку TCO, чтобы повысить производительность и эффективность кода. Однако, как оказалось, такая поддержка пока отсутствует, что может оставить некоторые проблемы с производительностью в коде, особенно для проектов, активно использующих рекурсивные функции.
Ограниченная поддержка декораторов:
Важной особенностью многих современных JavaScript-фреймворков является использование декораторов для управления функциональностью. Например, Angular и Nest.js активно используют декораторы. К сожалению, на данный момент Bun 1.0 не поддерживает декораторы, что может создать проблемы при миграции с проектов, использующих их.
Отсутствие встроенной поддержки модуля node:child_process:
Bun 1.0 не включает встроенную поддержку модуля node:child_process в Node.js. Это ограничивает возможности разработчиков в выполнении системных команд и взаимодействии с процессами операционной системы. Вот некоторые сценарии, в которых отсутствие поддержки node:child_process может вызвать проблемы:
— Запуск внешних приложений
— Обработка потоков ввода и вывода
— Асинхронное выполнение команд
...
Сложность поддержки:
Поскольку Bun 1.0 использует JavaScriptCore, написанный на языке программирования Zig, для некоторых разработчиков может возникнуть сложность в поддержке и доработке проектов на этой технологии. Необходимость знания как JavaScript, так и Zig может затруднить внесение улучшений и исправлений.
Заключение:
Bun 1.0, несомненно, представляет собой интересный и перспективный инструмент в мире JavaScript. Он внес некоторые изменения и вызовы в среду разработки, и некоторые из них могут быть вызовом для разработчиков. Однако важно помнить о недостатках, которые могут повлиять на выбор этого бандлера для конкретных проектов.
Отсутствие поддержки хвостовой рекурсии, отсутствие поддержки HTTP/2, ограничения в настройке и совместимости с некоторыми библиотеками - все эти факторы должны быть внимательно взвешены при решении использовать Bun 1.0 в вашем проекте. Разработчики должны учитывать текущие недостатки и следить за будущими обновлениями, которые могут исправить или изменить ситуацию.
В конечном итоге, выбор бандлера зависит от конкретных требований проекта и команды разработчиков. Будущее Bun 1.0 может быть светлым.
PS: Пожалуйста, не забудьте оценить этот пост и поделиться своим мнением ????
Комментарии (10)
tot0ro
11.09.2023 23:20Мне кажется один только заголовок уже заслуживает тазик минусов.
Говорить "провал" о технологии без обкатки ее в боевом проекте как минимум 3-4 месяцев это как минимум странно.
А если по факту:Проблемы совместимости с Windows и экспериментальными функциями
Ну начнем с того что windows это самая непопулярная среда запуска
productionпроектов, таким образом чаще всего это используется разработчиками а для них уже давно сделалиWSLи какой вообще сейчас смысл запускать под чистым windows??? Честно говоря учитывая какие цели ставит данный проект я на данном этапе вообще бы отказался от поддержки windows как такового;Например, разработчики выразили желание настраивать бандлер на основе файла tsconfig
Это не желание а анализ многих популярных бандлеров которые уже так делают при работе с
typescript, таким образом они просто зафиксировали популярный подход, с целью его дальнейшего закрепления как стандарта;Важно отметить, что в Bun 1.0 весь код собирается в ES5, что может вызвать проблемы при компиляции и привести к утечкам переменных (var), требуя дополнительного времени на отладку.
Важно отметить что на многих легаси проектах ( у меня таких на работе минимум 20 ) сборка точно также происходит в
ES5и отладка при необходимости происходит либо на сырцах либо наsoure mapи причем тут вообще булка непонятно;Отсутствие поддержки хвостовой рекурсии
Интересно а как часто вообще на node.js пишут рекурсивные функции темболее с оптимизацие хвостовой? Это при том что обычно на ноде пишут
Api,Proxy,BFFи прочие веб сервисы и прослойки. За последние 6 лет ни на одном Front/Back проекте не видел использование рекурсии. На собесах видел и писал, а также рассказывал что скорее всего на боевом проекте сделаю такое только в редком случае ( по факту за карьеру написал в прод около 4 штук );В этом контексте, многие разработчики ожидали, что Bun 1.0 предоставит поддержку TCO, чтобы повысить производительность и эффективность кода.
Мне кажется от булки много чего в приципе не ожидали поскольку есть
node.jsиdenoвыстрелит, хорошо, не выстрелит в принципе не страшно. В первую очередь если что то и ждали это была производительность и тулинг. Но точно не оптимизацию хвостовых рекурсий на версии1.0Важной особенностью многих современных JavaScript-фреймворков является использование декораторов для управления функциональностью. Например, Angular и Nest.js активно используют декораторы.
А назовите пожалуйста еще несколько современных и популярных фреймворков которым нужны декораторы? Кроме двух уже указанных.
Вы удивитесь но оказывается декораторы не так уж и популярны в js мире и самые популярные проекты вы уже указали.
Ктому же никто не говорил что их не будет, они временно ограничены в функционале. Также если вы прочте официальный комент по этому поводу:
https://github.com/oven-sh/bun/issues/303
То узнаете что они ограничены уровнем поддежкиTypescriptОтсутствие встроенной поддержки модуля node:child_process:
Bun 1.0 не включает встроенную поддержку модуля node:child_process в Node.js. Это ограничивает возможности разработчиков в выполнении системных команд и взаимодействии с процессами операционной системы.Опять таки функционал который не требуется в 80-90% задач которые выполняет нода в современном мире. Опять таки это временное ограничение;
Поскольку Bun 1.0 использует JavaScriptCore, написанный на языке программирования Zig, для некоторых разработчиков может возникнуть сложность в поддержке и доработке проектов на этой технологии. Необходимость знания как JavaScript, так и Zig может затруднить внесение улучшений и исправлений.
А
esbuldнаписан на go, аswcиromeнаписаны на rust и вы удивитесь сколко еще вещей для мира ноды написанны не наjavascriptи опять таки это не имеет никакого отношение к рядовым проектам, а относится к тем кто хочет сделать вклад в сам рантайм и его развитие;В конечном итоге, выбор бандлера зависит от конкретных требований проекта и команды разработчиков. Будущее Bun 1.0 может быть светлым.
А я думал булка это рантайм для запуска кода, а у ТС это бандлер;
Заключение
Авторы булки взяли все самые необходимые ( с их точки зрения ) и популярные вещи и положили их в релиз
1.0используя которые можно перенести простой проект или написать небольшой проект с нуля. Очевидно что авторы булки не рассчитывают что кто то будет брать легаси проект на 300-400 модулей и 100+ зависемости и надеятся что вот он сразу без напильника запустится и наступит "рай на земле".
Все проекты версии1.0как правило включают самое необходимое для начала работы здесь и сейчас с приемлемым уровнем стабильности. Вполне логично что по достижению 90% барьера авторы будут добавлять менее популярные вещи ( как напримет таже поддержка windows ).
ТС же почему-то собрал все непопулярные вещи в одном посте не упомянув при этом плюсов сразу окрестил релиз провалом.
Зачем? Почему? Непонятно....
ARTUR_KARTAVY Автор
11.09.2023 23:20Привет! Спасибо большое за комментарий и детальные замечания. Это действительно ценно, и я готов рассмотреть каждый аспект, который вы подняли.
Относительно заголовка "провал": Я согласен, что использование такого слова в заголовке может быть более умеренным. В статье я попытался подчеркнуть некоторые недостатки Bun, но, конечно, это все еще молодой проект, и многие вещи могут измениться с развитием.
Про проблемы совместимости с Windows: Да, согласен, что Windows может быть не так популярна в продакшене, но она все равно используется многими разработчиками. Упоминание этой проблемы полезно для тех, кто работает с Windows, чтобы они знали о существующих ограничениях.
Насчет концепции поддержки TypeScript и использования декораторов: Вы правильно отмечаете, что это не так важно для всех проектов. Однако некоторые разработчики и команды ценят такие возможности, и они могут рассматривать это как важный аспект при выборе технологии.
Относительно модуля node:child_process: Это важно уточнение, что ограничение временное, и это может стать важным для разработчиков, которые полагаются на этот модуль.
Сложность поддержки и язык Zig: Я согласен, что многие проекты для Node.js имеют зависимости, написанные на других языках, и это не обязательно плохо. Однако упоминание этого аспекта полезно для разработчиков, которые хотят внести свой вклад в развитие Bun.
Заключение: Вы правильно указали, что выбор между технологиями зависит от конкретных потребностей проекта. Важно рассматривать каждую технологию с учетом своих целей и требований. Я постараюсь быть более сбалансированным и осторожным в оценке технологий в будущих статьях. Спасибо вам за обратную связь и ваши мысли!)
tot0ro
11.09.2023 23:20Относительно заголовка "провал": Я согласен, что использование такого языка в заголовке может быть более умеренным. В статье я попытался подчеркнуть некоторые недостатки Bun, но, конечно, это все еще молодой проект, и многие вещи могут измениться с развитием.
Пробема в том что вы использовали так называемый кликбейтный заголовок, причем еще и сильно провакационный на дугом менее спокойном ресурсе вам бы уже карму в глубокий минус слили за такой "желтый журнализм".
Про проблемы совместимости с Windows: Да, согласен, что Windows может быть не так популярна в продакшене, но она все равно используется многими разработчиками. Упоминание этой проблемы полезно для тех, кто работает с Windows, чтобы они знали о существующих ограничениях.
Для этого есть
WSLкоторая закрывает 95% потребностей, вnode.jsесть пакеты которые в принципе под windows работать небудут. Какой смысл тратить ограниченные ресурсы на то чем пользуется от силы 5-10% это все равно что сейчас в бандлере включить поддержку IE 6-8.Однако некоторые разработчики и команды ценят такие возможности, и они могут рассматривать это как важный аспект при выборе технологии.
Разработчики Angular? так булка не для них а для бека, а там кроме
nest.jsбольше особо некому возмущатся.Сложность поддержки и язык Zig: Я согласен, что многие проекты для Node.js имеют зависимости, написанные на других языках, и это не обязательно плохо. Однако упоминание этого аспекта полезно для разработчиков, которые хотят внести свой вклад в развитие Bun.
Тогда зачем вы это записываете в провал? Если это не плохо а просто особенность.
ARTUR_KARTAVY Автор
11.09.2023 23:20-1Заголовок "провал": Заголовок был выбран с целью привлечь внимание к недостаткам, которые, по моему мнению, имеются у Bun. Это не попытка желтого журнализма, а способ подчеркнуть важные моменты.
Проблемы совместимости с Windows: Вы абсолютно верно указали на существование WSL и других инструментов для работы с Windows, и это важно учитывать. Упоминание ограничений Bun на Windows может быть полезным для разработчиков, чтобы они знали, с чем могут столкнуться при работе с этой технологией.
Сложность поддержки и язык Zig: Да, вы правильно указали на то, что зависимости от других языков не обязательно плохо. Я подчеркнул этот аспект, чтобы разработчики понимали, что Bun может потребовать знания не только JavaScript, но и Zig для некоторых доработок. Это не плохо, а просто дополнительная информация для разработчиков.
Мне нравится данная технология, и я понимаю, что она ещё продолжает развиваться. Однако я решил упомянуть и минусы, потому что считаю, что важно быть в курсе того, с чем можно столкнуться при использовании новых технологий в продакшене. Некоторым разработчикам может быть полезно подождать до более стабильной версии, чтобы избежать возможных проблем.
Спасибо за ваши замечания, и я ценю ваше участие в обсуждении. Ваши комментарии помогают улучшить качество информации, представленной в статье.)
alexBurenko
11.09.2023 23:20Спасибо за информативную статью!
ARTUR_KARTAVY Автор
11.09.2023 23:20Пожалуйста! Рад, что статья оказалась полезной. Если у вас есть какие-либо дополнительные вопросы или нужна дополнительная информация, не стесняйтесь спрашивать. Буду рад помочь!)
Yavanosta
А что скажете про Deno?
SWATOPLUS
Ещё хуже. Совместимость с npm-пакетами слабее. Своих пакетов мало. Побаловаться и написать пару скриптов можно, удобнее чем ts-node. Но пилить на нем Angular/Vue или Nest приложение -- самоубийство. Для deno есть фреймворк fresh, но с ним связываться рисково.
Bun делает упор на совместимость. Ждём допила багов, поддержки винды и функций в расширении для vscode -- тогда заживём.
tot0ro
Смысл
Denoв том что у него вообще не может быть своих пакетов. Райн считает что то как раньше распространялись пакеты ( CDN ) это более правильный вариант а централизованный вариант ( NPM ) это одна из худших вещей которая произошла с node.js.ARTUR_KARTAVY Автор
Плюсы Deno:
Как всем известно, чересчур улучшенная безопасность.
Встроенный менеджер пакетов (соу-соу).
Активное сообщество.
Обширная дока.
Один из ключевых плюсов Deno заключается в том, что он обеспечивает встроенную поддержку TypeScript.
…
У Deno все же есть минусы, и не меньшие, чем у Bun:
Отсутствие большой экосистемы плагинов и библиотек.
Сложности с миграцией с Node.js.
Ограниченная совместимость с существующими модулями.
Отсутствие поддержки некоторых Node.js-модулей.
...
А вообще выбор между этими двумя технологиями зависит от конкретных потребностей твоего проекта. (Тут необходимо сесть с листочком и ручкой, разобраться, какой проект ты собираешься разрабатывать, начертить параллельную линию, выписывая обе этих технологии. После этого сравнить, что именно больше тебе нужно и в чем проект будет нуждаться в первую очередь. Не все проекты нуждаются в скорости)