A reactive JS framework for server-rendered apps - no Virtual DOM, no eval(), no build step required. Looking for critical feedback.

I've been building a JavaScript framework called Voodoo.js, and I'd rather get torn apart in the comments than hear that it looks cool. It started with one question: How much JavaScript do we actually need to write for everyday interactive interfaces? For a lot of apps I don't want to build a component tree, configure a bundler, install five libraries, wrap the API, manage state somewhere else, and then wire it all back into HTML. Sometimes I just want to keep writing HTML. GitHub: https://github.com/kwy404/Voodoo.js The 30-second version A reactive counter: - { count } + No querySelector . No addEventListener . No innerHTML . No Virtual DOM. Voodoo observes the real DOM and connects HTML directives to a fine-grained reactive system built on Proxy . "Why another JS framework?" Fair question. It's the first one I'd ask too. Voodoo isn't trying to replace React, Vue or Svelte. The target is different: projects where the server already renders the HTML. Laravel, Django, Rails, PHP, ASP.NET, Node, Go templates - plus small frontends where a full SPA is overkill. Philosophically it lives somewhere near Alpine.js, HTMX and petite-vue. The difference I was chasing: HTTP, forms, validation, state, components, routing, UI helpers and reactivity should feel like one system, not five glued together. Declarative HTTP This is the part I enjoy using most. Instead of wiring a button by hand: button.addEventListener('click', async () => { if (!confirm('Delete user?')) return await fetch('/api/users/42', { method: 'DELETE' }) showToast('User deleted') }) You declare the intent: Delete The goal isn't to make JavaScript disappear. It's to stop writing JavaScript that only restates what the HTML already says. Forms Same idea: Save For most CRUD screens, that's the whole thing. When you need more, plain JavaScript is still right there. Voodoo is meant to be progressive, not restrictive. No eval() , no new Function() Take this: The lazy implementation is new Function(expression) or eval(expression) . Voodoo does neither. There's a full expression engine inside: Lexer → Pratt Parser → AST → Interpreter Expressions are parsed and interpreted by Voodoo itself. That gives the framework control over which syntax is supported and what the expression environment can touch - and honestly it's the most interesting engineering in the project. Fine-grained reactivity The reactive layer uses Proxy , tracking dependencies per object and per property: reactive object ↓ property accessed dependency tracked ↓ property changed only dependent effects run No Virtual DOM diff between updates. The real DOM is patched directly. The reactivity package exposes a familiar surface: reactive() ref() computed() watch() watchEffect() effectScope() toRaw() markRaw() If you've used a modern reactive framework, none of this should surprise you. Works with or without a build step Drop it in: Toggle Hello DEV Community 👋 Or import it like anything else: import { reactive } from 'voodoojs/reactivity' Both audiences matter to me: the "paste a script tag" crowd and the "give me proper ESM" crowd. Where it fits Server-rendered HTML + Voodoo.js → Reactive interface A Laravel view, for example: @foreach($users as $user) id }}" v-confirm="Delete user?"> Delete @endforeach The backend keeps rendering the app. Voodoo adds the interactive layer. No separate frontend application. The honest part What began as an experiment grew into a large framework: reactivity, directives, components, stores, HTTP, forms, validation, persistence, routing, i18n, UI utilities, animation, drag and drop, charts, streaming, devtools, and a CLI. That growth is now the problem. The project doesn't need another hundred features - it needs stability. Current focus: - 🔒 Security hardening - 🧩 Parser edge cases - ✅ Test coverage - 📐 API stability - 📦 Bundle modularity - ⚡ Performance benchmarks - 📚 Documentation - 🚀 Package and release quality I'd rather ship a small set of features people can trust in production than a huge one nobody can. What I'm asking for If you work with Alpine.js, HTMX, Vue, petite-vue, Stimulus, Livewire, server-rendered apps, or plain JS - I want your read on this: - What would stop you from using something like Voodoo.js? - Which parts of the API feel intuitive? - Which parts feel unnecessary? - What would you need to see before calling it production-ready? And if you like working on JS internals, there's real work available: parsers, reactivity, testing, browser compatibility, TypeScript, performance, security, docs, components. GitHub: https://github.com/kwy404/Voodoo.js If you find something questionable in the architecture, the API, the security model or the implementation, tell me. That's the feedback I actually need. Top comments (1) Good idea !!