Vidact – a compiler that turns React into direct DOM operations
mohebifar
13 points
9 comments
September 02, 2026
Related Discussions
Found 5 related stories in 54.7ms across 5,346 title embeddings via pgvector HNSW
- Removing React.js from the codebase and adapting Htmx for UI interactivity (2023) Ralfp · 239 pts · July 27, 2026 · 53% similar
- Show HN: TermDOM – HTML, CSS and JavaScript (With a Real DOM) for TUIs and CLIs bikeshaving · 12 pts · August 11, 2026 · 46% similar
- Show HN: I built a zero-latency developer tool suite in pure Vanilla JavaScript AAPD_Studio · 19 pts · July 23, 2026 · 45% similar
- Show HN: DOM-docx – HTML to native, editable Word docs (MIT) fishbone · 143 pts · July 13, 2026 · 44% similar
- Scriptc by Vercel: TypeScript-to-Native compiler, no JavaScript engine in binary maxloh · 90 pts · July 26, 2026 · 43% similar
Discussion Highlights (7 comments)
mohebifar
I started Vidact as an experiment 6 years ago, an experimental compiler that takes React-style function components and hooks and compiles them into direct DOM operations. The basic idea is: keep React's programming model, but replace its runtime model. It was a very ambitious project back then, but recently, another project I was working on (grep.codemod.com) inspired me to rebuild this and I thought of using React compiler's analysis this time as it has already done most of the heavy lifting. With Vidact, a component runs once when it mounts. The compiler analyzes which expressions depend on which values and generates static update functions for them. When state changes, it directly updates the affected text node, attribute, conditional range, or list item. So instead of: state change -> rerender component -> create element tree -> reconcile -> mutate DOM it's closer to: state change -> run compiler-selected updater -> mutate DOM There is no Virtual DOM, no reconciler, no runtime dependency tracking, and React itself isn't shipped to the browser. The compiler is written in Rust and uses React Compiler's analysis infrastructure for AST/scope/HIR/CFG/SSA and dependency information, but Vidact has its own IR, DOM code generator, and runtime. I've also been experimenting with the same model for SSR/hydration and built Vidact Start around it, with file-based routes, loaders, SSR, hydration, and client navigation. One design decision I'm particularly interested in feedback on: Vidact fails compilation when it encounters React behavior it can't preserve rather than silently falling back to React or a slower runtime path. It's therefore intentionally a subset of React today. It's beta and there are definitely compatibility edges left to explore. I'm especially interested in cases where React semantics make static compilation fundamentally difficult, rather than just features I haven't implemented yet. Site: https://www.vidact.dev/ Source: https://github.com/mohebifar/vidact
akagusu
Is this for real?
LoganDark
Please don't use LLMs for landing pages. Regardless of how long you've been developing the project, many people base their first impressions on whether a real person curated the documentation and website. And if you didn't, then they might never even get to evaluating your code at all.
ramon156
something that i realisr with LLM-generated content is that I just get more confused every sentence. HOW does it work? WHAT does it do? When I see technology I want to figure out what it CAN'T do. For example, Rust can do web, but I wouldn't use Rust if I get to choose a simpler language.
didgeoridoo
If I’m understanding this right, you’re aiming at something like Svelte, but with React syntax?
isaachinman
Interesting project. Direct Tanstack integration would convince me to give it a go. No users are going to swap over to your bespoke routing API
mg1c
Not sure what this project is for... the only way to statically compile JSX into direct DOM mutations is to either castrate React's dynamic runtime flexibility and closure model, or break its semantics like SolidJS does (in this case worse because the lack of templating/syntax constraints just shifts the burden from the compiler to the developer).