Ключевые выводы

Прорыв пока не в скорости. Опубликованные замеры автора ставят Voodoo.js рядом с Vue и React на создании списка, но далеко не впереди «ванильного» JavaScript и Preact. Читать бенчмарки как маркетинговый прорыв нельзя.

Новизна — в комбинации, а не в одной «секретной» технологии. HTML как центр приложения, выражения в разметке без компилятора JSX, точечные обновления DOM и отказ от обязательного пайплайна сборки — по отдельности знакомы; вместе они дают другой рабочий ритм.

Эпоха ИИ-кодинга усиливает ценность «приложения без проекта». Модели уже умеют выдавать цельный HTML. Если убрать package.json, конфиг Vite и шаг сборки, путь от промпта до кликабельного прототипа становится короче — и это практичнее, чем гонка миллисекунд в таблице.

Сильные ниши уже понятны. Прототипы, внутренние панели, микроприложения, интерактивные документы, статические страницы с умеренной динамикой. Слабые — крупные продуктовые клиентские части с дизайн-системой, строгим тестированием и долгой поддержкой.

Зрелость и риски реальны. Молодой API, собственный парсер выражений, отладка, безопасность при выполнении логики в разметке, масштабирование больших деревьев DOM. Идея интереснее, чем текущая экосистема.

Почему Voodoo.js вообще заслуживает внимания

За последние годы клиентская разработка накопила привычку: даже простая форма «открывается» через шаблон проекта, зависимости и конфиг. Это оправдано для продуктов с долгой жизнью. Для учебного стенда, внутренней админки на выходные или одноразового интерфейса под демо цена инфраструктуры часто больше пользы.

Voodoo.js появляется в этой точке напряжения. Автор позиционирует его как HTML-первый JavaScript-каркас: реактивность, компоненты, HTTP, формы и UI-набор через атрибуты и выражения в уже существующей разметке. Установка — тег script (например, сборка с CDN voodoojs). Нет обязательного сборщика, транспиляции и «каркаса проекта», чтобы увидеть результат — в том числе с file://.

Короткий анонс на Dev.to и новостной разбор на этом сайте уже обозначили идею. Ниже — не реклама и не «революция без доказательств», а разбор: что именно здесь ново, что знакомо, где каркас силён, где опасен, и почему его стоит держать в поле зрения даже если вы никогда не выложите его в прод.

Как сегодня устроена типичная клиентская разработка

Типичный путь выглядит так: разметка → компоненты → JSX/TSX → компилятор → сборщик → JavaScript → DOM. На пути появляются TypeScript, линтеры, пресеты CSS, маршрутизация, слой данных, CI и договорённости команды. Каждый слой сам по себе полезен. Вместе они превращают «показать список и кнопку» в мини-платформу.

Сложность выросла не из злости. Браузерные приложения стали настоящими продуктами: состояние, доступность, производительность, безопасность, мультикомандная разработка. Virtual DOM, компиляция шаблонов, островная архитектура, серверный рендеринг — ответы на реальные задачи. Парадокс в другом: небольшие задачи часто наследуют тот же пайплайн, что и крупные.

Итог для разработчика: чтобы проверить идею интерфейса, нужно сначала «поднять проект». Это замедляет эксперимент и отдаляет исходный код от того, что видит пользователь. Сборщики стали лучше (см. также как Turbopack режет JavaScript на фрагменты), но сам факт обязательного шага сборки никуда не делся.

Главная идея: HTML как приложение

Философия Voodoo.js: HTML остаётся центром. JavaScript не «забирает» разметку в отдельный мир компонентов с обязательной сборкой, а наращивает реактивный слой вокруг страницы, которую вы уже пишете.

Практический смысл «один HTML-файл + библиотека»:

1. Открыли файл в браузере — увидели поведение.
2. Нет обязательного npm install и конфига сборки для первого клика.
3. Исходник ближе к тому, что инспектирует DevTools.
4. Выкладка на статический хостинг упрощается: файл + CDN-скрипт.

