Один разработчик переписал компилятор Svelte на Rust: 25 000 компонентов больше не роняют IDE

Svelte, это фреймворк для создания веб-интерфейсов, где код превращается в готовый JavaScript на этапе сборки, а не в браузере. Компилятор (программа, которая выполняет это превращение) написан на JavaScript. Константин, фронтенд-разработчик с пятилетним стажем в enterprise-компании, решил переписать этот компилятор на Rust (язык программирования, известный высокой скоростью и экономным расходом памяти). Исходный код проекта опубликован на GitHub как открытый проект svelte-rs. Источник, авторский пост Константина на Хабре.

Какую проблему решает svelte-rs?

Константин описывает конкретную боль большой команды:

• Проекты долго собирались. В самом крупном проекте компании 25 тысяч Svelte-компонентов вместе с внутренними пакетами. Dev-сервер (локальный сервер для разработки) стартовал медленно и работал с задержками.
• LSP в IDE зависал. LSP (Language Server Protocol, протокол, который даёт редактору кода подсказки, подсветку ошибок и автодополнение) не справлялся с объёмом кодовой базы.
• Утилита svelte-check работала долго. Это инструмент проверки ошибок в Svelte-файлах перед релизом.
• На машинах с 8 гигабайтами оперативной памяти проекты не запускались вовсе. Ноутбуки грелись и шумели.

Внешние решения на тот момент ещё не вышли. TypeScript на Go (Project Corsa) анонсировали только в марте 2025 года. Vite 8, построенный на движке Rolldown, стал стабильным 12 марта 2026 года. Rolldown 1.0 вышел 7 мая 2026 года. TypeScript 7 RC появился 18 июня 2026 года. Ждать было некогда.

Как шла разработка: два захода за полтора года

Первая попытка заняла пять с половиной месяцев: с 4 ноября 2024 по 24 апреля 2025 года, 303 коммита, 108 дней с коммитами. Константин делал всё вручную, параллельно изучая Rust.

Архитектура строилась по классической схеме: сканер разбивал текст на токены, парсер превращал токены в AST (абстрактное синтаксическое дерево, структурированное представление кода), кодогенератор превращал дерево в JavaScript.

Парсер для JavaScript-выражений внутри Svelte-шаблонов Константин не писал сам, а использовал OXC, открытый проект, который стал ядром Vite 8 и Rolldown. Именно отсутствие поддерживаемых JS/TS-парсеров на Go стало причиной выбора Rust.

Константин сразу заложил восстановление после ошибок: оригинальный компилятор Svelte останавливается на первой ошибке, а svelte-rs записывает её в список и продолжает разбор. Это задел под будущее встраивание в LSP.

Где первая попытка забуксовала?

Две архитектурные ошибки остановили проект.

Первая: Константин хранил в AST ссылки на строки вместо копий, чтобы избежать лишних выделений памяти. Плюс в AST хранилась мета-информация из фазы анализа. В Rust это привело к тому, что через всё дерево прорастал lifetime (механизм контроля времени жизни данных), а менять такое дерево без специальных обёрток стало практически невозможно.

Вторая: по аналогии с компилятором Rust (rustc) Константин завёл второе дерево, HIR (High-level Intermediate Representation, промежуточное представление более высокого уровня). За неделю сделал преобразование AST в HIR, но оказалось, что отдельное дерево не нужно: те же задачи решаются анализом и семантиками поверх одного AST.

Результат: два дерева вместо одного, преобразование между ними и вдвое больше шаблонного кода на каждое изменение. Мотивация закончилась, первая попытка остановилась.

Как попробовать?

1. Откройте репозиторий проекта: github.com/MrWaip/svelte-rs.
2. Клонируйте его и соберите по инструкции в README (потребуется установленный Rust-тулчейн).
3. Подставьте свои Svelte-файлы и сравните результат компиляции с оригинальным компилятором.

Проект пока не заменяет штатный компилятор Svelte и не имеет стабильного релиза. Это исследовательская работа, а не готовый инструмент для продакшена.

Есть ли аналоги в российской экосистеме?

Прямых аналогов svelte-rs в России нет: это не продукт, а инженерный эксперимент одного разработчика. Но сама задача, ускорение тяжёлых сборок в больших проектах, знакома командам, работающим с любыми фреймворками.

Если вы используете фреймворки в крупных российских проектах и сталкиваетесь с медленной сборкой, стоит следить за Vite 8 (уже стабилен) и Rolldown 1.0 (вышел в мае 2026 года), они решают часть тех же проблем на уровне сборщика, без переписывания компилятора вручную.

Что с этого прямо сейчас, по ролям?

Разработчику в большой команде. Если ваш проект на Svelte тормозит и LSP не справляется, изучите подход Константина: парсер с восстановлением после ошибок и использование OXC вместо собственного JS-парсера. Даже если вы не перепишете компилятор, архитектурные решения из svelte-rs пригодятся при оптимизации тулинга.

Автору Дзена, пишущему про разработку. Это готовый кейс для статьи или серии: путь от книги «Writing an Interpreter in Go» до собственного компилятора, с конкретными ошибками и числами. Такие истории собирают аудиторию.

Руководителю или предпринимателю. Когда штатные инструменты не справляются с масштабом, а официальные обновления ещё далеко, иногда быстрее вырастить решение внутри команды. Но учитывайте: Константин потратил 5,5 месяцев и остановился из-за архитектурных тупиков. Внутренний тулинг требует ресурсов, которые не всегда окупаются.

Частые вопросы

Можно ли уже использовать svelte-rs вместо стандартного компилятора?

Нет. Проект находится в стадии эксперимента. Константин описал первую попытку, которая остановилась на архитектурных проблемах. Для рабочих проектов используйте штатный компилятор Svelte.

Зачем переписывать компилятор на Rust, если скоро выйдут Vite 8 и Rolldown?

На момент начала работы (ноябрь 2024) эти инструменты ещё не были доступны. Vite 8 стал стабильным только в марте 2026 года, Rolldown 1.0 вышел в мае 2026 года. Для команды с 25 тысячами компонентов ждать полтора года было неприемлемо. Сейчас, когда эти инструменты доступны, часть проблем со сборкой решается без переписывания компилятора.

Почему Rust, а не Go?

Константин начинал с Go: написал интерпретатор по книге, попробовал парсить JavaScript. Но на Go не нашлось поддерживаемого парсера JS/TS, а на Rust уже существовал OXC. Именно наличие готовой инфраструктуры определило выбор языка.