Ключові висновки

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

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

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

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

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

Чому Voodoo.js взагалі заслуговує уваги

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

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

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

Як сьогодні влаштована типова клієнтська розробка

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

Складність виросла не зі злості. Браузерні застосунки стали справжніми продуктами: стан, доступність, продуктивність, безпека, багатокомандна розробка. 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: сервер або тонкий клієнтський шар, а не обов’язковий моноліт односторінкового застосунку. 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 з ШІ працюють із кодом, якщо вони у вас у стрічці). Voodoo.js тут — не єдиний шлях: той самий htmx, «ваніль», Alpine, навіть збірка Vue з CDN розв’язують частину задач. Але ставка на вирази в дусі JSX всередині HTML добре лягає на те, що моделі вже вміють писати.

Ризик дзеркальний: ШІ легко нагенерує величезну «простирадло» логіки в одному файлі. Без меж і перегляду вийде не прототип, а непідтримуваний моноліт у HTML.

Де підхід сильний — і де небезпечний

Сильні сценарії

• Маленькі вебзастосунки й мікроінтерфейси.
• Внутрішні адмінки й панелі «на вчора».
• Прототипування продуктових гіпотез.
• Інтерактивні документи й демонстрації.
• Статичні сайти з помірною динамікою.
• Разові мікрозастосунки, згенеровані ШІ під задачу.

Слабкі / ризиковані сценарії

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

Головні ризики проєкту

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

Практична порада: тримайте 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 у реальних політиках.

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

Часті питання

Чи можна вже ставити це в бойове середовище?

Коротка відповідь: для невеликих внутрішніх інструментів — обережно так; для ядра публічного продукту — рано без власної оцінки ризиків.

Потрібні свої заміри, політика безпеки, план супроводу й розуміння, що API молодий. Для прототипу й пісочниці поріг входу низький.

Чим Voodoo.js відрізняється від Alpine?

Коротка відповідь: обидва живуть у HTML, але Voodoo.js сильніше тисне на вирази в дусі JSX і «застосунок у файлі» без збірки, плюс свій інтерпретатор замість звичного «майже JS в атрибутах» у стилі Alpine.

Alpine простіший і легше знайомий багатьом; Voodoo.js обіцяє більш «каркасний» синтаксис усередині розмітки. Вибір — про модель виразів і готовність до молодого середовища виконання.

Чим це відрізняється від htmx?

Коротка відповідь: htmx здебільшого рухає взаємодію до сервера через HTML-атрибути; Voodoo.js тримає клієнтську реактивність і логіку на сторінці.

Їх можна навіть мислити комплементарно: серверні шматки через htmx, локальна реактивність — через HTML-перше середовище виконання. Змішування без дисципліни швидко ускладнить сторінку.

Чи потрібен Virtual DOM, щоб клієнтська частина була «справжньою»?

Коротка відповідь: ні.

Virtual DOM — один із інструментів узгодження інтерфейсу й стану. Компіляція (Svelte), дрібнозерниста реактивність (Solid) і акуратний DOM API розв’язують суміжні задачі інакше. Важливі передбачуваність, вартість оновлень і зручність команди.

Чому ШІ-кодування підсилює інтерес до таких каркасів?

Коротка відповідь: тому що моделі добре генерують цілісні HTML-документи, а погано люблять крихкі ланцюжки конфігурації.

Менше рухомих частин до першого результату — більше шансів, що згенерований прототип одразу відкриється. Це не скасовує перегляд і інженерію.

Чи варто вчити Voodoo.js замість React?

Коротка відповідь: ні, не замість.

React/Vue/Svelte лишаються валютою ринку праці й великих продуктів. Voodoo.js має сенс як розширення кругозору й інструмент для швидких інтерфейсів — поруч, а не замість основної компетенції.

Де дивитися вихідники й демонстрації?

Коротка відповідь: сайт проєкту й репозиторій автора на GitHub, плюс майданчик для спроб; короткий новинний конспект — у нас у блозі.

Звіряйте версію в CDN (у прикладах вище — лінія 0.13.x на момент розбору) і читайте журнал змін: у молодому проєкті це обов’язкова гігієна.

Подальше читання

Якщо збираєте картину HTML-першого підходу й альтернатив важкому односторінковому застосунку, має сенс пройти сусідні матеріали:

• Voodoo.js: архітектура середовища виконання без компілятора, Virtual DOM і eval — горизонтальна архітектурна карта кластера.
• Voodoo.js: реактивність і map/filter просто в звичайному HTML (новинний розбір)
• htmx 4.0: запити через fetch і HTML без зайвого JavaScript
• HTML поверх WebSockets: SPA майже без JavaScript
• Як Turbopack ділить JavaScript на фрагменти в Next.js
• Svelte, вересень 2026: SvelteKit 3 RC, SvelteMap і міграція через sv
• Lovable: 400 маршрутів з Next.js на TanStack Start без одномоментного перемикання
• П'ять продуктів в одному FastAPI-моноліті: HTMX, Telegram Mini App і Stars

Зовнішні першоджерела: документація й демонстрації Voodoo.js, репозиторій на GitHub.

Висновок

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

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

Необов’язкова лабораторна рамка Stuzhuk Lab: спочатку зафіксуйте межу експерименту (що спеціально не масштабуємо), потім уже сперечайтеся про каркаси — інакше будь-який новий інструмент перетворюється на нескінченне підтвердження концепції без критерію успіху.