Сайт проекта заявляет дополнительные свойства, важные для оценки зрелости идеи: после установки директив атрибуты убираются из документа (в инспекторе остаётся обычный HTML); выражения не идут через eval / new Function, а через лексер, Pratt-парсер и интерпретатор — заявка на работу при строгом CSP без unsafe-eval.

Минимальный пример в духе документации автора:

<script src="https://cdn.jsdelivr.net/npm/[email protected]/dist/voodoo.full.min.js" defer></script>

<div v-data="{ n: 0 }">
  <output>{ n }</output>
  <button @click="n--">-</button>
  <button @click="n++">+</button>
  <p>double: { n * 2 }</p>
</div>

Это не «магия без JavaScript» — логика есть. Но она живёт рядом с разметкой, без отдельного этапа «сначала собери приложение».

Рядом по духу — подходы, управляемые HTML вроде htmx 4.0 и сценарии HTML поверх WebSockets: сервер или тонкий клиентский слой, а не обязательный SPA-монолит. Voodoo.js ближе к клиентской реактивности «в файле», htmx — к серверно-управляемым обновлениям из атрибутов. Вместе они показывают одну тенденцию: вернуть выразительность разметке.

Самая необычная часть: выражения и JSX-стиль прямо в HTML

В привычном React JSX — это синтаксис, который до браузера превращается в вызовы функций. В Voodoo.js заявлен другой контракт: писать конструкции вроде { user }, цепочки map / filter и условный рендеринг внутри обычного .html, без компилятора JSX и без отдельного .tsx.

Это меняет ментальную модель. Вы не «собираете приложение из модулей», а описываете поведение в документе. Для прототипа это ускоряет итерации. Для большой команды это повышает требования к дисциплине: длинные выражения в HTML быстро теряют обзорность; без договорённостей страница превращается в трудночитаемый скрипт внутри тегов.

Собственный парсер/интерпретатор — и сила, и риск. Сила: нет зависимости от Babel/SWC ради JSX в HTML; потенциально строгий CSP. Риск: совместимость с ожиданиями разработчиков («это же почти JavaScript»), краевые случаи синтаксиса, отладка стектрейсов, эволюция языка выражений. Любой баг в интерпретаторе — баг во всех приложениях на каркасе.

Между HTML, JavaScript и DOM происходит примерно следующее: библиотека читает директивы и выражения, строит связи данных с узлами, обновляет DOM точечно при изменениях, по возможности очищает «служебные» атрибуты из итоговой разметки. Детали реализации стоит проверять в репозитории и тестах автора — публичные заявления сильные, независимый аудит экосистемы пока тонкий.

Реактивность без Virtual DOM

Voodoo.js опирается на обычный DOM и идею точечных обновлений: отслеживать зависимости и менять то, что реально изменилось. Сама по себе идея «без Virtual DOM» не революция: её давно исследуют Solid, Svelte (компиляция в точечные обновления), Alpine и «ванильные» подходы.

Полезнее сравнивать контракты, а не слоганы:

Вывод для архитектора: отсутствие Virtual DOM — не трофей. Вопрос в том, какую цену вы платите за реактивность: шаг сборки, размер бандла, предсказуемость обновлений, удобство отладки, найм людей, которые это уже знают.

Производительность: есть ли настоящий прорыв?

На сайте проекта опубликована таблица: семь реализаций одного списка на 1000 строк, медиана из 30 замеров (мс, меньше — лучше). Фрагмент (версия Voodoo.js 0.13.0 по заявлению автора):

Честное чтение (и сам автор это подчёркивает): на создании списка Voodoo.js — не лидер; «ваниль» заметно быстрее. На обновлении — рядом с React, Solid и Preact впереди. Alpine в этом сценарии отстаёт сильнее. Отдельно: размер бандла у Voodoo.js в сравнении заявлен как относительно большой; если критичен вес — Preact/Alpine часто честнее как рекомендация «полегче».

