Coi compiles a component language to WebAssembly with no virtual DOM

A language, not a framework, and the author says so plainly

Coi is described as a type-safe, component-based language for building reactive WASM web apps, and the README's own framing is the most important thing to understand before you evaluate it. Coi isn't another JavaScript framework, it's a new language for the web, built from scratch to feel like a component framework but compile to high-performance WebAssembly.

The stated payoff is static types, strict checking and native-speed execution without the overhead of a heavy JavaScript runtime. The project also carries a note that Coi is in early development, that things change fast, and that it is not ready for production but is suited to experimenting, especially for people who want to influence where the language goes.

That combination, a new language plus an explicit invitation to shape it, defines the audience. This is a project for people who want to participate in a language's design rather than consume a stable one. The homepage is coi.github.io/coi, and the topics list covers compiler, fine-grained-reactivity, reactive-ui, wasm, programming-language and deterministic-performance.

The language is written in C++, and the repository root shows a build.sh, a build.ninja, defs/, deps/, src/, templates/, tests/ and an example/ directory.

Fine-grained reactivity replaces the virtual DOM

The architectural claim is about how updates reach the browser. Coi uses a fine-grained reactive system, and instead of diffing a virtual tree in JavaScript, the compiler generates direct, surgical DOM updates triggered by WASM logic. The README says this eliminates VDOM overhead and minimizes the work the browser has to do.

The language features around that are what make the approach usable. State is passed by reference with `&` for parent-child synchronization, and there is explicit move semantics with `:` to prevent accidental copying. Component members are private by default and you expose them with `pub`.

The reactive model is visible in the type system, not just the runtime. The example declares a `pod Task` structure with an int id, a string text and a Status enum field, then a component with `mut Task[] tasks` and `mut int nextId`, and the mutability is explicit in the declaration rather than inferred. The toggle function mutates a task's status through a match on the enum, and the view block binds the click handler to that function.

The contrast with a virtual DOM is the point of the whole design, and it is also where the honest caveat lives. Direct updates require the compiler to know precisely which state change caused which DOM mutation, which is a much tighter coupling between the reactive graph and the generated code than a diffing approach allows.

Components carry their own markup, styles and lifecycle

The component model is close to what a frontend developer would expect, and the syntax is worth reading closely.

You write HTML elements and scoped CSS directly inside a component. The style block in the example defines an .app class with padding and a system font, and a .done class that strikes through and greys the text, and both are scoped rather than global. The view block uses declarative control flow with `<if>`, `<else>` and `<for>` tags rather than a templating language, and the `<for>` tag carries a `key` attribute, which is a familiar signal for anyone who has used keyed list rendering in a framework.

Lifecycle is built in as named blocks: `init {}` for setup, `mount {}` and `tick {}` for the component lifecycle. The example puts the two initial tasks into the array inside `init`.

Platform APIs are typed. The README lists full type safety for Canvas, Storage, Audio, Fetch and other browser APIs, so calling the wrong method on a storage object is a compile error rather than a runtime one.

The declaration at the end of the file is the application entry point, with a root component, a title and a description, and the last of those is what the browser tab and any social preview would use.

Building the compiler, then a project with the CLI

Building Coi needs Clang 16 or newer for full C++20 support, with the README giving the package commands for Ubuntu and Debian, macOS and Fedora, and then the build is two commands:

git clone https://github.com/coi/coi.git
cd coi
./build.sh

After that, a project is created and run with the CLI:

coi init my-app
cd my-app
coi dev

And the dev server is at http://localhost:8000.

The command table is longer than a typical new project tool, and the entries tell you what kind of project this is becoming. There is `coi init [name]` to create an app and `coi init [name] --pkg` to create a package, `coi build`, `coi dev` with hot reload and a `--no-watch` variant, and a package manager with `coi add <package> [version]`, `coi install` reading from coi.lock, `coi remove <package>`, `coi upgrade [package]`, `coi list` and `coi self-upgrade`, which pulls the latest Coi source and rebuilds the compiler itself.

Two entries are unusual. `coi version` reports the compiler version, and `coi llms [--path]` prints the full language context for AI assistants, with the path variant printing where that file lives. The repository ships llms.txt and llms-full.txt at the root, which is what that command is presumably serving, and for a language this new, having the grammar available in a form a code assistant can read is a practical convenience rather than a gimmick.

The bundle size claim, and what the benchmarks actually compare

The headline claim is about bundle size. In the counter app example, Coi is described as 40% smaller than Svelte, 72% smaller than Vue and 88% smaller than React, with the results linked to a separate benchmarks repository.

The benchmark setup is described in the Benchmarks section, and the framing is careful. It compares Coi, React, Vue and Svelte, and says Coi delivers the smallest bundle size and competitive DOM performance, with a chart embedded in the README.

Two things are worth holding onto. First, the figures come from the project itself, and the README points to a separate repository for the methodology, so the comparison is at least inspectable rather than asserted. Second, the measurement is a counter app, which is a small and unrepresentative program, and bundle size for a WASM-compiled language depends on how much of the standard library and runtime you ship, which is a compiler and linker decision as much as a language decision.

The performance argument is framed differently from the size argument, and more plausibly. The claim is that no garbage collection pauses means consistent 60fps animations and responsive interactions, and that computation-heavy features run at native speed, which the README suggests for simulations, physics, data processing and canvas-based apps. That is the case for a WASM target: the work happens in the same place as the animation, rather than crossing a boundary into JavaScript on every frame.

Editorial conclusion

Adopt Coi if you want to experiment with a language that compiles to WebAssembly and gives you static types and direct DOM updates without a virtual DOM, especially if you want to shape the language while it is young. Do not adopt it for a production application, because the README says it is in early development, not ready for production, and that things change fast. Before you start, read the language guide and the components documentation, check the benchmark results in the separate benchmarks repository rather than relying on the headline numbers, and note the release picture, where the repository publishes no tagged releases and the last push was on 2026-10-22.

Frequently asked questions

Official sources

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