← All posts

Voodoo.js: reactivity and map/filter inside plain HTML

An HTML-first JS framework with one script tag—no bundler—reactive markup and JSX-style syntax in a normal page.

Tags
Newsfrontendhtmljavascript
Voodoo.js: reactivity and map/filter inside plain HTML
Contents

In brief

The author of Voodoo.js on Dev.to wants reactive UIs, list rendering via map / filter / sort, components, and even JSX-style syntax inside a plain HTML file. The framework targets developers who want modern frontend capabilities without a heavy toolchain: one script tag, no bundler, compiler, config, or project scaffolding. HTML stays at the center; reactivity wraps the markup you already have instead of forcing a different app structure.

What happened

The pitch is simple: open an .html file, include Voodoo.js, and work with reactive data, events, expressions, forms, HTTP helpers, and JSX-style templates. In the stock example, products are filtered by inventory, sorted, and rendered with familiar array methods—while the file remains a normal HTML page, not a separate build-driven app.

For people coming from React, Vue, Alpine, or vanilla JavaScript, the syntax feels familiar. The philosophy differs: do not pull markup into a foreign application shell; keep HTML primary. The author aims at prototypes, small apps, internal tools, static sites, and experiments—places where the cost of standing up Vite/Webpack already outweighs the framework payoff.

There is also an in-browser playground: edit HTML, run the sample, see a live preview. A JSX-map demo, project site, and GitHub repo are linked. The project is open source and still evolving; the author asks for feedback and stars, and poses a community question: would you accept JSX/TSX-style syntax inside HTML if it removed the build step?

Why it matters

In recent years “minimal frontend” often still meant a starter template, dependencies, and config. For a teaching demo, a landing page with light dynamics, or an internal form, that inflates the “open file → see result” loop. Voodoo.js points at the other pole: the browser as the environment, HTML as source of truth, reactivity as a layer on top.

This is not a claim to replace React on a large team with a design system and server rendering. It is a hypothesis check: can familiar map/filter and a component feel exist without a mandatory bundle? For mentors, freelancers, and teams with many small HTML pages, that lowers the entry bar. The reverse risk is a blurry line between “just a page” and “already an app,” plus dependence on a young API that is still moving.

In practice

  1. For a prototype or internal tool, first ask whether one HTML file + Voodoo.js beats a new repo with a bundler.
  2. Keep markup readable: reactive expressions and filter → sort → map chains are handy, but long blocks in HTML lose scannability—extract repeats into framework components.
  3. If the team already ships React/Vue through one deploy pipeline, do not drag Voodoo.js “for simplicity” into that same production surface; keep it on isolated pages.
  4. Before production, check the author’s playground and repo: API stability, forms/HTTP support, and how expression errors surface.
  5. On static hosting, “one file + CDN script” simplifies deploy; decide where data lives (inline JSON, separate API) and how you update the page without a build.
  6. Compare with Alpine and vanilla JS: if small directives are enough, you may not need a new framework; if you want a JSX feel without a bundler, try the playground first.

Takeaway

Voodoo.js bets on HTML-first reactive frontend work without a required build step. For prototypes and small apps it can speed up the start; for large product stacks it is an experiment, not a drop-in replacement for mature frameworks. Look at the demos, size the problem—and do not confuse a fast start with long-term maintainability.