Главный вывод статьи по скорости: прорыва «мы уничтожили React по миллисекундам» нет. Есть конкурентоспособность в узком синтетическом сценарии и прозрачность замеров. Архитектурная идея — HTML-первый без обязательной сборки — интереснее таблицы.

Почему это особенно интересно в эпоху ИИ-кодинга

ИИ уже генерирует интерфейсы целиком: разметку, стили, обработчики. Чем короче путь «промпт → работающая страница», тем меньше мест, где генерация ломается о конфиги, версии плагинов и несовместимость пресетов.

Модель «приложения, сгенерированные ИИ, без проекта» выглядит так:

1. Запросили у модели один HTML-файл с нужным поведением.
2. Подключили одну библиотеку с CDN (или встроили минимальную среду выполнения).
3. Открыли в браузере, поправили вручную или вторым промптом.
4. Выложили как статику или отдали как внутренний инструмент.

Исчезают (или откладываются) package.json, выбор сборщика, настройка JSX, конфликт зависимостей. Остаются другие проблемы — качество кода, безопасность, доступность, сопровождение — но стартовый налог падает.

Это пересекается с тем, как команды уже используют агентов в IDE и генерацию прототипов (см. смежные длинные разборы про границы генерации кода и инженерии и как ИИ-IDE работают с кодом, если они у вас в ленте). Voodoo.js здесь — не единственный путь: тот же htmx, «ваниль», Alpine, даже CDN-сборка Vue решают часть задач. Но ставка на JSX-подобные выражения внутри HTML хорошо ложится на то, что модели уже умеют писать.

Риск зеркальный: ИИ легко нагенерирует огромную «простыню» логики в одном файле. Без границ и ревью получится не прототип, а неподдерживаемый монолит в HTML.

Где подход силён — и где опасен

Сильные сценарии

• Маленькие веб-приложения и микроинтерфейсы.
• Внутренние админки и панели «на вчера».
• Прототипирование продуктовых гипотез.
• Интерактивные документы и демонстрации.
• Статические сайты с умеренной динамикой.
• Одноразовые микроприложения, сгенерированные ИИ под задачу.

Слабые / рискованные сценарии

• Крупный продукт с дизайн-системой, многоязычностью, сложным роутингом и SSR/SEO-требованиями уровня маркетингового сайта.
• Команды, где найм и онбординг завязаны на React/Vue экосистему.
• Долгая поддержка без владельца, который понимает ограничения парсера времени выполнения.
• Жёсткие требования к аудиту безопасности клиентской логики.

Главные риски проекта

Молодость и маленькая экосистема: мало независимых статей, плагинов, курсов, «боевых» кейсов. Надёжность собственного интерпретатора выражений нужно проверять тестами и краш-кейсами, а не слоганами. Совместимость браузеров и поведение при строгом CSP стоит воспроизводить у себя. Отладка и инструментарий беднее, чем у React DevTools / Vue DevTools. Масштабирование больших приложений упрётся в организацию кода, а не в «магическую реактивность». Безопасность: любая модель «логика в разметке» требует дисциплины к XSS и к тому, чьи данные попадают в выражения. Разрастание возможностей: если каркас обрастёт всем, что есть у больших фреймворков, он рискует потерять исходное преимущество — простоту.

Практический совет: держите Voodoo.js в «песочнице» для задач, где цена ошибки низкая, а скорость эксперимента высокая. Для ядра продукта выбирайте то, что команда может сопровождать годы.

Что в Voodoo.js действительно новое — и сигнал о будущем

Новое здесь не Virtual DOM «наоборот» и не «ещё одни компоненты». Новое — связка:

• HTML-первый как рабочая норма, а не упрощённый демо-режим;
• JavaScript-выражения и JSX-стиль непосредственно в HTML без обязательного компилятора;
• точечные обновления DOM;
• минимальная инфраструктура до первого результата;
• заявленный отказ от eval ради более строгого CSP.

