Voby is a signal based UI framework with no VDOM and no Babel transform

Voby is Solid's model with the Babel transform removed

Voby is a UI framework written in TypeScript that describes itself as high-performance with fine-grained observable or signal based reactivity. The feature list opens with a direct comparison: it works similarly to Solid, but without a custom Babel transform and with a different API. That single sentence defines the project. The mental model is Solid's, the tooling is closer to plain JavaScript with optional JSX, and the surface is the author's own.

The motivation is stated without much modesty in the same list. The author is building it because he needs good performance for Notable, is allergic to third-party dependencies, wants an API that resonates with him, and wanted to understand deeply how Solid works, which he calls the more solid option and points readers toward. That is a personal project with a real product behind it, and it is also the reason there is no community consensus about the API yet.

The honest caveat is in the list as well: this is probably beta software. The package.json puts the version at 0.58.1, the licence is MIT, and the repository root holds a license file, an src directory, a demo directory, tsconfig.json and little else. The site is voby.dev, and the project also has a Discord, a CodeSandbox playground, a StackBlitz playground and an Open Collective page, so there is somewhere to ask questions.

Updates go straight to the DOM, so nothing is diffed

The reactivity model is the part that decides whether an application built with Voby feels fast, so it is worth being concrete about what the framework claims to remove.

There is no virtual DOM. The framework deals with raw DOM nodes directly, which removes the reconciliation step entirely rather than optimising it. There is no props diffing either: whenever an attribute, property, class or handler should change, it is updated directly and immediately, and the update is fine-grained, meaning the specific reactive value that changed is the specific thing that updates. There is no key prop to specify when you map over an array, and the framework points you at the For component with an array of unique values, or at mapping directly.

Babel is not part of the setup. The feature list argues that plain old JavaScript plus JSX is enough, and reasons that having no transform means having zero transform related bugs, since there is no transform function to be buggy. The same reasoning produces the no magic claim: your code is not transformed to do something different from what you wrote.

Taken together these are the classic arguments for compiling away the virtual DOM, applied to a framework that removes the compiler as well. The cost is that the reactivity boundary becomes visible in your source. A component is a function that runs once, and the values it reads are subscriptions. That is closer to how a spreadsheet works than to how a template language works, and the feature list says outright that it may be more challenging to learn.

Hooks are plain functions, so there are no rules to follow

The hook system is where the difference in approach shows most clearly, because the constraints other frameworks impose are all listed as absent.

There are no rules of hooks. Hooks are regular functions, and you can nest them indefinitely, call them conditionally, or use them outside components. There are no dependency arrays, because the framework detects what depends on what else automatically. There are no stale closures, since functions are always executed afresh and you never have to think about previous potential executions of the current function.

That last point is a design claim with teeth, and it is the one to watch. Automatic dependency detection is only possible if the framework controls when and how a function re-executes, which means the function is not a closure you pass around but a tracked computation. Reading a signal inside it registers a dependency; writing to one inside it schedules an update. The absence of a rules-of-hooks order requirement follows from the same mechanism, and it is also what allows the framework to skip re-running a computation whose dependencies did not change.

The core hook list covers the usual ground with different names: useBoolean, useCleanup, useContext, useDisposed, useEffect, useMemo, usePromise, useReadonly, useResolved, useResource and useMicrotask. The web-oriented set adds useAbortController, useAbortSignal, useAnimationFrame, useAnimationLoop, useEventListener, useFetch, useIdleCallback, useIdleLoop and useInterval. useResource and usePromise together cover the asynchronous case, and the demo folders include a store counter and a creation example, which suggests the intended shape of that code.

A small exported surface built for tree shaking

The API is organised into six groups, and the shape of the table tells you what the author considers fundamental. Methods include $ and $$ for the low level entry points, batch, createContext, createDirective, createElement, h, hmr and html, plus isBatching. Components include Dynamic, ErrorBoundary, For, Fragment, If, KeepAlive, Portal, Suspense, Switch and Ternary.

The presence of both html and h alongside Dynamic and Portal is informative. A hyperscript entry point and an HTML template literal entry point both exist, and the demo directory has matching folders named html, hyperscript, creation and standalone, which points to a framework that can be used without a build step at all. There is also an hmr method and an hmr demo folder, so hot module replacement is part of the design rather than an afterthought.

Two entries deserve a note because they are unusual. KeepAlive implies caching of component state, and ErrorBoundary implies error handling at a component boundary rather than only at the root. Neither is common in a framework this young, and neither is described further in the feature list, so treat the names as a promise of capability rather than a specification.

The package is configured for tree shaking, with the sideEffects flag set to false, and the extras section of the API table lists Contributing, Globals, JSX, Tree Shaking and TypeScript documentation. The package is ESM only, with a main entry pointing at dist/index.js and types at dist/index.d.ts, and separate jsx-runtime and jsx-dev-runtime entry points for JSX compilation.

Running a demo is the shortest path to the API

The repository ships one demo per feature area, and the package scripts wire each one to a small directory, so exploring the framework means running a demo rather than reading documentation. The scripts in package.json look like this for the counter demo:

