Key takeaways

The breakthrough is not speed — yet. The author’s published numbers place Voodoo.js next to Vue and React on list creation, but nowhere ahead of vanilla JavaScript or Preact. Treat the benchmarks as marketing breakthrough material and you will misread them.

The novelty is the combination, not one “secret” technology. HTML as the center of the app, expressions in markup without a JSX compiler, fine-grained DOM updates, and dropping a mandatory build pipeline — each piece is familiar; together they create a different working rhythm.

The AI-coding era raises the value of an “app without a project.” Models already emit coherent HTML. Remove package.json, a Vite config, and the build step, and the path from prompt to clickable prototype gets shorter — which is more practical than racing milliseconds in a table.

The strong niches are already clear. Prototypes, internal panels, micro-apps, interactive documents, static pages with moderate dynamics. The weak ones — large product frontends with a design system, strict testing, and long-term ownership.

Maturity and risk are real. A young API, a custom expression parser, debugging, security when logic runs in markup, scaling large DOM trees. The idea is more interesting than the current ecosystem.

Why Voodoo.js deserves attention at all

Over the last few years frontend accumulated a habit: even a simple form “opens” through a project template, dependencies, and config. That is justified for products with a long life. For a teaching sandbox, an internal admin thrown together over a weekend, or a one-off demo UI, the cost of infrastructure often exceeds the benefit.

Voodoo.js appears at that tension point. The author positions it as an HTML-first JavaScript framework: reactivity, components, HTTP, forms, and a UI kit through attributes and expressions in markup you already write. Installation is a script tag (for example, a build from the voodoojs CDN). There is no mandatory bundler, transpilation, or “project scaffold” to see a result — including over file://.

A short Dev.to announcement and a news-style write-up on this site already sketched the idea. What follows is neither an ad nor a “revolution without evidence,” but a breakdown: what is actually new here, what is familiar, where the framework is strong, where it is dangerous, and why it is worth keeping in view even if you never ship it to production.

How typical frontend development works today

The usual path looks like this: markup → components → JSX/TSX → compiler → bundler → JavaScript → DOM. Along the way appear TypeScript, linters, CSS presets, routing, a data layer, CI, and team conventions. Each layer is useful on its own. Together they turn “show a list and a button” into a mini-platform.

Complexity did not grow out of spite. Browser apps became real products: state, accessibility, performance, security, multi-team development. Virtual DOM, template compilation, islands architecture, server rendering — answers to real problems. The paradox sits elsewhere: small tasks often inherit the same pipeline as large ones.

The developer outcome: to try an interface idea, you first have to “spin up a project.” That slows experiments and distances source code from what the user sees. Bundlers got better (see also how Turbopack chunks JavaScript), but the fact of a mandatory build step never went away.

The core idea: HTML as the application

The Voodoo.js philosophy: HTML stays at the center. JavaScript does not “steal” markup into a separate component world with a mandatory build; it grows a reactive layer around the page you already write.

Practical meaning of “one HTML file + library”:

1. Open the file in a browser — see behavior.
2. No mandatory npm install and build config for the first click.
3. Source stays closer to what DevTools inspects.
4. Deploy to static hosting gets simpler: file + CDN script.

The project site claims extra properties that matter for judging maturity: after directives install, attributes are removed from the document (the inspector shows ordinary HTML); expressions do not go through eval / new Function, but through a lexer, Pratt parser, and interpreter — a claim of working under strict CSP without unsafe-eval.

A minimal example in the spirit of the author’s docs:

<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>

This is not “magic without JavaScript” — logic is there. But it lives next to the markup, without a separate stage of “first build the app.”

Nearby in spirit are HTML-driven approaches like htmx 4.0 and HTML over WebSockets scenarios: a server or a thin client layer, not a mandatory SPA monolith. Voodoo.js is closer to client reactivity “in a file”; htmx is closer to server-driven updates from attributes. Together they show one trend: give expressiveness back to markup.

The most unusual part: expressions and JSX-style syntax inside HTML

In familiar React, JSX is syntax that before the browser turns into function calls. Voodoo.js claims a different contract: write constructs like { user }, map / filter chains, and conditional rendering inside a normal .html file, without a JSX compiler and without a separate .tsx.