Это может быть ветка реактивного программирования, родного для HTML: разметка снова становится средой программирования интерфейса, а не только скелетом, который заполняет фреймворк. Вопрос «может ли компилятор перестать быть обязательным?» для некоторых классов приложений уже практический — не философский.

Будущее клиентской части, скорее всего, останется полиглотом архитектур: React/Next.js для крупных продуктов, Svelte/Solid где важны компиляция и размер, htmx и HTML «по проводу» где доминирует сервер, HTML-первая среда выполнения там, где важны скорость прототипа и простота выкладки. Voodoo.js — кандидат во последний лагерь, а не убийца остальных.

Вердикт

Voodoo.js пока не замена React, Vue или Svelte в зрелых продуктовых командах. Производительность не доказывает революционность. Экосистема молодая, API будет меняться, риски парсера и масштабирования нужно принимать осознанно.

При этом архитектурная идея заслуживает серьёзного внимания. Возможный сценарий: сам Voodoo.js не станет доминирующим каркасом, но его ход мыслей повлияет на следующее поколение инструментов — особенно на стыке статического хостинга, строгих CSP и ИИ-генерации интерфейсов.

Итоговая формулировка: не доказанный прорыв, но очень интересный сигнал о том, куда может двигаться клиентская часть.

Если коротко для командного чата: смотреть стоит; переписывать прод «потому что без сборки» — нет.

Что стоит проверить дальше — технический разбор

Этот текст — обзор архитектуры и смысла. Пайплайн выражений, Proxy-эффекты, walker и согласование v-for разобраны отдельно: Voodoo.js изнутри — парсер и интерпретатор.

Что ещё полезно проверить самостоятельно или следующим материалом кластера:

1. HTTP, формы, маршрутизация — что в ядре, что снаружи.
2. Размер бандла, точки входа (voodoojs/reactivity и т.п.) и накладные расходы среды выполнения.
3. Поведение на больших DOM-деревьях и длинных списках вне синтетики.
4. Сравнение с Solid/Svelte на одинаковых пользовательских сценариях (не только создание/обновление/очистку).
5. Независимый аудит CSP и отсутствия eval в реальных политиках.

До своих замеров сохраняйте скепсис к абсолютным формулировкам и опирайтесь на воспроизводимые демо.

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

Дальнейшее чтение

Если собираете картину HTML-первый и альтернатив тяжёлому SPA, имеет смысл пройти соседние материалы:

• Voodoo.js: архитектура среды выполнения без компилятора, Virtual DOM и eval — горизонтальная архитектурная карта кластера.
• Voodoo.js: реактивность прямо в HTML (новостной разбор)
• htmx 4.0: fetch и HTML без лишнего JavaScript
• HTML поверх WebSockets: реальное время без классического SPA
• Как Turbopack режет JavaScript на фрагменты
• Svelte: обзор обновлений
• Миграция большой клиентской части: Next.js → TanStack Start
• FastAPI + htmx + React в Telegram Mini App

Внешние первоисточники: документация и демо Voodoo.js, репозиторий на GitHub.

Заключение

Voodoo.js полезен как вопрос к статусу-кво, даже если конкретная реализация не станет стандартом. Вопрос звучит так: для какого класса интерфейсов мы продолжаем платить полный налог современной клиентской части — и где достаточно документа, реактивности и одной библиотеки?

На этой неделе сделайте маленький эксперимент: возьмите внутреннюю задачу уровня «таблица + фильтр + модалка», соберите её одним HTML-файлом на Voodoo.js или на htmx/Alpine, засеките время до первого рабочего экрана и сравните с привычным шаблоном Vite+React. Цифра времени скажет больше, чем любой слоган про прорыв.

Опциональная лабораторная рамка Stuzhuk Lab: сначала зафиксируйте границу эксперимента (что не масштабируем специально), потом уже спорьте о каркасах — иначе любой новый инструмент превращается в бесконечную проверку концепции без критерия успеха.