00:00:00— Так что финальная публичная версия V+ будет,
00:00:03скорее всего, ощущаться как что-то веселое.
00:00:06— Это Эван Ю.
00:00:07— Эван Ю.
00:00:09— Эван Ю.
00:00:10— Эван Ю!
00:00:10— Я создал Vue, я создал Vite.
00:00:14Сейчас я руковожу компанией под названием VoidZero.
00:00:16— Чем Vite отличается от Vite+?
00:00:19— Опыт разработки будет точно таким же,
00:00:21каким он является в Vite сегодня.
00:00:22Но если вы захотите пойти дальше,
00:00:24инструмент поддержит вас на всем пути.
00:00:26— Как команда и вы сами используете ИИ?
00:00:28— Мы начали проводить безумные эксперименты,
00:00:30вроде портирования компилятора Angular на Rust.
00:00:32— Что вы думаете о серверных компонентах React?
00:00:34— Я был скептиком с самого первого дня.
00:00:36— Обычно, когда я представляю подкаст,
00:00:39я прошу гостей представиться самим.
00:00:40Но, думаю, если кто-то смотрит это
00:00:42и не знает, кто вы, я буду крайне удивлен.
00:00:44Мне кажется, вы просто очень известны.
00:00:46Но все должны знать,
00:00:48ну или большинство должны знать, кто вы такой.
00:00:49— По крайней мере, о Vite или Vue они точно слышали.
00:00:53— Да, я создал Vue и Vite.
00:00:57Сейчас я руковожу компанией VoidZero,
00:00:59где мы работаем над еще большим числом open-source проектов.
00:01:03Это Rolldown, Vitest, OXC.
00:01:07И да, Vue и Vite, наверное, более популярны,
00:01:11но некоторые вещи, над которыми мы работаем в VoidZero,
00:01:14тоже довольно крутые.
00:01:15Потому что Rolldown — это бандлер на базе Rust.
00:01:18OXC — это полноценный инструментарий на Rust, который включает
00:01:22всё: от парсера до резолвера, трансформера,
00:01:25минификатора и так далее.
00:01:28А на базе OXC у нас есть OX Lint и OX Format,
00:01:32который представляет собой линтер, совместимый с ESLint,
00:01:35и форматтер, совместимый с Prettier.
00:01:37Есть и другие наработки, но об этом позже.
00:01:41Пока что мы хотим в основном поговорить об open source.
00:01:45— Конечно.
00:01:45Раз уж вы работаете над столькими вещами сразу,
00:01:47как вы распределяете свое время?
00:01:50— Ну, лично я не пишу код
00:01:52для всех этих проектов.
00:01:53На самом деле, сейчас я пишу гораздо меньше кода,
00:01:56с тех пор как основал компанию.
00:01:58У нас в компании много инженеров,
00:02:01которые разбираются в Rust гораздо лучше меня,
00:02:03и сейчас они все плотно «подсели» на ИИ.
00:02:05Так что это наполовину они, а наполовину Claude или Codex,
00:02:10выдающие горы кода на Rust.
00:02:12А мне приходится принимать решения
00:02:17по поводу DX (опыта разработчиков),
00:02:22решать, на чем нам сосредоточиться в дальнейшем.
00:02:25И, очевидно, есть вопросы по продуктам:
00:02:28как превратить всё это в продукт,
00:02:31который будет приносить деньги.
00:02:32Над этим мы все еще работаем.
00:02:34Да, в общем, всё то, чем нужно заниматься,
00:02:39чтобы управлять компанией в наши дни.
00:02:41— Откуда берутся идеи
00:02:43для новых open-source проектов?
00:02:45Они в основном рождаются из внутренних потребностей,
00:02:48когда вы понимаете, что это могло бы помочь
00:02:49решить проблемы и других людей тоже?
00:02:53— На самом деле всё начинается с Vite, верно?
00:02:56Когда я создавал Vite, я просто экспериментировал.
00:03:01Всё началось как прототип,
00:03:03а потом я подумал: нам нужен бандлер.
00:03:07Мы начали с этого полностью «небандлированного»
00:03:10нативного ESM сервера для разработки.
00:03:13Эта идея отлично работала для простого кода,
00:03:16но затем мы начали подключать тяжелые зависимости
00:03:18и поняли: ладно, это не будет масштабироваться,
00:03:21если загружать все зависимости без бандлинга.
00:03:24Например, если вы загружаете Lodash-es,
00:03:26а там около 700 файлов.
00:03:28И мы решили: окей,
00:03:30нам нужно что-то для бандлинга зависимостей.
00:03:34Тогда были Rollup, esbuild и Webpack.
00:03:41Webpack не выдает ESM, так что он не подходил.
00:03:47Я посмотрел на Rollup, и он довольно медленный.
00:03:50Очень медленный по сравнению с esbuild, понимаете?
00:03:53Быстрее, чем Webpack, но медленнее, чем esbuild.
00:03:56Поэтому мы использовали esbuild для пре-бандлинга зависимостей,
00:03:59что работает молниеносно.
00:04:00А затем отдавали весь исходный код как «небандлированный» ESM,
00:04:02и это работало отлично.
00:04:04Затем, когда дело дошло до продакшена,
00:04:06мы сначала подумали: окей,
00:04:08давайте просто использовать esbuild для сборки всего проекта
00:04:10для продакшена.
00:04:11И тут мы поняли, что у esbuild очень ограниченный контроль
00:04:14над разделением на чанки (chunk splitting).
00:04:17А это очень распространенная потребность при создании крупных приложений,
00:04:19потому что вы хотите иметь возможность контролировать процесс.
00:04:21Например, я хочу вынести библиотечные зависимости
00:04:24в отдельный «vendor» чанк для лучшего кэширования.
00:04:26Я хочу, чтобы этот чанк никогда не менялся,
00:04:28чтобы у него был постоянный хеш.
00:04:32Чтобы даже если я изменю исходный код,
00:04:33хеш этого чанка оставался прежним.
00:04:35Так пользователи всегда будут получать этот чанк из кэша
00:04:38при посещении сайта.
00:04:39Существует масса подобных оптимизаций,
00:04:41которые esbuild просто не позволяет реализовать.
00:04:44У него есть один алгоритм разделения чанков по умолчанию,
00:04:47и всё.
00:04:49Его система плагинов тоже менее гибкая.
00:04:53Например, если один плагин решил,
00:04:56что он будет обрабатывать этот файл, то на этом всё.
00:04:59Никакие другие плагины больше не могут его трогать.
00:05:02При этом мы много работали с Rollup,
00:05:05мы знакомы с его системой плагинов.
00:05:08В итоге мы решили так:
00:05:10мы будем использовать Rollup для финальной сборки,
00:05:13но esbuild — для пре-бандлинга при разработке.
00:05:15Это была комбинация, в которой каждый инструмент
00:05:20делал то, что у него получается лучше всего.
00:05:23И на самом деле, даже сегодня Vite 6 всё еще основан
00:05:26на этой комбинации.
00:05:27И для многих это работает вполне достойно.
00:05:31Но, очевидно, есть проблемы, потому что esbuild
00:05:35написан на Go, а Rollup — на JavaScript,
00:05:40что означает, что сборка для продакшена
00:05:41всё еще довольно медленная по сравнению, скажем,
00:05:43с бандлерами полностью на Rust, такими как Rspack.
00:05:47А для сервера разработки, из-за того что у esbuild
00:05:52и Rollup разные системы плагинов,
00:05:55мы не можем применить один и тот же набор плагинов
00:05:57к зависимостям во время разработки,
00:05:59хотя они применяются к ним
00:06:01во время финальной сборки.
00:06:03К тому же возникают тонкие нюансы взаимодействия.
00:06:07Например, когда у вас смешанный граф из ESM и CJS,
00:06:10esbuild и Rollup обрабатывают его немного по-разному.
00:06:13Есть различия в поведении tree shaking.
00:06:15Хотя оба инструмента справляются хорошо,
00:06:18и мы пишем «костыли» для всех этих несоответствий
00:06:22и прочего.
00:06:22Мы заставили всё это работать, но в глубине души понимали:
00:06:25это просто две разные вещи, которые мы кое-как
00:06:29слепили вместе.
00:06:31Поэтому, чтобы А — ускорить финальную сборку
00:06:35и Б — сделать сборку в разработке и продакшене более консистентной,
00:06:40лучше всего иметь один бандлер,
00:06:42который делает и то, и другое.
00:06:44Проблема в том, что esbuild быстрый,
00:06:47но он не особо расширяемый.
00:06:50Весь код написан на Go.
00:06:54Эван Уоллес, автор esbuild...
00:06:57Очевидно, он «безумный ученый», он гений,
00:06:59и он сделал esbuild невероятно быстрым,
00:07:02но этот код не слишком подходит для того,
00:07:05чтобы другие люди его расширяли, форкали
00:07:07или поддерживали какой-то слой поверх него.
00:07:10Это нелегко сделать.
00:07:12К тому же очень трудно убедить Эвана Уоллеса
00:07:15делать то, чего он не хочет,
00:07:17потому что деньги ему не нужны и ему всё равно.
00:07:21Тогда мы подумали: окей, а что насчет Rollup?
00:07:27Можем ли мы сделать Rollup быстрее?
00:07:28Были некоторые эксперименты,
00:07:30но фундаментально Rollup написан на JavaScript,
00:07:33а JavaScript — это однопоточность.
00:07:36Мы пробовали воркеры, плагины в воркерах.
00:07:41Мейнтейнер Rollup пытался внедрить парсер на Rust,
00:07:47SWC-парсер, прямо в Rollup.
00:07:50Это не дало заметного прироста производительности,
00:07:54потому что в смешанной системе из Rust и JS” всегда
00:07:57возникают огромные затраты на передачу состояния.
00:07:59Вы гоняете огромные куски строк туда-сюда.
00:08:02А если приходится клонировать память, всё становится еще медленнее.
00:08:05Оказалось, что чистый прирост скорости от Rust,
00:08:09когда у вас только парсер на Rust,
00:08:12а всё остальное на JavaScript,
00:08:13нивелируется ценой передачи данных.
00:08:16В итоге производительность осталась почти той же.
00:08:19Мы поняли, что радикально ускорить Rollup
00:08:23технически невозможно.
00:08:26Единственный вариант — переписать его,
00:08:30создать бандлер, который будет изначально
00:08:33спроектирован специально для Vite и будет молниеносным.
00:08:37Так начались поиски ответа на вопрос:
00:08:40«Что же нам делать?»
00:08:42Мы решили, по сути,
00:08:44изначально была идея форкнуть Rollup на Rust.
00:08:48Не форкнуть, а портировать.
00:08:49Мы хотели перенести Rollup на Rust.
00:08:51Поэтому проект называется Rolldown.
00:08:53Типа Rollup — Rolldown (вверх-вниз).
00:08:54Начинали как прямой порт,
00:08:58но быстро осознали, что код на JavaScript
00:09:02не так-то просто перенести напрямую на Rust,
00:09:06потому что JavaScript очень динамичен.
00:09:08Это динамический язык.
00:09:11Даже если вы используете TypeScript,
00:09:13вы всё равно можете мутировать объекты как угодно.
00:09:16А Rust очень строг с памятью.
00:09:19Строг с жизненными циклами, владением и так далее.
00:09:23Поэтому структуру приходится делать совершенно иной
00:09:25по сравнению с JavaScript.
00:09:27Так что это никогда не было бы просто
00:09:29переносом существующего JS-кода
00:09:31на такой язык, как Rust.
00:09:33По факту это полное переписывание.
00:09:35В итоге мы также
00:09:37захотели взять лучшее от обоих миров.
00:09:42Сам по себе Rollup — это довольно лаконичное ядро.
00:09:45И если вы хотите превратить Rollup
00:09:47в готовый к продакшену инструмент,
00:09:49это требует немалых усилий,
00:09:51потому что вам нужен плагин node-resolve —
00:09:54разрешение путей в node_modules не встроено.
00:09:56Его нужно добавлять как плагин.
00:09:58Нужен плагин CommonJS для поддержки соответствующих модулей,
00:10:03потому что ядро Rollup работает только с ESM.
00:10:06И нужно добавить целую кучу плагинов,
00:10:10таких как define, inject, replace.
00:10:14Многие из этих функций встроены в esbuild,
00:10:17но в Rollup они требуют плагинов.
00:10:20И что хуже всего — большинство этих плагинов в мире JS
00:10:25реализованы как отдельный цикл парсинга AST, трансформации и кодогенерации.
00:10:30То есть каждый плагин фактически делает полный цикл:
00:10:33берет код от предыдущего плагина,
00:10:36снова его парсит, трансформирует,
00:10:38генерирует новый код и новый source map.
00:10:41А потом нужно объединять все эти source map-ы.
00:10:43Вот почему системы сборки на JS становятся всё медленнее:
00:10:46каждый плагин просто повторяет одно и то же по кругу.
00:10:49Мы решили: окей, нам нужно, чтобы это было встроено.
00:10:53В итоге мы получили охват функций как у esbuild,
00:10:56но API как у Rollup — и это и есть Rolldown.
00:11:01Но чтобы создать Rolldown, мы поняли:
00:11:03нам нужен парсер, нужны все трансформации.
00:11:07Нужен минификатор, нужен резолвер.
00:11:10Где всё это взять?
00:11:12И тут на сцену выходит OXC.
00:11:14OXC — это набор низкоуровневых инструментов,
00:11:17который дает вам всё это.
00:11:20Автор OXC тогда работал в ByteDance,
00:11:25и я давно приглядывался к этому проекту.
00:11:28Его зовут Бошинь, он автор OXC,
00:11:30и сейчас он наш вице-президент по инженерии в VoidZero.
00:11:33Он не сразу присоединился к компании после основания.
00:11:36Я пытался его переманить, но он сомневался,
00:11:38типа «не знаю...»
00:11:39Но мы всё равно начали строить Rolldown на базе OXC.
00:11:44Мы решили: «Это отличная штука».
00:11:45Я верил в это,
00:11:47потому что изучил все доступные варианты.
00:11:51Мне нужно было что-то компонуемое.
00:11:54Что-то, где каждая часть инструментария
00:11:57доступна по отдельности в виде крейтов (crates).
00:12:00И чтобы это было экстремально быстро.
00:12:03Мы сравнили OXC и SWC.
00:12:06Парсер OXC в три раза быстрее,
00:12:09чем парсер SWC, хотя оба написаны на Rust,
00:12:12из-за множества архитектурных решений
00:12:15и низкоуровневых технических деталей,
00:12:18которые привели к такой разнице.
00:12:20Главное, что Бошинь был одержим
00:12:24производительностью парсинга и линтинга
00:12:27еще до прихода в компанию.
00:12:30Например,
00:12:32OXC использует так называемый «arena allocator»,
00:12:34который размещает всю память для AST
00:12:39в одном непрерывном блоке.
00:12:41Он просто выделяет большой кусок памяти
00:12:43и сразу кладет туда AST.
00:12:45Так память освобождается гораздо быстрее.
00:12:50Это также открыло интересные возможности,
00:12:53которые позволили сделать быстрыми JS-плагины в OX Lint,
00:12:57потому что такая структура памяти позволяет нам
00:12:59передавать весь блок данных в JavaScript
00:13:01без клонирования, а затем десериализовать на стороне JS.
00:13:05Преимуществ масса.
00:13:06Когда я тогда смотрел на проект,
00:13:10был под большим впечатлением,
00:13:10и мы решили строить Rolldown на нем,
00:13:13а в итоге и убедили Бошиня присоединиться.
00:13:16Так что теперь сфера деятельности компании, по сути, такова:
00:13:21у нас есть вертикальный стек на Rust,
00:13:24который начинается с самого парсера.
00:13:26Он покрывает всё вплоть до бандлинга в Vite,
00:13:29а сверху — линтер, форматтер, тест-раннер.
00:13:33Целая экосистема инструментов.
00:13:34И наш следующий шаг,
00:13:37над которым мы работаем уже некоторое время,” —
00:13:40это объединить всё это в единый пакет,
00:13:43чтобы вам не нужно было устанавливать пять разных штук,
00:13:47просто чтобы запустить базовое приложение.
00:13:50Вам также не понадобится
00:13:51шесть или семь разных конфигурационных файлов.
00:13:55Мы просто собираем всё в одном конфиге,
00:13:57и гарантируем, что всё это будет работать слаженно,
00:13:59потому что в основе лежит один и тот же парсер,
00:14:02один пайплайн трансформации и один резолвер.
00:14:05Никаких сюрпризов.
00:14:07Например, если вы используете Webpack и Jest,
00:14:10вам приходится настраивать логику резолвинга отдельно,
00:14:14потому что они используют разные механизмы.
00:14:16Так что наше видение таково:
00:14:19«Давайте создадим вертикальный стек,
00:14:22который будет работать стабильно везде».
00:14:25Сделать процесс разработки максимально простым
00:14:29и быстрым.
00:14:30Производительность — это ключевой момент.
00:14:32Я привык воспринимать это как должное,
00:14:34но вы наверняка видели твиты о том, что Rolldown
00:14:39в 20 раз быстрее, чем Rollup.
00:14:43OX Lint в 50–100 раз быстрее, чем ESLint.
00:14:47OX Format в 30–40 раз быстрее, чем Prettier.
00:14:51Наша цель — сделать всё это совместимым,
00:14:57чтобы вы могли перейти без масштабного рефакторинга,
00:15:00просто получив огромный прирост скорости.
00:15:04Теперь ваш цикл тестов, проверки линтером
00:15:08и всё остальное будет намного быстрее и плавнее.
00:15:12И это позволит людям
00:15:15создавать больше приложений быстрее.
00:15:17— Знаете, мне нравится, как быстро всё это разрослось:
00:15:20от «нам нужен инструмент сборки для Vue» до
00:15:22«хочу улучшить вот эту часть, а теперь и вот ту».
00:15:24И теперь, как вы сказали, вы действительно владеете
00:15:25всем вертикальным стеком.
00:15:27Это впечатляет, и это действительно очень быстро.
00:15:29Я рассказывал ребятам перед началом,
00:15:32что на одной из моих прошлых работ
00:15:33мы начинали старый проект,
00:15:35и там был Webpack, который собирался по 50 минут.
00:15:37Понятия не имею, что там происходило,
00:15:40но первое, что я им сказал:
00:15:42«Нам нужно немедленно перейти на Vite».
00:15:43Потому что при изменении CSS
00:15:46приходилось ждать минуты две,
00:15:47пока всё пересоберется.
00:15:49Я подумал: «Это никуда не годится».
00:15:49Нам нужен Hot Module Replacement.
00:15:52Когда я сохраняю файл, изменения должны появляться сразу.
00:15:54Vite определенно с этим помог.
00:15:57Думаю, прогресс и темпы,
00:15:59с которыми Vite взлетел, просто поражают.
00:16:02Я видел цифру в 200 миллионов скачиваний из NPM
00:16:05в месяц или что-то в этом роде.
00:16:07Это...
00:16:09— Да, мы недавно преодолели отметку в 50 миллионов в неделю.
00:16:10— Это просто уму непостижимо.
00:16:13— Я как раз думал об этих 50 миллионах.
00:16:15Там наверняка есть доля инфляции
00:16:19от приложений, написанных с помощью ИИ.
00:16:21Всякие наспех сделанные одноразовые поделки.
00:16:23Тем не менее, это показывает, что много людей,
00:16:26или, вероятно, ИИ-агентов, используют его.
00:16:29— Я как раз хотел сказать, что команда инженеров
00:16:33в BetterStack — огромные фанаты Vue.
00:16:34У них Rails на бэкенде и Vue на фронтенде.
00:16:36У них есть вопросы, которые я буду задавать
00:16:40по ходу подкаста.
00:16:42Но вы упомянули бандлинг,
00:16:46и один из их вопросов был таким:
00:16:48раз в Rails используются import maps,
00:16:49каким вы видите будущее бандлинга?
00:16:52Ведь если есть import maps,
00:16:54то особо ничего и не нужно бандлить.
00:16:56Так куда всё движется?
00:16:57— У меня на самом деле есть отдельная страница
00:17:00в документации Rolldown,
00:17:02которая так и называется:
00:17:04«Зачем нам всё еще нужны бандлеры?»
00:17:07— Вас часто об этом спрашивают?
00:17:10— Да, к тому же DHH очень активно
00:17:13продвигает идею «без бандлинга и без сборки».
00:17:16Так что к этому приходится прислушиваться.
00:17:18Import maps работают до определенной степени,
00:17:20но отсутствие бандлинга в целом — это концепция,
00:17:24которая жизнеспособна только до определенного масштаба.
00:17:29Если в вашем приложении меньше тысячи модулей,
00:17:35весь граф модулей, скорее всего, загрузится
00:17:39за пару сотен миллисекунд,
00:17:41и это вполне приемлемо.
00:17:43И если вы знаете, что работаете в этих рамках,
00:17:45то это на самом деле здорово.
00:17:48Всё лениво по умолчанию,
00:17:50а значит, если у вас большое приложение,
00:17:53где каждая страница изолирована,
00:17:56и у вас есть этот под-граф модулей,
00:17:58всё работает прилично.
00:18:00Поэтому Vite хорошо справляется в разработке.
00:18:01Но это не панацея,
00:18:05потому что мы заметили на примере самого Vite,
00:18:07и именно поэтому мы работаем над
00:18:09полным режимом бандлинга в Rolldown,
00:18:12что у режима без бандлинга есть свои ограничения.
00:18:15Узкое место — это именно количество модулей.
00:18:18Существует масса приложений,
00:18:21которые загружают тысячи и тысячи модулей
00:18:25во время разработки.
00:18:29Вы можете загружать, скажем, 3000 модулей,
00:18:32и это просто «задушит» ваш браузер.
00:18:33Проблема на сетевом уровне,
00:18:36потому что с нативным ESM
00:18:38вы отправляете HTTP-запрос для каждого отдельного модуля.
00:18:40И если у вас глубокий граф импортов,
00:18:44браузеру нужно сначала получить первый модуль,
00:18:46понять: «Окей, мне нужны вот эти дополнительные модули»,
00:18:49и пойти за ними.
00:18:52А потом еще за следующими.
00:18:53Вам нужно жадно обойти весь граф,
00:18:54прежде чем вы сможете выполнить первый импортирующий модуль.
00:18:57При плохом соединении
00:19:00вы рискуете получить множество сетевых задержек,
00:19:04прежде чем отрисуется хоть что-то.
00:19:06А если модулей тысячи,
00:19:09сетевой фактор просто умножает проблему.
00:19:13Даже при локальной разработке на сервере Vite,
00:19:17если у вас более 3000 модулей,
00:19:20локальная загрузка может занять секунду-две.
00:19:23Представьте, что будет в продакшене
00:19:27через интернет.
00:19:29Вам это не нужно, потому что с бандлингом
00:19:31загрузка займет миллисекунд сто.
00:19:35Это та самая «бесплатная» оптимизация,
00:19:38которую всегда стоит использовать,
00:19:40как только вы переходите определенный порог.
00:19:41Мне кажется, главный аргумент против бандлинга
00:19:45и инструментов сборки в целом — люди просто устали
00:19:47их настраивать.
00:19:52Они натыкались на баги,
00:19:55на проблемы с конфигурацией, которые не могли решить.
00:19:56И поскольку Webpack сделал всё это слишком сложным,
00:20:01многие теперь думают:
00:20:04«Настройка бандлера — это не для меня, я не хочу этим заниматься».
00:20:06У людей появилось своего рода отвращение:
00:20:08когда они слышат про «этап сборки»,
00:20:11они сразу: «Это плохо, я хочу этого избежать».
00:20:14Поэтому мы в своих
00:20:16инструментах хотим сделать так:
00:20:19максимально упростить эти концепции.
00:20:22Для больших сложных приложений просто не будет никогда,
00:20:24это понятно.
00:20:28Но мы хотим, чтобы для нового проекта всё было настолько просто,
00:20:32чтобы вам не приходилось об этом думать,
00:20:34если ваше приложение не сверхсложное.
00:20:37Вы просто запускаете проект,
00:20:41он использует Vite, и вы знаете, что всё будет отлично.
00:20:45Кстати, есть проект сообщества,
00:20:48кажется, Ruby Vite или Vite Rails,
00:20:50который позволяет Vite прекрасно работать в Rails.
00:20:55У подхода «без сборки» есть свои плюсы.
00:20:59Он дает чувство комфорта, потому что вы знаете:
00:21:05вы избегаете кучи зависимостей
00:21:12и неопределенностей, из-за которых что-то может сломаться.
00:21:14Думаю, у некоторых людей потеря доверия к системам сборки вызвана тем,
00:21:17что всегда что-то идет не так.
00:21:20Сборка ломается при обновлении зависимости —
00:21:23и они хотят этого избежать, что заманчиво.
00:21:26Но в конечном счете,
00:21:29если технология достаточно хороша и стабильна,
00:21:33вы всегда хотите дать лучший UX своим пользователям.
00:21:36А полный отказ от бандлинга загоняет вас
00:21:37в очень жесткие рамки размера приложения.
00:21:41Вам всё равно придется думать об оптимизации,
00:21:45потому что придется следить:
00:21:48«Не импортирую ли я случайно лишнего
00:21:52на этой конкретной странице?»
00:21:54«Как мне грамотно кэшировать модули?»
00:21:57Я полагаю, даже в Rails без бандлинга
00:22:01всё равно нужен какой-то препроцессинг,
00:22:03чтобы проставить штампы версиям модулей для кэширования.
00:22:06Так что неизбежно придется уделять внимание
00:22:08оптимизации, чтобы всё работало.
00:22:11Скажем так: это определенно подходит для
00:22:15внушительного числа случаев, но это не то,
00:22:18что покроет абсолютно все потребности.
00:22:21Некоторые люди строят действительно огромные приложения
00:22:24с кучей функционала.
00:22:29И нельзя просто заставить их отказаться от бандлинга
00:22:31и тем самым запереть их в этой
00:22:35неуправляемой по производительности ситуации.
00:22:37— Для тех, кто не особо знаком с этим,
00:22:39в чем отличие Vite от Vite+?
00:22:42И что именно люди от этого получат?
00:22:45— С Vite+ мы сейчас проходим через небольшой
00:22:49«мини-пивот» в плане того, чем он должен быть.
00:22:54Идея в следующем: если вы только начинаете
00:22:57свой путь в JavaScript-разработке с нуля,
00:23:02вы новичок,
00:23:06у вас «чистая» машина, на которой ничего не установлено...
00:23:11Как пройти путь от нуля до работающего приложения
00:23:14с HMR, всеми лучшими практиками,
00:23:17настроенным линтингом, форматированием и тестами?
00:23:21Сейчас для этого нужно очень многому научиться.
00:23:25Первое, что вам нужно узнать: «Что такое Node.js?»
00:23:28«Как её установить?»
00:23:33«Что такое менеджер версий Node?»
00:23:36«Какой пакетный менеджер использовать?»
00:23:38«Какой сборщик выбрать?»
00:23:39«Какой линтер?»
00:23:40Вам приходится отвечать на все эти вопросы.
00:23:42Мы хотим убрать эти вопросы.
00:23:44Мы даем вам эту «мнение-ориентированную» стартовую точку,
00:23:45где вам,
00:23:47возможно, даже не придется устанавливать Node.js.
00:23:49Мы экспериментируем с новым способом
00:23:50работы в Vite+: просто curl...
00:23:52типа `curl https://vplus.dev/install | bash`.
00:23:54И затем `vp new`, и у вас новый проект,
00:23:57затем `vp dev` — и у вас
00:23:59полный набор уже настроенных инструментов.
00:24:03У вас есть линтер, форматтер,
00:24:08тест-раннер, бандлер; вы также можете использовать это,
00:24:15чтобы развернуть монорепозиторий.
00:24:17Есть бандлинг библиотек.
00:24:21Мы планируем добавить встроенные штуки вроде lint-staged,
00:24:25управление ченджлогом.
00:24:28Если у вас огромный монорепозиторий с библиотеками,
00:24:31также есть команда `vp run` —
00:24:32это раннер, похожий на `pnpm run`,
00:24:39но более продвинутый,
00:24:41вроде Nx, который может сам определить
00:24:44правильный порядок выполнения задач
00:24:49и грамотно их кэшировать.
00:24:52Но это опционально.
00:24:57То есть это целый комплекс, где,
00:24:59если вам не нужны все эти навороты,
00:25:03вы можете использовать его просто как обычный Vite.
00:25:04Опыт разработки будет точно таким же,
00:25:07как в сегодняшнем Vite.
00:25:11Но если вы захотите расти дальше,
00:25:13вплоть до монорепозитория корпоративного уровня,
00:25:17готового к продакшену, — инструмент поддержит вас на всём пути.
00:25:18К тому же он построен на
00:25:20проверенных технологиях,
00:25:24которые люди уже используют в подобных ситуациях.
00:25:27Вот что мы надеемся предложить.
00:25:31Мы переводим множество существующих пользователей
00:25:33на наши open-source решения:
00:25:35люди переходят с Webpack на Vite,
00:25:39с ESLint на OX Lint.
00:25:44И мы надеемся, что Vite+ станет ответом на вопрос:
00:25:47«Что мне делать,
00:25:48если я только начинаю учить JavaScript?»
00:25:52«Какой самый быстрый и простой способ начать?»
00:25:54Я хочу дать ответ на этот вопрос,
00:25:57а также сделать так, чтобы всё это отлично работало с ИИ.
00:26:00— А какова тогда цель компании?
00:26:02Многие пугаются, когда слышат,
00:26:05что за open-source проектами стоит коммерческая компания,
00:26:07потому что вы можете начать прятать функции за пейволлом.
00:26:11Но ваша цель, как я понял,
00:26:14в том, что пользователь всегда может сделать то же самое сам.
00:26:15Просто это потребует долгой настройки,
00:26:17а Vite+ — это просто удобство,
00:26:20где всё упаковано воедино, как вы и сказали.
00:26:23То есть вы никогда не сделаете функцию платной?
00:26:25— Да, мы уже закидывали удочку
00:26:26по поводу лицензирования Vite+.
00:26:29Мы говорили: «Окей, если ваша компания
00:26:31превышает определенный порог прибыли, вы должны платить».
00:26:34Эти мысли сейчас эволюционируют,
00:26:37потому что мы общаемся со многими заинтересованными компаниями
00:26:39и пытаемся найти правильный баланс:
00:26:41дать инструмент в руки как можно большему числу людей
00:26:44и приносить пользу, позволяя нам при этом монетизировать часть этой ценности
00:26:46и быть устойчивыми.
00:26:50Думаю, мы значительно поднимем этот порог.
00:26:53Так что платить придется только очень узкой категории компаний.
00:26:56Подавляющее большинство пользователей смогут наслаждаться им
00:27:00бесплатно. К тому же
00:27:02мы работаем над идеями, которые больше похожи на сервис,
00:27:07а не на простую продажу функций.
00:27:11Сервис, который работает в связке с Vite+,
00:27:14который как бы повышает качество кода,
00:27:17мониторит его
00:27:20и подкидывает идеи или советы,” —
00:27:25помогает вам улучшать те или иные вещи.
00:27:27Существует масса экспертных знаний,
00:27:31которые мы теперь можем масштабировать через ИИ-агентов.
00:27:35Это то направление, которое мы сейчас исследуем.
00:27:37— Понятно. Мне вот еще интересно:
00:27:39раз Vite+ делает всё удобным,
00:27:41как вы думаете, может ли ИИ делать то же самое с текущими решениями?
00:27:44Был ли у вас опыт,
00:27:48когда вы просили ИИ собрать воедино структуру
00:27:51линтера, сборки и всего остального?
00:27:53Не кажется ли вам, что А — ИИ будет полагаться на старые технологии
00:27:56из-за своих обучающих данных и натворит дел?
00:28:00— Мы видим много приложений, созданных ИИ,
00:28:02которые всё еще используют, скажем, Vite 5.
00:28:05Большая проблема в том, что когда мы выпускаем новую версию,
00:28:07когда добавляем фичи, моделям нужно время,
00:28:09чтобы обучиться на этих данных.
00:28:13Модели всегда будут отставать от последних новостей
00:28:17и технологий. И одна из вещей, которую мы хотим сделать,” —
00:28:20это, например, при выпуске новой версии Vite+
00:28:26сразу давать...
00:28:29Во-первых, он будет идти со своими правилами для агентов (agent rules) и навыками.
00:28:31Когда вы обновляете Vite+,
00:28:34он сам подправит соответствующие части в правилах вашего агента
00:28:37и обновит ссылки на навыки,
00:28:41которые изменились в NPM-пакете.
00:28:44И еще,
00:28:47мы можем давать вам промпт, который просто скажет:
00:28:50«Если вы хотите обновиться с этой версии на эту,
00:28:54этот промпт поможет вашему агенту сделать это гладко».
00:28:58Многое из этого должно исходить
00:29:00именно от авторов инструментов.
00:29:05Потому что — и мы это заметили —
00:29:08наши OX Lint, OX Format и Vitest
00:29:10используются в OpenClaude (OpenClaw), верно?
00:29:13А OpenClaude — это безумная кодовая база.
00:29:17Там около 54 000 строк на JavaScript,
00:29:19и она растет с сумасшедшей скоростью.
00:29:22Автор просто мержит всё подряд, даже не читая.
00:29:26И там
00:29:29очень много вещей,
00:29:31которые просто лишены смысла.
00:29:34Мы смотрим на некоторые PR, которые обновляют OX Lint
00:29:36или пытаются его внедрить.
00:29:40Там просто галлюцинируют опции, которых нет.
00:29:43Мы такие: «Стоп, у нас нет такой опции,
00:29:45нам придется...»
00:29:46И когда ИИ делает проверку типов,
00:29:51он просто «чинит» её:
00:29:54«Окей, я просто выключу это правило,
00:29:57чтобы типы сошлись».
00:29:59То есть ИИ будет идти по пути наименьшего сопротивления,
00:30:00если не ставить ему рамки.
00:30:04И что более важно: Питер,
00:30:06автор OpenClaude,
00:30:07он не TypeScript-разработчик.
00:30:09Он просто выбрал TypeScript для работы.
00:30:12Он не эксперт в инструментарии.
00:30:15Он не профи в этой области.
00:30:18ИИ помог ему всё сделать.
00:30:20Но мы, как авторы инструментов, которые использует этот ИИ,
00:30:22видим, где он пасует.
00:30:25И мы понимаем: если продолжать в том же духе
00:30:26без наших подсказок,
00:30:29ваш код развалится через три месяца.
00:30:30В этом и заключается ценность,
00:30:35которую, как мы думаем, мы можем дать в эпоху ИИ:
00:30:38как убедиться, что вы выпускаете продукт быстро,
00:30:41но при этом ничего не ломаете?
00:30:44Как продолжать быстро пилить фичи с ИИ?” —
00:30:46потому что скорость написания кода
00:30:50растет колоссально благодаря агентам.
00:30:54Люди могут выпускать фичи гораздо быстрее, чем раньше.
00:30:58Но проходят ли эти фичи должный обзор?
00:30:59Когда вы мержите по 20 PR в день,
00:31:03остается ли кодовая база
00:31:06в нормальном, поддерживаемом состоянии?
00:31:11Здоровье кода становится очень нестабильным.
00:31:14Так что время от времени приходится делать то же,
00:31:19что мы делаем при обычной разработке людьми:
00:31:22вы какое-то время пилите фичи,
00:31:25а потом должны остановиться и подумать:
00:31:26«Так, надо прибраться».
00:31:30«Нужно отдать накопившийся техдолг».
00:31:33С ИИ-агентами мы пилим код быстрее,
00:31:36но и техдолг копится быстрее, понимаете?
00:31:37Значит, нужно использовать ИИ и для погашения этого долга.
00:31:38Мне кажется, это та часть,
00:31:40которую люди сейчас упускают из виду
00:31:42и которая остро нуждается в решении.
00:31:45— Да, я взглянул на код OpenClaude,” —
00:31:49как вы и сказали, там царит хаос.
00:31:53Это определенно отличный пример того, что бывает,
00:31:56когда вы даете ИИ полную свободу
00:31:57и позволяете ему делать всё что угодно
00:32:00без какого-либо надзора.” последние
00:32:03пару недель в интернете было забавно наблюдать
00:32:05за этим хайпом и всем тем, что ИИ там натворил.
00:32:07Но я хотел еще спросить про роль ИИ:
00:32:09меняете ли вы способ создания форматтера
00:32:11и линтера, чтобы ИИ-агентам было удобнее ими пользоваться?
00:32:13Это как-то формирует будущее,
00:32:16или вы считаете, что сам факт того, что вы делали
00:32:19форматтеры и линтеры быстрыми, уже помог в эпоху ИИ?
00:32:22Очевидно, раз они быстрые, агенты могут их эффективно использовать.
00:32:26— Это определенно правильное направление мысли,
00:32:29потому что мы начинаем задумываться об этой проблеме.
00:32:31Изначальный объем работ по этим линтерам
00:32:34и форматтерам просто колоссальный,
00:32:38ведь мы пытаемся быть совместимыми
00:32:40с ESLint и Prettier,” —
00:32:45инструментами, которые в строю уже десятилетие,
00:32:48под которые люди написали горы кастомных правил
00:32:50и легаси-кейсов,
00:32:53а мы стремимся к 100% совместимости.
00:32:54Это титанический труд,
00:32:56но мы наконец-то этого достигли — недавно мы вышли
00:33:00на 100% совместимость с плагинами ESLint.
00:33:03Мы прошли все тесты плагинов ESLint
00:33:06и достигли 100% соответствия (conformance)
00:33:09между Prettier и нашим форматтером.
00:33:13Эти две вехи означают, что теперь
00:33:17мы можем уверенно рекомендовать людям
00:33:21переходить на наши инструменты. А что дальше?
00:33:23Как раз это отличный вопрос.
00:33:25Как должны линтинг и форматирование...
00:33:28как им адаптироваться под работу агентов?
00:33:31Мы сейчас активно над этим работаем.
00:33:34Да.
00:33:38— В общем, ждем ответа на этот вопрос.
00:33:40Всё еще в процессе, да.
00:33:44ИИ определенно меняет многое
00:33:49в мире программирования, так что за этим интересно наблюдать.
00:33:53— Возвращаясь к теме Vite+:
00:33:54вы анонсировали его на ViteConf 2024,
00:33:57и показали функцию `vp install`.
00:33:59Мой вопрос: эта фича всё еще в планах?
00:34:01И насколько сильно Vite+ будет пересекаться
00:34:04с чем-то вроде Bun?
00:34:06— Хороший вопрос.
00:34:10С момента ViteConf кое-что изменилось.
00:34:14Я бы сказал, что финальная,
00:34:17финальная публичная версия Vite+ будет,
00:34:19по ощущениям, чем-то похожа на Bun в некотором смысле.
00:34:21В плане онбординга, как я и говорил:
00:34:23у вас чистая система,
00:34:27и вы такие: «Хочу начать делать веб-приложение
00:34:30как можно скорее».
00:34:33Вы просто запускаете скрипт через curl,
00:34:38получаете глобальный бинарник под названием `vp` и всё.
00:34:41Когда вы находитесь внутри проекта,
00:34:43если у вас есть файл `.node-version`
00:34:45и поле `packageManager` в `package.json` —
00:34:46стандартные вещи, которыми мы описываем окружение,” —
00:34:51вашу JS-среду...
00:34:56В Vite+, когда вы пишете `vp run build`,
00:35:02он автоматически использует...
00:35:04даже если вы просто пишете `vp build` или `vp lint`,
00:35:06любое действие, требующее запуска JavaScript,
00:35:11он сам подберет нужную версию Node
00:35:15и нужный пакетный менеджер за вас.
00:35:20Так что с Vite+...
00:35:22на самом деле, даже если вы не используете Vite+ в этом проекте,
00:35:26но используете
00:35:28эти стандартные описания окружения,
00:35:31вы можете использовать Vite+ как замену nvm.
00:35:36Можете заменить им Corepack.
00:35:40Вы просто перестаете думать о версиях.
00:35:44Идея в том, что когда вы запускаете свой рабочий процесс,
00:35:45вы делаете это через него. Вы перестаете писать `npm run`.
00:35:48Вы используете `vp run`.
00:35:52Идея такая: когда вы делаете `vp run`,
00:35:55он сам использует нужную версию Node,
00:35:59сам выберет нужную версию пакетного менеджера
00:36:02и сделает всё как надо.
00:36:05А `install` означает, что он просто...
00:36:06у нас пока нет своего пакетного менеджера, да?
00:36:10Так что это скорее эквивалент Corepack.
00:36:14Не знаю, пользовались ли вы пакетом `ni`,
00:36:16который сделал Энтони Фу.
00:36:19Смысл `ni` в том, что когда вы его запускаете,
00:36:24он сам понимает, какой пакетный менеджер нужно дернуть,” —
00:36:27запуск ли это, установка или удаление,
00:36:30что угодно.
00:36:34`vp install` — это, по сути, то же самое,
00:36:36но с управлением самими пакетными менеджерами.
00:36:41Как раз то, что делает Corepack.
00:36:45Даже если у вас вообще ничего не установлено,
00:36:48вы заходите в проект, а в `package.json` написано:
00:36:49«пакетный менеджер pnpm»
00:36:51конкретной версии.
00:36:56Вы запускаете `vp install`, он сам проверит,
00:36:58установлена ли эта версия pnpm.
00:37:01Если нет — он сам её скачает
00:37:03 и запустит процесс установки через `pnpm install`.
00:37:07В общем, мы хотим
00:37:08решать не только проблемы линтинга и форматирования.
00:37:12А вообще все типичные задачи,
00:37:14с которыми вы сталкиваетесь в JS-разработке.
00:37:16Мы хотим убрать эти вечные затыки, чтобы
00:37:20новичку даже не приходилось о них думать.
00:37:25Когда вы впервые разворачиваете проект,
00:37:31мы поставим последнюю LTS-версию Node и посоветуем pnpm.
00:37:34И запишем эту информацию в конфиг проекта.
00:37:36Чтобы в следующий раз, когда вы вернетесь в этот проект,
00:37:40он всегда использовал правильную комбинацию инструментов.
00:37:43— А почему вы рекомендуете именно pnpm, если не секрет?
00:37:45— В нем просто лучший баланс возможностей,
00:37:50корректности работы, эффективности использования диска, скорости
00:37:53и отличной поддержки воркспейсов (например, функция catalog).
00:37:55Знаете, когда мы
00:37:59сравнивали функции воркспейсов у всех менеджеров,
00:38:02мы пришли к выводу, что pnpm всё еще дает лучший баланс.
00:38:06Мы знаем, что Bun безумно быстрый,
00:38:10но pnpm достаточно быстр для большинства из нас.
00:38:15И к тому же мы не исключаем возможности
00:38:19поддержки Bun в нашем рантайме
00:38:21и в управлении версиями пакетных менеджеров.
00:38:25Вы сможете сказать: «Я хочу использовать Bun»,
00:38:29и мы будем запускать всё через него.
00:38:33— По поводу Vite 6: вы вроде говорили, что релиз
00:38:35планируется после Китайского Нового года, так?
00:38:37— Да.
00:38:40— На каких вещах в бета-версии
00:38:42вы сейчас сосредоточены перед финальным релизом?
00:38:44— Исключительно на стабильности.
00:38:49Ecosystem CI —
00:38:52у нас огромная система непрерывной интеграции для экосистемы,
00:38:54где мы гоняем Vite 6 на всех зависимых проектах.
00:38:58Недавно мы добились того, что
00:39:00все тесты SvelteKit теперь проходят на Vite 6.
00:39:04Для нас это большое достижение,
00:39:06потому что стабильность — это самое важное.
00:39:10Посудите сами:
00:39:15мы заменяем два проверенных бандлера
00:39:17на новый, который мы написали с чистого листа.
00:39:21Это как менять двигатели у летящего самолета
00:39:24в надежде, что он продолжит полет без тряски.
00:39:27Тут нужно быть предельно осторожными.
00:39:28— Я хотел спросить раньше: почему именно Rust?
00:39:30Это потому что люди в вашей команде
00:39:33уже знали этот язык?
00:39:36Я вижу, что многие в мире TypeScript
00:39:40предпочитают Go, потому что на него проще «перекатиться»,
00:39:43и даже команда TypeScript переходит на Go
00:39:46для своего компилятора.
00:39:48— Да, я думаю, выбор команды TypeScript
00:39:49в пользу Go обусловлен тем, как я и сказал,
00:39:51что на Go гораздо проще портировать TypeScript.
00:39:55Ментальная модель языков гораздо ближе.
00:39:57Для нас же одним из главных препятствий
00:39:58стало то, что у Go довольно слабая поддержка WebAssembly.
00:40:02Он выдает огромные бинарники WebAssembly,
00:40:04и их производительность
00:40:09не так хороша по сравнению с Rust.
00:40:13А что касается Rust...
00:40:17да, многое зависит от доступных талантов,” —
00:40:21людей, которые уже горят этим
00:40:26и вложили силы в эту экосистему.
00:40:29Например, когда мы искали,” —
00:40:32на каком фундаменте строить,” —
00:40:35мы не нашли ни одного парсера или набора инструментов,
00:40:39который был бы так же хорошо реализован и так же компонуем.
00:40:41OXC изначально создан для того, чтобы строить поверх него.
00:40:44Это набор низкоуровневых утилит.
00:40:46В мире Go мы ничего подобного не видели.
00:40:48У esbuild есть свой парсер и прочее,
00:40:54но это большая монолитная система.
00:40:59Вы не можете просто вытащить оттуда парсер и как-то его использовать.
00:41:04К тому же все функции в esbuild —
00:41:08define, inject, трансформации, минификация...
00:41:11Для достижения лучшей производительности
00:41:14они реализованы за три прохода по AST,
00:41:18что означает, что в рамках одного прохода
00:41:23у вас смешаны разные задачи:
00:41:25тут мы делаем трансформацию,
00:41:30тут внедряем инъекцию,
00:41:33а тут что-то модифицируем.
00:41:36Это не идеально для расширяемой системы,
00:41:37где, например,
00:41:39мы хотим дать возможность добавлять больше трансформаций
00:41:41и позволять людям их включать и выключать.
00:41:42Мы хотим, чтобы люди могли писать свои трансформации.
00:41:45Нужна система линтинга, которая
00:41:51была бы четко разделена на слои,
00:41:54чтобы над ней могло работать много людей одновременно.
00:41:57В общем, мы исходили из того, что было доступно.
00:42:01Rust к тому же очень производительный.
00:42:03Правда, на нем довольно муторно писать хорошие трансформации.
00:42:07Нам пришлось потратить немало времени,
00:42:09чтобы выстроить правильную архитектуру
00:42:13для визиторов (visitors) и пайплайна трансформаций,
00:42:16из-за проблем с владением памятью:
00:42:22когда вы спускаетесь глубоко в дерево
00:42:26и вам нужно изменить родительское дерево,
00:42:28всё становится очень непросто, понимаете?
00:42:31Но мы нашли решение.
00:42:34В Go это гораздо проще, но если подумать,
00:42:37мы хотим, чтобы наши наработки могли компилироваться
00:42:39в WebAssembly и работать в браузере.
00:42:42Так, Rolldown способен работать в браузере
00:42:44и работать весьма быстро.
00:42:45Впрочем, esbuild тоже может работать в браузере,
00:42:49но WebAssembly на Rust просто лучше.
00:42:51— Еще один вопрос,
00:42:53касающийся команды и Rust:
00:42:57как команда и вы лично используете ИИ?
00:42:59Вы упоминали, что многие в команде
00:43:01используют ИИ.
00:43:05Вы находите ИИ эффективным в вашей работе?
00:43:07Мне кажется, что в обычном вебе — создании сайтов —
00:43:09на GitHub полно примеров,
00:43:12поэтому ИИ обучен отлично.
00:43:14Но то, что делаете вы, — это гораздо более низкий уровень
00:43:16или, по крайней мере, очень высокий уровень технической сложности.
00:43:19Помогает ли ИИ там, или вы всё еще
00:43:21пишете код в основном вручную?
00:43:23— Он определенно помогает.
00:43:25Дело в том, что всё меняется очень быстро.
00:43:28В это же время в прошлом году я был скептиком.
00:43:30Я думал: «Ну, я попробовал, мне это не подходит,
00:43:32потому что я работаю на слишком низком уровне».
00:43:34Но Бошинь, который ведет проект OXC,” —
00:43:38он, пожалуй, самый ярый сторонник ИИ
00:43:41в нашей компании на данный момент.
00:43:45Он начал проводить совершенно безумные эксперименты.
00:43:49Кажется, в прошлом месяце была неделя,
00:43:52когда он выкатил 60 PR с помощью ИИ,
00:43:59просто запуская агентов параллельно.
00:44:03И тогда мы начали эти безумные штуки,
00:44:04вроде переноса компилятора Angular на Rust —
00:44:07просто скормили его ИИ и посмотрели, получится ли.
00:44:11И каким-то образом это работает.
00:44:13Так что, возможно, в будущем у нас появится что-то в этом духе.
00:44:16Да, в общем, мы постоянно обновляем
00:44:19наше представление о возможностях ИИ,
00:44:24буквально каждые несколько месяцев,
00:44:27с выходом новых моделей,
00:44:29с появлением лучших инструментов управления
00:44:33и новых практик, вроде использования «режима планирования»
00:44:39или прописывания правил для агентов.
00:44:43Когда начинаешь применять все эти маленькие хитрости, понимаешь:
00:44:46оно действительно становится всё лучше и лучше.
00:44:48Хотя степень внедрения у всех разная.
00:44:51Мы поощряем каждого в компании
00:44:55использовать ИИ в той мере, в какой они считают нужным.
00:45:00Мы даем им ежемесячный бюджет,
00:45:03чтобы они могли использовать Claude 3.7 или o3, если захотят.
00:45:06Некоторые от этого в полном восторге
00:45:08и открыто об этом говорят.
00:45:13И, очевидно, они выдают отличные PR.
00:45:18Многое зависит от того, насколько умело вы им пользуетесь.
00:45:22Частично это возможности самой модели,
00:45:24частично — инструментарий,
00:45:27но этот слой инструментов
00:45:33сейчас напоминает JavaScript-фреймворки в былые времена.
00:45:36Все делают свою версию одного и того же.
00:45:40Более-менее одно и то же.
00:45:45У кого-то пара фишек в рукаве,
00:45:49но через пару месяцев это будет у всех, понимаете?
00:45:52Это очень конкурентная среда, и с моделями так же.
00:45:54Каждые несколько месяцев...
00:45:57вот сейчас должен выйти Sonnet 3.7.
00:46:00Кажется, DeepSeek готовит новую модель.
00:46:03Всё будет становиться только лучше.
00:46:08Очевидно, что ИИ невероятно способен
00:46:11при правильном управлении,
00:46:13но этот момент «руления» всё еще критически важен.
00:46:17Нельзя ожидать, что человек с нулевым знанием Rust
00:46:18сможет работать в кодовой базе OXC даже с ИИ.” он
00:46:21даже промпт составить не сможет, понимаете?
00:46:23Но тот, кто уже хорошо ориентируется в OXC
00:46:26как Rust-инженер, с помощью ИИ
00:46:32становится на порядок эффективнее
00:46:34и может выдавать больше фич быстрее.
00:46:37Вот моё общее мнение на этот счет.
00:46:41Лично я, пожалуй, тот человек,
00:46:45который пишет с помощью ИИ совсем мало кода,” —
00:46:50минимум по сравнению с другими инженерами в компании.
00:46:54Я использую его больше для исследований и как собеседника для брейнсторминга.
00:46:58— Да, мир программирования
00:47:00становится по-настоящему странным.
00:47:03Мне самому трудно уследить за тем,
00:47:08сколько этих субагентов нужно использовать,
00:47:13параллельных агентов, какие markdown-файлы
00:47:16теперь полагается иметь в репозитории.
00:47:20Всё меняется постоянно.
00:47:25Любопытно, к чему мы в итоге придем.
00:47:27— Если вернуться к Vite на минутку...
00:47:29В Vite 5 вы добавили поддержку серверных компонентов React (RSC).
00:47:32На мой взгляд, RSC
00:47:34не стали тем безоговорочным хитом, на который рассчитывала команда.
00:47:37Я имею в виду, есть такие мета-фреймворки, которые их не приняли,
00:47:38например, TanStack.
00:47:40А Remix и вовсе пошел своим путем.
00:47:43Что вы думаете о серверных компонентах React
00:47:43и почему они, по-вашему, не «взлетели» так, как должны были?
00:47:47— Я всегда относился к этому очень консервативно
00:47:52и был скептиком с самого первого дня.
00:47:54Поэтому мы даже не рассматривали внедрение
00:47:57чего-то подобного во Vue.
00:48:00Фундаментальный вопрос здесь: какую именно проблему
00:48:01это пытается решить?
00:48:04И как это преподносилось.
00:48:07В попытках хайпануть
00:48:10это рекламировали как «серебряную пулю».
00:48:14Мол, это будет величайшая вещь в истории,
00:48:17которая ускорит все ваши сайты.
00:48:20А когда технология вышла, люди поняли:
00:48:23«Может, мне и не стоит использовать это везде».
00:48:28Это применимо только в определенных случаях,
00:48:30где это действительно принесет пользу.
00:48:35В остальном же это просто куча компромиссов.” —
00:48:38Потому что части, живущие на сервере,” —
00:48:40теперь любое взаимодействие требует
00:48:42сетевого запроса.
00:48:44А это довольно паршиво
00:48:48для опыта «offline-first», на мой взгляд.
00:48:51И вы не можете полностью избежать затрат на гидратацию,
00:48:54как мне кажется.
00:48:56Вы просто перекладываете часть стоимости клиентской гидратации.
00:48:59Вы переносите нагрузку на сервер, верно?
00:49:04Теперь вы платите ценой каждого запроса,
00:49:06выполняя больше работы на сервере.
00:49:08У людей даже есть теория заговора,
00:49:10что Vercel продвигает это, чтобы продавать больше серверных мощностей.
00:49:14Я не думаю, что дело в этом,
00:49:20но факт остается фактом: использование RSC
00:49:21означает большую нагрузку на сервер.
00:49:26Вы запускаете больше процессов на сервере,
00:49:29тратите больше серверных минут.
00:49:31И хотя есть плюсы — например,
00:49:33если вынести часть логики на сервер,
00:49:38уменьшится размер бандла...” —
00:49:44есть много других способов решить эту проблему,
00:49:47которые не требуют от вас
00:49:51обязательного запуска Node.js сервера.
00:49:52Опять же, это моё личное мнение.
00:49:54Во фронтенде мы привыкли говорить:
00:49:56«Архитектура действительно важна».
00:49:59Нужно ли вам SPA?
00:50:01Нужен ли серверный рендеринг (SSR)?
00:50:02RSC — это еще более специфическая штука.
00:50:06«Нужны ли вам RSC?» — это очень важный вопрос
00:50:07и на него очень трудно ответить.
00:50:10А когда вы говорите «да»,
00:50:14вы должны четко осознавать, какую цену вы платите.
00:50:17Думаю, одна из причин,
00:50:19почему технология не взлетела, в том, что, во-первых,
00:50:21она запредельно сложная.
00:50:24Саму концепцию трудно объяснить.
00:50:27Трудно объяснить, как это работает внутри.
00:50:31Нам пришлось закопаться очень глубоко,
00:50:33потому что это требует сложнейшей оркестровки на уровне сборщика,
00:50:35чтобы вся система вообще завелась.
00:50:37В итоге очень мало людей реально понимают,
00:50:39как работают «сырые» RSC.
00:50:43Большинство знают о них только через реализацию
00:50:46в Next.js, потому что обычный разработчик
00:50:48не смог бы настроить RSC сам с нуля.
00:50:50Нужно досконально понимать, как всё это стыкуется,
00:50:52чтобы собрать работающую схему самостоятельно
00:50:56на чистом React с Vite или Webpack.
00:50:58Это не то, чем хочется заниматься в повседневной разработке.
00:51:02Вам нужен фреймворк.
00:51:04Для этого он и создан.
00:51:07Но чтобы внедрить RSC в фреймворк,
00:51:11авторам фреймворка приходится принимать решения:
00:51:14как подать RSC пользователю,
00:51:17чтобы обеспечить достойный DX?
00:51:20И я считаю, что Next.js с этим не справился.
00:51:23Вся эта путаница с `use server` и `use client`,
00:51:27смешанные графы, когда вы помечаете что-то как `use server`
00:51:29и какие-то вещи просто перестают работать.
00:51:30Вы ограничены только определенным набором возможностей,
00:51:33а потом импортируете зависимость,
00:51:36а она не работает в `use server`.
00:51:39И вам снова приходится возвращаться к `use client`.
00:51:42Эта вечная беготня туда-сюда...
00:51:47Мне кажется, эта масса мелких неудобств
00:51:51в DX заставляет людей задуматься:
00:51:55«Чтобы получить заявленные выгоды,
00:51:58я теперь должен мириться с этим раздражением
00:52:01постоянно, всегда, в будущем?»
00:52:03«А оно того стоит?»
00:52:06Так что вполне справедливо, что люди задаются вопросом:
00:52:08«А действительно ли я хочу это использовать?»
00:52:10И даже для авторов фреймворков...
00:52:12у Vercel были очень тесные отношения с командой React,
00:52:15поэтому они могли сотрудничать и быстро итерировать.
00:52:20Но для сторонних разработчиков...
00:52:24хотя технически Vercel тоже сторонние,
00:52:27но для других фреймворков, типа Remix или TanStack,
00:52:28всё было далеко не так просто,” —
00:52:35им было сложно работать над этой проблемой, потому что многие
00:52:37изменения API от команды React делались с приоритетом под Next.js.
00:52:40Я не критикую их за это,” —
00:52:42понятно, Vercel их дизайн-партнер.
00:52:45Они хотят работать с Vercel,
00:52:49чтобы отполировать фичу и выпустить её,” —
00:52:52это логично.
00:52:57Но в результате
00:53:02Next.js по сути стал единственным реальным способом
00:53:06использовать RSC.
00:53:08А этот опыт оказался не самым приятным.
00:53:13Вот почему всё пошло не так гладко, как могло бы.
00:53:15И еще: я считаю,
00:53:17что даже в идеальном мире с идеальным DX для RSC,
00:53:19они всё равно не станут универсальным решением
00:53:21на все случаи жизни.
00:53:25Нужно понимать,
00:53:29где они имеют смысл, а где — нет.
00:53:31Слишком много компромиссов.
00:53:33— Я так понимаю, не было никаких попыток
00:53:38внедрить нечто подобное во Vue,
00:53:41поскольку связи там ведут к Vercel.
00:53:46Они купили NuxtLabs —
00:53:49это своего рода мета-фреймворк поверх Vue,
00:53:50который собирает всё воедино.
00:53:52Как изменились отношения между Nuxt и Vue
00:53:54теперь, когда Vercel ими владеет?
00:53:57— Честно говоря, почти ничего не изменилось.
00:53:59Vercel ведет себя довольно отстраненно с момента покупки,
00:54:01так что команда Nuxt просто рада возможности
00:54:03продолжать делать своё дело.
00:54:05Наверняка прилагаются усилия,
00:54:08чтобы Nuxt лучше работал на Vercel,
00:54:09стал там «гражданином первого класса».
00:54:13Но, думаю, в Vercel понимают,
00:54:14какой имидж у них сложился в сообществе,
00:54:18и они очень стараются не испортить его еще сильнее.
00:54:21И после покупки Nuxt
00:54:24последнее, чего бы они хотели —
00:54:25это заставлять Nuxt делать вещи, которые людям не нравятся.
00:54:30— К сожалению, Эвану пришлось уйти пораньше,
00:54:32чтобы ответить на важный звонок,
00:54:34но мы очень благодарны ему за уделенное время
00:54:38и за все его глубокие ответы на наши вопросы.
00:54:43Если у вас есть идеи, кого позвать в подкаст,
00:54:47пожалуйста, пишите в комментариях.
00:54:50И если у вас есть любой другой фидбек,
00:54:52тоже пишите нам.
00:54:54Мы будем рады его услышать.
00:54:56Ищите нас везде, где вы слушаете подкасты:
00:54:58в Spotify или Apple Podcasts.
00:55:00А на сегодня всё, с вами был я, пока!
00:55:04— Пока!
00:55:06— Пока!
00:55:08— Был рад пообщаться, всем спасибо.
00:55:10— Огромное спасибо, что пришли к нам.
00:55:11We'd love to hear it.
00:55:12Find us on anywhere you listen to podcasts
00:55:15like Spotify or Apple Podcasts.
00:55:17And until next time, it's a bye from me.
00:55:20- Bye from me.
00:55:21- Bye from me.
00:55:21- It's a pleasure, thank you all.
00:55:23- Thank you very much for joining us.