That changes the mental model. You are not “assembling an app from modules”; you describe behavior in the document. For a prototype that speeds iteration. For a large team it raises the bar on discipline: long expressions in HTML quickly lose scannability; without conventions the page becomes a hard-to-read script inside tags.

A custom parser/interpreter is both strength and risk. Strength: no Babel/SWC dependency just to get JSX in HTML; potentially strict CSP. Risk: compatibility with developer expectations (“this is almost JavaScript”), edge cases in syntax, stack-trace debugging, evolution of the expression language. Any bug in the interpreter is a bug in all apps on the framework.

Between HTML, JavaScript, and the DOM roughly this happens: the library reads directives and expressions, builds data-to-node links, updates the DOM finely when things change, and where possible clears “service” attributes from the final markup. Implementation details should be checked in the author’s repo and tests — the public claims are strong; independent ecosystem audit is still thin.

Reactivity without a Virtual DOM

Voodoo.js leans on the ordinary DOM and fine-grained updates: track dependencies and change what actually changed. The idea of “no Virtual DOM” by itself is not a revolution: Solid, Svelte (compile to fine-grained updates), Alpine, and vanilla approaches have explored it for years.

It is more useful to compare contracts, not slogans:

Architect takeaway: absence of a Virtual DOM is not a trophy. The question is what price you pay for reactivity: a build step, bundle size, update predictability, debug comfort, hiring people who already know the stack.

Performance: is there a real breakthrough?

The project site publishes a table: seven implementations of the same 1000-row list, median of 30 runs (ms, lower is better). Fragment (Voodoo.js version 0.13.0 per the author):

An honest reading (and the author stresses this): on list creation Voodoo.js is not the leader; vanilla is noticeably faster. On update it sits near React, with Solid and Preact ahead. Alpine lags harder in this scenario. Separately: Voodoo.js’s bundle size is claimed as relatively large in comparison; if weight is critical, Preact/Alpine are often the more honest “go lighter” recommendation.

This article’s main speed takeaway: there is no breakthrough of “we destroyed React on milliseconds.” There is competitiveness in a narrow synthetic scenario and transparency of the numbers. The architectural idea — HTML-first without a mandatory build — is more interesting than the table.

Why this matters more in the age of AI coding

AI already generates interfaces end to end: markup, styles, handlers. The shorter the path “prompt → working page,” the fewer places where generation breaks on configs, plugin versions, and preset mismatches.

The model of “AI-generated applications without a project” looks like this:

1. Ask the model for one HTML file with the desired behavior.
2. Attach one library from a CDN (or embed a minimal runtime).
3. Open in a browser, fix by hand or with a second prompt.
4. Deploy as static files or hand it over as an internal tool.

package.json, bundler choice, JSX setup, and dependency conflicts disappear (or get deferred). Other problems remain — code quality, security, accessibility, maintenance — but the startup tax drops.

This intersects with how teams already use agents in IDEs and prototype generation (see related long reads on where code generation ends and engineering begins and how AI IDEs work with code, if they are in your feed). Voodoo.js is not the only path here: the same htmx, vanilla, Alpine, even a CDN Vue build solve parts of the job. But betting on JSX-like expressions inside HTML fits well with what models already write fluently.

The mirror risk: AI easily generates a huge “sheet” of logic in one file. Without boundaries and review you get not a prototype but an unmaintainable monolith in HTML.

Where the approach shines — and where it is dangerous

Strong scenarios

• Small web apps and micro-interfaces.
• Internal admins and “needed yesterday” panels.
• Prototyping product hypotheses.
• Interactive documents and demos.
• Static sites with moderate dynamics.
• One-off AI-generated micro-apps for a task.

Weak / risky scenarios

• A large product with a design system, i18n, complex routing, and SSR/SEO requirements at marketing-site level.
• Teams whose hiring and onboarding are tied to the React/Vue ecosystem.
• Long support without an owner who understands runtime-parser limits.
• Hard requirements to audit client-side logic security.

Main project risks

