00:00:00(весёлая музыка) - Привет, все!
00:00:06Я Лидия.
00:00:07Мой титул — главный по пропаганде в BUN.
00:00:11Если вы немного обо мне знаете,
00:00:13то знаете,
00:00:13что я люблю говорить о JavaScript runtime и производительности.
00:00:17До того как я присоединилась к BUN,
00:00:19я работала в Vercel пару лет и учила разработчиков Next,
00:00:22как строить приложения быстрее.
00:00:24Поэтому я очень рада быть здесь и показать вам,
00:00:27как всё может быть намного быстрее,
00:00:29когда мы объединяем производительность Next Framework с производительностью BUN runtime.
00:00:35Но перед тем,
00:00:36как говорить о самом BUN,
00:00:38я хочу сделать небольшой шаг назад и показать,
00:00:41что делает такие фреймворки,
00:00:42как Next.js,
00:00:43настолько особенными.
00:00:45Потому что они действительно переосмыслили то,
00:00:47как мы видим производительность в вебе.
00:00:49Это не только сделало сайты быстрее.
00:00:52Это оптимизировало каждый этап процесса.
00:00:55У нас появилась умная сборка с Webpack,
00:00:58а теперь — с Turbo Pack.
00:00:59Встроенная оптимизация изображений и шрифтов.
00:01:02Эффективный серверный рендеринг,
00:01:05статический рендеринг,
00:01:06и теперь у нас есть ISR и RSC,
00:01:08что позволяет доставлять данные прямо в компонент.
00:01:12Все эти улучшения расширили возможности оптимизации фреймворка,
00:01:18но только до определённой точки.
00:01:21Всегда был один фундаментальный уровень,
00:01:23который Next.js не смог оптимизировать.
00:01:26И это не из-за недостатка инженерных усилий или возможностей,
00:01:31это просто вне области Next.
00:01:34Это сам runtime.
00:01:37Обычно,
00:01:37когда вы запускаете Next dev или разворачиваете на Vercel,
00:01:40ваше приложение Next работает на Node.
00:01:42Это значит, что Node runtime выполняет ваш JavaScript.
00:01:45Он управляет event loop, файловым вводом-выводом, всем.
00:01:49И он соединяет ваш JavaScript код с операционной системой.
00:01:53Это имеет смысл,
00:01:54потому что Node был стандартным runtime около 15 лет.
00:01:59Он хорошо проверен,
00:02:01надёжен,
00:02:02но в 2025 году он немного стал узким местом.
00:02:06Не поймите неправильно, Node фантастический.
00:02:09Он позволил запускать JavaScript на сервере.
00:02:13До этого, до 2009 года, JavaScript был только для браузера.
00:02:20Node изменил это,
00:02:21дав нам runtime с JavaScript движком,
00:02:23event loop,
00:02:24асинхронным вводом-выводом и API для всего,
00:02:27что браузеры не могут делать.
00:02:29Например,
00:02:29чтение файлов с диска,
00:02:31работа с памятью и всё остальное.
00:02:33Под капотом Node использует JavaScript движок V8.
00:02:37Это быстрый движок Chrome от Google,
00:02:39отличный для долгоживущих задач,
00:02:42вроде вкладки в браузере Chrome.
00:02:44Но конечно, V8 — это просто движок.
00:02:46Он умеет только выполнять JavaScript.
00:02:49Он не может открывать файлы,
00:02:52делать TCP соединения и всё такое.
00:02:54Вот здесь вступают встроенные API Node.
00:02:57Вроде FS, HTTP, NET и так далее.
00:03:01Эти API — своего рода мост между нашим JavaScript кодом и операционной системой.
00:03:07И сами эти API опираются на C библиотеку libuv.
00:03:13Это не создано для самого JavaScript.
00:03:16Это больше похоже на универсальную абстракцию,
00:03:19которую Node использует для работы с файловым вводом-выводом,
00:03:23сетевыми операциями и тому подобным на разных операционных системах.
00:03:27Так что когда мы вызываем что-то вроде fs.readFile в нашем JavaScript коде,
00:03:32мы действительно просим компьютер прочитать файл с диска.
00:03:36Но прежде всего это должно пройти через V8,
00:03:40то есть из JavaScript кода в V8.
00:03:42Потом это передаётся в C++ привязку Node.
00:03:46Это вызывает libuv,
00:03:47и это даже не учитывает работу потоков и всех этих накладных расходов.
00:03:52И только потом libuv делает системный вызов к нашему ядру,
00:03:56чтобы получить этот файл с диска.
00:03:58А пока всё это происходит,
00:03:59у нас есть event loop,
00:04:01который libuv использует,
00:04:02так что остальной JavaScript код может продолжать выполняться и так далее.
00:04:06И эта модель работает хорошо.
00:04:08Мы всё ещё используем Node, но это не оптимально.
00:04:13Итак,
00:04:13вернёмся в 2009 год,
00:04:14когда был представлен Node,
00:04:16наше оборудование выглядело совсем по-другому.
00:04:19Серверы,
00:04:20может быть,
00:04:21имели четыре ядра,
00:04:22ограниченную память,
00:04:23и хранилище было довольно медленным.
00:04:25Потоки тоже были дорогими,
00:04:27поэтому создание нового потока для каждого соединения просто не масштабировалось хорошо.
00:04:32Поэтому модель Node была отличной для того времени,
00:04:35потому что мы могли использовать один поток для обработки тысяч соединений очень эффективно.
00:04:40Но если прыгнуть в 2025 год,
00:04:41наше оборудование выглядит совсем иначе.
00:04:44Теперь у нас есть сотни ядер процессора,
00:04:47терабайты памяти,
00:04:48и хранилище в 50 раз быстрее.
00:04:51Но мы всё ещё используем модель Node,
00:04:53основанную на 2009 году.
00:04:55Мы всё ещё пропускаем всё через тот же event loop.
00:04:59И снова, это хорошо.
00:05:00Архитектура Node хорошая, когда серверы работали дни.
00:05:04Но в современное время часто есть serverless функции или dev серверы.
00:05:09Все эти более короткие скрипты,
00:05:11которые нужно быстро запустить и которые работают гораздо короче.
00:05:16Поэтому в этих окружениях каждая миллисекунда запуска и каждый слой данных имеют значение,
00:05:22потому что всё это добавляется к задержке.
00:05:24Итак,
00:05:25когда вы запускаете ваше приложение Next,
00:05:30вы запускаете его на Node.
00:05:34Это значит,
00:05:34что всё,
00:05:35что делает ваше приложение,
00:05:36вроде рендеринга страниц,
00:05:37обслуживания ресурсов,
00:05:38потоковой передачи ответов,
00:05:39всё это проходит через все эти слои,
00:05:41которые мы только что видели.
00:05:43От JavaScript к V8 к Node, и всё остальное.
00:05:46И Next проделал невероятную работу,
00:05:49выжимая каждый бит производительности,
00:05:52несмотря на то что Node runtime по-прежнему блокирует некоторые вещи.
00:05:57Потому что в конце концов,
00:05:58все эти улучшения по-прежнему работают поверх Node.
00:06:01Поэтому,
00:06:02когда вы запускаете dev сервер или перестраиваете файлы,
00:06:05hot reloading,
00:06:06вы всё ещё упираетесь в ограничения runtime.
00:06:09Поэтому,
00:06:09если мы действительно хотим идти быстрее,
00:06:11мы должны посмотреть за пределы фреймворка.
00:06:13Мы должны копнуть глубже.
00:06:15Мы должны пересмотреть сам runtime.
00:06:18Вот здесь входит BUN.
00:06:20BUN это не просто ещё один слой поверх Node.
00:06:24Это совершенно новый runtime,
00:06:27созданный с нуля для оборудования,
00:06:30которое у нас есть в 2025 году.
00:06:33Вместо того чтобы быть написанным на C++ поверх LibUV,
00:06:37как Node,
00:06:38BUN написан на Zig.
00:06:40Это современный системный язык,
00:06:42который работает намного ближе к железу.
00:06:45Для JavaScript движка BUN использует очень быстрый JavaScript Core от Apple.
00:06:51И он запускается действительно быстро,
00:06:53в основном потому,
00:06:54что может отложить некоторые оптимизации инициализации,
00:06:57которые делают движки вроде V8.
00:06:59И он также работает очень быстро,
00:07:01что идеально подходит для современных задач,
00:07:04которые мы используем сейчас,
00:07:06с dev серверами,
00:07:07serverless окружениями и короткими скриптами сборки.
00:07:10Сам основной runtime написан на Zig.
00:07:13Поэтому API BUN и все части,
00:07:15которые обрабатывают асинхронный ввод-вывод.
00:07:17Где Node использует LibUV для всех этих асинхронных операций,
00:07:22вроде чтения файлов,
00:07:23сетевых запросов и прочего,
00:07:25BUN может реализовать их как прямые системные вызовы к операционной системе,
00:07:31потому что написан на Zig.
00:07:33Сейчас для сетевых запросов мы используем useSockets,
00:07:36так что это немного другое.
00:07:37Но мы удаляем так много слоёв абстракции,
00:07:41используя Zig вместо LibUV.
00:07:44Итак,
00:07:45если вы хотите прочитать файл с BUN runtime,
00:07:47он всё ещё идёт,
00:07:48конечно,
00:07:48из вашего JavaScript кода.
00:07:49Теперь он идёт к JSC движку на Zig,
00:07:52который затем может сделать прямой системный вызов.
00:07:55Итак,
00:07:55снова,
00:07:56меньше слоёв между нашим JavaScript кодом и реальной операционной системой.
00:08:01И результат в том,
00:08:02что всё работает намного быстрее,
00:08:05от запуска до доступа к файлам,
00:08:07HTTP серверам и прочему.
00:08:09Но BUN это не только про производительность.
00:08:12Мы также стремимся быть на 100% совместимы с Node.
00:08:15Поэтому мы хотим убедиться, что работают все API Node.
00:08:19Но он также поставляется с тоннами дополнительных встроенных API,
00:08:23вроде S3,
00:08:24SQL,
00:08:25или как бы вы это ни называли.
00:08:27Redis, хеширование, shell и много чего ещё.
00:08:30И если вы когда-нибудь использовали другие языки программирования,
00:08:34вроде Go или Python,
00:08:35этот подход "батарейки в комплекте" вам очень знаком.
00:08:39Но как разработчики JavaScript,
00:08:41мы просто привыкли устанавливать зависимости для практически всего.
00:08:45Я использую хеширование пароля в почти всех своих приложениях.
00:08:48Но мне всё ещё нужно установить зависимость каждый раз,
00:08:51когда я это использую.
00:08:52BUN меняет это.
00:08:54Всё,
00:08:54что вы используете практически всё время,
00:08:57просто встроено в сам runtime.
00:08:59Это просто встроено в global.
00:09:01И снова,
00:09:01это не просто поверхностные обёртки поверх NPM зависимости.
00:09:06Это действительно встроено на Zig.
00:09:08Поэтому это оптимизировано для производительности для современного оборудования.
00:09:12Например, BUN имеет встроенный SQL клиент.
00:09:16Поэтому вы можете подключаться напрямую к Postgres,
00:09:20MySQL и SQLite,
00:09:21используя единственный API.
00:09:23Вам не нужно устанавливать никакие дополнительные зависимости.
00:09:26И снова, это не просто вызов какого-то пакета из NPM.
00:09:30Это действительно всё BUN, прямо общающийся с системой.
00:09:35И это не просто удобство, что у нас есть это встроенное.
00:09:38Опции BUN обычно также намного быстрее,
00:09:41чем альтернативы Node и NPM.
00:09:44Например,
00:09:45BUN.SQL в 11 раз быстрее,
00:09:47чем MySQL 2 на Node,
00:09:49что очень хорошо.
00:09:51Или вы можете использовать S3 клиент BUN.
00:09:54И это работает из коробки с любым S3-совместимым хранилищем.
00:09:58Amazon S3,
00:09:59Supabase Storage,
00:10:00Cloudflare R2,
00:10:01называйте как угодно.
00:10:03И снова, этот API также невероятно быстрый.
00:10:06Здесь мы видим,
00:10:07что это в 6 раз быстрее,
00:10:10чем AWS S3 SDK на Node.
00:10:12Конечно,
00:10:13вы по-прежнему можете использовать ваши обычные зависимости с BUN runtime.
00:10:17Вам не нужно использовать эти встроенные API.
00:10:20Но они действительно сильно уменьшают размер вашего бандла,
00:10:23потому что мы больше не добавляем эти зависимости.
00:10:25И это помогает с уязвимостями NPM,
00:10:27которые мы видели в прошлом месяце,
00:10:30потому что вам не нужно их устанавливать.
00:10:32Есть тонны других API.
00:10:33Я очень рекомендую вам посмотреть документацию.
00:10:37Но BUN поставляется не только с runtime.
00:10:40Он также включает очень быстрый менеджер пакетов,
00:10:44который в 17 раз быстрее,
00:10:46чем YARN,
00:10:47в 7 раз быстрее,
00:10:48чем NPM,
00:10:49и в 4 раза быстрее,
00:10:50чем PNPM.
00:10:51И хорошая новость,
00:10:52вам не нужно использовать BUN runtime для использования BUN install.
00:10:55И это просто-- вы можете использовать BUN install с Node.
00:10:58Это просто работает.
00:10:59Поэтому вам не нужно ничего менять в вашем проекте.
00:11:03Он также имеет очень быстрый встроенный бандлер и транспилер.
00:11:06Поэтому вы можете обслуживать и строить ваши файлы мгновенно.
00:11:09Поэтому вам не нужен Webpack,
00:11:10ESBuild,
00:11:11никакой дополнительной настройки.
00:11:12И хорошая новость в том,
00:11:14что он также поддерживает TypeScript и JSX из коробки.
00:11:18У него также очень быстрый тестовый раннер,
00:11:21в 14 раз быстрее Vitest и в 23 раза быстрее jest,
00:11:24когда мы SSR около 1000 React тестов.
00:11:26Итак, снова, вы получаете действительно быстрые тесты.
00:11:29Вам не нужно ничего устанавливать.
00:11:31Итак,
00:11:32всё это звучит отлично,
00:11:33но как мы можем использовать BUN runtime?
00:11:35И в Next, честно говоря, это очень просто.
00:11:38После установки BUN,
00:11:39вам просто нужно обновить вашу команду start или dev команду и добавить bun run --bun.
00:11:45Вот и всё.
00:11:46Вы теперь работаете на BUN runtime.
00:11:48Теперь вы можете спросить, зачем мне этот --bun?
00:11:51Типа, я уже говорю bun run.
00:11:54Это опять же,
00:11:54потому что BUN действительно заботится о совместимости с node.
00:11:57Обычно,
00:11:58если мы просто используем bun run next dev,
00:12:02BUN обнаружит,
00:12:03что next CLI использует node shebang.
00:12:07И в этом случае BUN будет как,
00:12:08ОК,
00:12:09я понимаю,
00:12:09что должен использовать node.
00:12:11Так что тогда он просто вернётся по умолчанию на node,
00:12:14даже если мы сказали bun run.
00:12:15Но с флагом --bun,
00:12:16мы как бы принудительно пропускаем shebang и говорим,
00:12:19ОК,
00:12:20мы просто используем bun runtime.
00:12:21Так что просто в качестве дополнительного пояснения.
00:12:25Итак, с этой командой bun запускает ваш next dev сервер.
00:12:29Сам бандлер всё ещё Next.
00:12:31Так что это, знаете, Turbo Pack.
00:12:33Я думаю Web Pack,
00:12:34Turbo Pack,
00:12:34теперь это значение по умолчанию.
00:12:35Но теперь runtime,
00:12:36лежащий в основе всего этого,
00:12:38вещь,
00:12:39которая выполняет ваш JavaScript,
00:12:41читает файлы,
00:12:41обслуживает ответы и так далее,
00:12:43это всё bun.
00:12:44И потому что bun разработан для совместимости с node,
00:12:47вам не нужно ничего менять в вашем коде.
00:12:50Ваши пакеты или ваш middleware.
00:12:51Всё должно работать.
00:12:53Если этого не происходит, это также считается ошибкой в bun.
00:12:57Это должно быть на 100% совместимо с node.
00:12:59Поэтому если вы это пробуете и сталкиваетесь с проблемами,
00:13:01дайте нам знать.
00:13:02Но вам не нужно ничего переписывать.
00:13:05И теперь,
00:13:06когда ваше приложение работает поверх bun,
00:13:08вы получаете доступ ко всем встроенным API bun.
00:13:10Например,
00:13:10мы можем просто использовать S3 клиент,
00:13:13верно,
00:13:13в серверной функции,
00:13:14в React server component и так далее.
00:13:16Поэтому нам не нужно устанавливать никакие зависимости.
00:13:18Так что просто для сравнения,
00:13:20как бы это обычно выглядело с Node,
00:13:22вы видите,
00:13:23что с bun у нас намного меньше кода.
00:13:25У нас меньше зависимостей.
00:13:27И это моментально совместимо со всеми другими S3 провайдерами также.
00:13:32Так что если вы хотите переключиться с Amazon S3 на Cloudflare R2,
00:13:36Supabase Storage,
00:13:37все эти другие провайдеры,
00:13:39это очень просто.
00:13:40Или более полный пример,
00:13:42мы можем использовать S3,
00:13:44bun shell и SQL прямо в React server component.
00:13:47Итак,
00:13:48сначала мы запрашиваем БД с SQL,
00:13:50чтобы получить блог-пост,
00:13:51генерируем заранее подписанный S3 URL для изображения,
00:13:54используем bun shell для подсчёта слов.
00:13:57Снова,
00:13:57нет никакого дополнительного слоя API или сторонних инструментов,
00:14:01которые BUN вызывает.
00:14:02Bun обрабатывает runtime,
00:14:04соединения БД и shell все нативно на Zig,
00:14:07очень близко к железу.
00:14:10И снова, конечно, это не только S3 SQL.
00:14:12Мы получаем доступ ко всем API bun,
00:14:15просто добавив bun run --bun перед next dev.
00:14:20Но конечно,
00:14:21сейчас вы можете подумать,
00:14:22ОК,
00:14:23я не использую Postgres.
00:14:24Я не использую S3.
00:14:25Я не использую никакие сумасшедшие зависимости,
00:14:27так почему мне это должно быть интересно?
00:14:28Вещь,
00:14:29которая привлекла меня к bun до того,
00:14:31как я присоединилась,
00:14:32была честно просто невероятным DX.
00:14:34Вы можете просто запустить любой JS,
00:14:37TS,
00:14:37TSX,
00:14:38JSX,
00:14:38неважно какой файл без никакой конфигурации.
00:14:41Это просто работает.
00:14:41Вам не нужно думать о TSNode, Babel, SWC и так далее.
00:14:46Поэтому даже если вы не используете next,
00:14:48даже если вы просто разрабатываете,
00:14:50вам нужен быстрый скрипт сборки,
00:14:52просто используйте bun run,
00:14:53просто попробуйте,
00:14:54это делает вашу жизнь намного лучше,
00:14:56потому что вам не нужна никакая конфигурация.
00:14:59Bun также идёт с bun x.
00:15:01И это аналог BUN для NPX.
00:15:04Снова, вам не нужно ничего менять.
00:15:06Вам не нужно использовать bun runtime для этого.
00:15:08Вы можете просто заменить NPX на bun x.
00:15:11И вы видите немедленные улучшения запуска.
00:15:13Например,
00:15:14используя bun x create-next-app в 5 раз быстрее,
00:15:18чем npx create-next-app.
00:15:20И снова, вам не нужно использовать bun runtime для этого.
00:15:23Это просто намного быстрее.
00:15:25Но конечно,
00:15:26есть также bun install,
00:15:27который опять же не требует от вас менять runtime.
00:15:31Это просто делает ваши установки намного быстрее,
00:15:34также на базовых next проектах.
00:15:36Очевидно, запуск bun локально это одно.
00:15:39Но как мы развёртываем приложения, которые работают на bun?
00:15:42Потому что это, конечно, совершенно новый runtime.
00:15:46Вы уже можете использовать Next.js на bun на нескольких платформах,
00:15:50вроде Render,
00:15:51Railway,
00:15:51или контейнеризировать ваше приложение с Docker.
00:15:54Но мы все разработчики Next.js.
00:15:56Ideально,
00:15:57мы также хотим иметь возможность развёрнуть на Vercel.
00:16:00Поэтому естественно,
00:16:02мы написали твит Гильермо,
00:16:03любезно попросив его об встроенной поддержке bun на Vercel.
00:16:07И мы довольно быстро получили многообещающий ответ.
00:16:10И потом пару недель спустя,
00:16:12поддержка bun была достигнута,
00:16:14по крайней мере,
00:16:15внутри.
00:16:15Поэтому я очень рада,
00:16:17что встроенная поддержка bun придёт на Vercel очень,
00:16:20очень скоро.
00:16:20И это значит, что вы сможете-- [АПЛОДИСМЕНТЫ] Да.
00:16:25Аплодисменты для замечательных инженеров Vercel,
00:16:28которые сделали это возможным.
00:16:29Но это очень волнующе,
00:16:30потому что это значит,
00:16:32что мы можем теперь запускать bun приложения просто так же легко,
00:16:35как любой другой Next проект на Vercel.
00:16:37Итак, также просто реальный пример.
00:16:39Я не уверена, сможете ли вы это увидеть на экране.
00:16:41Но запуск HONO API с bun уже показал 30% снижение или снижение CPU,
00:16:46просто запуском bun на Vercel.
00:16:49Это, конечно, другой фреймворк.
00:16:50Это HONO API.
00:16:52Но это те же преимущества runtime,
00:16:53которые вы получите,
00:16:54если бы это была серверная функция,
00:16:56RSC и так далее.
00:16:57Потому что bun экономит много в использовании CPU и памяти.
00:17:02Теперь мы,
00:17:02конечно,
00:17:03не должны ждать встроенной поддержки bun,
00:17:04чтобы начать использовать это в наших приложениях.
00:17:06Самый простой способ это как-то начать использовать это или внедрять это постепенно.
00:17:11Итак,
00:17:11сначала я рекомендую просто переключиться на bun install.
00:17:14Ничего не меняется в вашей кодовой базе.
00:17:16Это просто использует действительно быстрый менеджер пакетов bun.
00:17:19Также,
00:17:19если вы заинтересованы в том,
00:17:21почему bun install так намного быстрее,
00:17:23я написал статью об этом не так давно.
00:17:24Я настоятельно рекомендую вам посмотреть её.
00:17:26Это просто объясняет-- знаете, мы не просто пропускаем шаги.
00:17:29Мы делаем что угодно.
00:17:29Это как-то объясняет системную инженерию,
00:17:32которая за этим стоит,
00:17:33что делает это намного быстрее.
00:17:35Теперь после использования bun install,
00:17:37затем попробуйте использовать bun runtime.
00:17:39Вы можете просто использовать его локально с bun run --bun.
00:17:42Протестируйте ваше приложение.
00:17:42Посмотрите, работает ли всё.
00:17:44Должно.
00:17:45Если нет, дайте нам знать.
00:17:47И затем в конце,
00:17:48вы можете как-то постепенно переходить на встроенные API bun,
00:17:51где это имеет смысл.
00:17:53Вы,
00:17:53конечно,
00:17:54можете по-прежнему смешивать и подбирать эти NPM зависимости.
00:17:57Но лучшая часть в том, что каждый шаг здесь обратим.
00:18:00Поэтому если вы использовали один из встроенных API bun и он не сработал,
00:18:04вы всегда можете просто переключиться обратно на node.
00:18:06Но это определённо стоит проверить.
00:18:08Теперь перед тем,
00:18:09как я закончу эту речь,
00:18:11я просто хочу сказать огромное спасибо удивительной команде инженеров в bun.
00:18:17Большинство людей знают Джареда,
00:18:18но за bun стоит целая команда,
00:18:20которая так усердно работает каждый день,
00:18:22чтобы сделать bun ещё быстрее,
00:18:24более стабильным и намного более приятным в использовании.
00:18:27Они действительно расширяют границы того,
00:18:30что возможно с JavaScript.
00:18:32Итак,
00:18:32Next переосмыслил,
00:18:34как мы строим для веба,
00:18:35но bun переосмысляет,
00:18:37что это питает.
00:18:38Спасибо большое за то,
00:18:39что пришли на мою речь,
00:18:40и я так взволнована видеть,
00:18:42что вы будете строить с bun и Next.