"dev:counter": "cd demo/counter && npm i && npm update && npm run dev",
"prod:counter": "cd demo/counter && npm i && npm update && npm run prod",

Each script enters the demo folder, installs and updates its dependencies, then runs that demo's own dev or production script. The same pattern exists for benchmark, boxes, clock, creation, emoji_counter and the rest. The demo folders list covers benchmark, boxes, clock, counter, creation, emoji_counter, hmr, html, hyperscript, playground, spiral, ssr_esbuild, standalone, store_counter, triangle and uibench.

The package itself is built with tsex, and the scripts section exposes clean, compile and compile:watch for that, so the build step is a TypeScript compile rather than a bundler plugin. The export map in package.json is explicit about the entry points:

".": {
  "import": "./dist/index.js",
  "types": "./dist/index.d.ts"
},
"./jsx-runtime": {
  "import": "./dist/jsx/runtime.js",
  "types": "./dist/jsx/runtime.d.ts"
},

There is no CommonJS condition in either entry, and the package sets the module type to module, so Voby is an ESM only dependency. If your application is still CommonJS, that is a decision to make before you start rather than after.

No hydration, no server components, no streaming

The absence of server support is listed as a feature, which tells you how deliberate it is. The framework is focused on local-first rich applications, and the documentation states that most server related features are not implemented: no hydration, no server components, no streaming.

That is a large boundary for a UI framework in 2026, and it is the one most likely to decide whether you can use Voby at all. A server rendered application needs hydration, and a streamed application needs a server component story. Voby offers neither, so the target is an application that runs in the browser and treats the server as an API it talks to. For a desktop-like editor, a local tool, or an offline-first app, that is exactly right. For a content site, a public dashboard or anything with a marketing page, it rules the framework out.

There is a demo directory named ssr_esbuild, so experimentation with server side rendering has at least been started, and the demo list includes a standalone and a playground example, both of which suggest the author cares about shipping something that runs without a server at all.

The other boundary is behavioural. The feature list warns that functions are always executed afresh, and the reactivity system is described as working very differently from a React-like system, which the author says may be harder to learn. The debugging story is not documented in what is visible here, so a team that lives in the devtools will want to establish their own mental model before committing to a large codebase in it.

Where Voby differs from Solid, in practice

Solid is the reference point the project itself sets, and the differences are concrete rather than cosmetic.

The first is the toolchain. Solid uses a custom Babel transform to compile away the virtual DOM while keeping the look of JSX with hooks. Voby removes the transform entirely and works with plain JavaScript plus optional JSX, which means the code you read is the code that runs, and there is no compiler step in between to produce a surprising result. The second is the API. The feature list says explicitly that the API is different, so knowledge of Solid transfers conceptually but not syntactically: Voby exposes methods such as $ and $$, components such as If, Switch and For, and a hook set whose names and responsibilities differ.

The third difference is the emphasis. Solid is a mature project with a large ecosystem and its own conventions, and the author recommends it as the more solid option. Voby is smaller, opinionated, and shaped by what one developer needed for one product, which is exactly what makes the API pleasant for that person and unproven for everyone else.

If you evaluate Voby, evaluate it against a real application rather than a counter demo. The fine-grained update path is the whole point of the project, and the honest question is whether the observable model becomes clearer or muddier once your components have real state, real async work and real conditional rendering. The demos in the repository, including the uibench and benchmark folders, are the closest thing to that test.

MIT licensed, version 0.58.1, and no tagged releases

The licence is MIT, and the repository root contains a license file. The package metadata lists the author as Matt Bartos with the url field pointing at open-storm.org, and the repository field pointing at github:fabiospampinato/voby, which differs from the vobyjs/voby location the project is published under. That mismatch is a small thing, but it is the kind of detail that makes a supply chain check awkward.

On maintenance, the facts are thin and worth stating plainly. The repository is not archived, and the last push was on 2026-07-17. The project has no GitHub releases, so there is no tagged version history to pin against and no changelog in the repository listing. The version lives in package.json at 0.58.1, which tells you the project is still pre-1.0 and that the number in your lock file reflects whatever the registry held when you installed.

The cost of that is upgrade friction. With no release tags, a breaking change to an internal API cannot be signposted the way a major version bump would signal it, and the version number alone is a weak signal of stability in a 0.x package. If you adopt Voby, pin the exact version, read the diff between the version in your lock file and the one on the registry before bumping, and keep the surface you use small, since the hook set and component set are what you would have to rewrite.

Editorial conclusion

Voby suits an engineer who wants Solid style fine-grained reactivity without a compile step, without a virtual DOM, and with an MIT licence they can read in an afternoon. It does not suit a team that needs server rendering, hydration or streaming, because the framework deliberately omits all three, and it does not suit anyone who wants a stable release channel, since the project publishes no GitHub releases and the version in package.json is 0.58.1. Before you build on it, check that the api surface in the README covers the hooks you need, confirm the version on npm matches the commit you are reading, and read the MIT licence file in the repository root, since there is no separate warranty or support commitment attached to the code.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. vobyjs/voby on GitHub