Youth and a small ecosystem: few independent articles, plugins, courses, “battle” case studies. Reliability of the custom expression interpreter needs tests and crash cases, not slogans. Browser compatibility and strict-CSP behavior should be reproduced yourself. Debugging and tooling are thinner than React DevTools / Vue DevTools. Scaling large apps will hit code organization, not “magic reactivity.” Security: any “logic in markup” model needs discipline around XSS and whose data lands in expressions. Feature creep: if the framework grows everything large frameworks have, it risks losing its original advantage — simplicity.

Practical advice: keep Voodoo.js in a sandbox for tasks where the cost of error is low and experiment speed is high. For product core, choose what the team can support for years.

What is actually new in Voodoo.js — and a signal about the future

What is new here is not Virtual DOM “in reverse” and not “yet more components.” What is new is the bundle:

• HTML-first as a working norm, not a simplified demo mode;
• JavaScript expressions and JSX style directly in HTML without a mandatory compiler;
• fine-grained DOM updates;
• minimal infrastructure to first result;
• a claimed rejection of eval for stricter CSP.

This may be a branch of HTML-native reactive programming: markup again becomes the programming medium for the interface, not only a skeleton a framework fills. The question “can a compiler stop being mandatory?” for some classes of apps is already practical — not philosophical.

Frontend’s future will likely stay a polyglot of architectures: React/Next for large products, Svelte/Solid where compilation and size matter, htmx/HTML-over-the-wire where the server dominates, HTML-first runtime where prototype speed and deploy simplicity matter. Voodoo.js is a candidate for the last camp, not a killer of the others.

Verdict

Voodoo.js is not yet a replacement for React, Vue, or Svelte on mature product teams. Performance does not prove revolutionary status. The ecosystem is young, the API will move, parser and scaling risks must be accepted consciously.

At the same time the architectural idea deserves serious attention. A plausible scenario: Voodoo.js itself never becomes the dominant framework, but its line of thought influences the next generation of tools — especially at the junction of static hosting, strict CSP, and AI-generated interfaces.

Final phrasing: not a proven breakthrough, but a very interesting signal about where frontend may move.

For the team chat, short: worth watching; rewriting production “because no build” — no.

What to verify next — a technical deep dive

This piece is an architecture-and-meaning overview. The expression pipeline, Proxy effects, walker, and v-for reconciliation are covered separately: Inside Voodoo.js — parser and interpreter.

Still useful to verify yourself or in a later cluster piece:

1. HTTP, forms, routing — what is in the core, what is outside.
2. Bundle size, entrypoints (voodoojs/reactivity and similar), and runtime overhead.
3. Behavior on large DOM trees and long lists outside synthetic benches.
4. Comparison with Solid/Svelte on identical user scenarios (not only create/update/clear).
5. Independent CSP audit and absence of eval under real policies.

Until you have your own measurements, keep skepticism toward absolute phrasing and lean on reproducible demos.

Frequently asked questions

Further reading

If you are assembling a picture of HTML-first and alternatives to a heavy SPA, these neighboring pieces help:

• Voodoo.js: a runtime architecture without a compiler, Virtual DOM, or eval — the horizontal architecture map for the cluster.
• Voodoo.js: reactivity and map/filter inside plain HTML (news write-up)
• htmx 4.0: fetch-based requests and HTML-driven apps
• HTML over WebSockets: SPAs with barely any JavaScript
• How Turbopack chunks your JavaScript in Next.js
• Svelte, September 2026: SvelteKit 3 RC, SvelteMap, and sv migration
• Lovable: 400 routes from Next.js to TanStack Start without a big bang
• Five products in one FastAPI monolith: HTMX, Telegram Mini App, and Stars

External primaries: Voodoo.js docs and demos, GitHub repository.

Conclusion

Voodoo.js is useful as a question to the status quo, even if the concrete implementation never becomes a standard. The question is: for which class of interfaces do we keep paying the full tax of modern frontend — and where is a document, reactivity, and one library enough?

This week, run a small experiment: take an internal task at the level of “table + filter + modal,” build it as one HTML file on Voodoo.js or on htmx/Alpine, time to first working screen, and compare with a habitual Vite+React template. The time number will say more than any slogan about breakthroughs.

Optional Stuzhuk Lab closing: first fix the boundary of the experiment (what you deliberately will not scale), then argue about frameworks — otherwise every new tool becomes an endless proof-of-concept without a success criterion.