Наблюдая за развитием популярных проектов можно увидеть как меняется ответ на вопрос "А зачем использовать этот проект?". Давайте посмотрим как менялся этот ответ для проекта Next с течением времени, 1 -> 2 -> 3. 1. SEO - обычные SPA не индексируются, го просто добавим SSR без необходимости переписывания нашего SPA-приложения. 2. Performance - делая SSR мы избавляемся от водопада запросов и уменьшаем клиентский рендеринг. 3. Политика - Next слился с React, экосистема хочет замкнуться на Vercel, cкупаюся конкуренты (Nuxt и Svelte), релизы хотят решить проблемы Vercel, а не твои, хочется бежать. (мы находимся здесь)
А теперь посмотрим на какой стадии находится Bun. 1. Performance - нууу нет. Кажется с самого начала слова "fast" и "Bun" слились вместе. Но когда мы говорим fast хочется x10, x5, ну хотя бы x2. Но таким цифрам просто неоткуда взяться (я говорю про runtime). На реальном проекте с реальной бизнес логикой скорость на Bun будет ~ x1.3 по сравнению с Node. А вот время старта сильно лучше в Bun за счет движка JavaScriptCore. 2. Экосистема - ДА и очень ДА. Unix-way подход в JS экосистеме был ошибкой. Шутки про пакеты is-odd, is-even и когда наше приложение представляет собой пакет с пакетиками - это совсем не шутки. Я просто устал от этого. Посмотрел сейчас историю файла package.json, кол-во зависимостей после переезда на Bun сократилось в 2.5 раза. И как пишет сам Bun "Время, которое вы тратите на поиск библиотек, можно было бы потратить на разработку приложения." 3. ??? - а вот здесь вопросы, как и на чем будет зарабатывать Bun и какие риски это принесет. Не хочется, чтобы случилось как с Next. Я думал именно в этом релизе мы узнаем ответ, но кажется ещё рано.
Итого: я перевел на Bun все свои Node проекты - и backend, и frontend приложения, стало легче дышать. Т.к. это drop in replacement для Node я не вижу особо рисков в данный момент, а может и в будущем.
С детства за Bun.
Наблюдая за развитием популярных проектов можно увидеть как меняется ответ на вопрос "А зачем использовать этот проект?". Давайте посмотрим как менялся этот ответ для проекта Next с течением времени, 1 -> 2 -> 3.
1. SEO - обычные SPA не индексируются, го просто добавим SSR без необходимости переписывания нашего SPA-приложения.
2. Performance - делая SSR мы избавляемся от водопада запросов и уменьшаем клиентский рендеринг.
3. Политика - Next слился с React, экосистема хочет замкнуться на Vercel, cкупаюся конкуренты (Nuxt и Svelte), релизы хотят решить проблемы Vercel, а не твои, хочется бежать. (мы находимся здесь)
А теперь посмотрим на какой стадии находится Bun.
1. Performance - нууу нет. Кажется с самого начала слова "fast" и "Bun" слились вместе. Но когда мы говорим fast хочется x10, x5, ну хотя бы x2. Но таким цифрам просто неоткуда взяться (я говорю про runtime). На реальном проекте с реальной бизнес логикой скорость на Bun будет ~ x1.3 по сравнению с Node. А вот время старта сильно лучше в Bun за счет движка JavaScriptCore.
2. Экосистема - ДА и очень ДА. Unix-way подход в JS экосистеме был ошибкой. Шутки про пакеты is-odd, is-even и когда наше приложение представляет собой пакет с пакетиками - это совсем не шутки. Я просто устал от этого. Посмотрел сейчас историю файла package.json, кол-во зависимостей после переезда на Bun сократилось в 2.5 раза. И как пишет сам Bun "Время, которое вы тратите на поиск библиотек, можно было бы потратить на разработку приложения."
3. ??? - а вот здесь вопросы, как и на чем будет зарабатывать Bun и какие риски это принесет. Не хочется, чтобы случилось как с Next. Я думал именно в этом релизе мы узнаем ответ, но кажется ещё рано.
Итого: я перевел на Bun все свои Node проекты - и backend, и frontend приложения, стало легче дышать. Т.к. это drop in replacement для Node я не вижу особо рисков в данный момент, а может и в будущем.
Согласен, современные детсады и школы это про дрессировку и послушание в первую очередь. Это основная цель, а не какие-то там знания.
Я никого не хотел убивать. Со мной что-то не так?
Я напишу цикл на своем любимом языке программирования в котором буду делать http GET на твой проект. Отгадай как Cloudflare защитит тебя от этого?
Никак. Cloudflare подходит только для защиты от больших распределенных атак.