I was about to comment this. The selling for svelte has always been that the compiler will output just the needed instructions for the expressed transformation. No virtual DOM.
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).
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.
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.
React code looks so ugly to my taste. Try reading it: "use state zero". What does it even mean? And why "const" is used for a value that changes?
const [count, setCount] = useState(0)
I didn't understand how the compiler works completely, but I assume it tries to figure out the dependencies during compilation time ("The text of node Y depends on variable x"). This approach is closer to Vue's approach which uses proxies to find these dependencies in runtime, than React's approach which renders the new tree, diffs it against the DOM and applies changes. So it is unclear why React was used for input instead of Vue here. Furthermore, as I remember, Vue has templates implemented as HTML (including attributes for branches and loops) so it would be easier to parse than raw JS code used by React.
Another problem is that those dependencies are often unknown at compilation stage. For example, imagine a form which is generated dynamically based on list of fields received from the server and should show error boxes when invalid values are entered. The compiler won't be able to pre-compute the dependencies here because it doesn't know what DOM nodes will exist at runtime. I assume the compiler would figure out a dependency between a variable with list of fields and "form" DOM node, but not dependencies between entered data and error boxes visibility.
Sadly the website doesn't provide examples of generated code so I cannot confirm my guess.
Anyway, interesting idea. Sometimes I draft reactive frameworks on paper so I understand the challenges a little bit.
Also what I do not like in reactive frameworks as that they are invasive and require you to adapt the code for them. For example, I might have my object model (let's say a TextDocument class with lot of nodes inside), and all I need is a "View" that would display it. But React requires you to move the data into props and state, and sometimes use a giant immutable object that gets rebuilt on every user action, and Vue wraps everything with proxies which causes lots of small issues and confusion (like putting a proxy into the Set instead of original object). And also React requires installing Node and compilation which is too much for a one-page quick project. So what I want is that I pass my Document Object Model and framework just displays it without making me adapt to its architecture. For example, I pass a model of a text document and it just displays it. Without immutability, without proxies, and without writing a giant switch with all possible user commands (I think they call the approach with a large switch and immutable objects "redux"). I do not need redux, I just want to use classic MVC from 80s and not modern dubious ideas. I have M and C and only need a V.
It is real but still experimental. Gotta test it in small apps first. I will move grep.codemod.com (currently vanilla js) this week to Vidact to try it out in production.
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.
React’s programming model, compiled.
The successor to Inferno, built around the same focus on performance. It brings React’s hooks, Suspense, and actions to a compiler-first architecture.
No virtual DOM, rules of hooks, or dependency arrays you have to maintain yourself. The compiler tracks what your code uses automatically.
If I’m understanding this right, you’re aiming at something like Svelte, but with React syntax?
I was about to comment this. The selling for svelte has always been that the compiler will output just the needed instructions for the expressed transformation. No virtual DOM.
What Svelte used to be pre version 5 I think? They now also have a runtime with hooks, etc
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).
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.
Thanks. I totally hear you and that makes sense. Content is not my forte and I get lazy when it comes to that. Will improve it.
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
Missed opportunity to call this Rawact
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.
React code looks so ugly to my taste. Try reading it: "use state zero". What does it even mean? And why "const" is used for a value that changes?
I didn't understand how the compiler works completely, but I assume it tries to figure out the dependencies during compilation time ("The text of node Y depends on variable x"). This approach is closer to Vue's approach which uses proxies to find these dependencies in runtime, than React's approach which renders the new tree, diffs it against the DOM and applies changes. So it is unclear why React was used for input instead of Vue here. Furthermore, as I remember, Vue has templates implemented as HTML (including attributes for branches and loops) so it would be easier to parse than raw JS code used by React.Another problem is that those dependencies are often unknown at compilation stage. For example, imagine a form which is generated dynamically based on list of fields received from the server and should show error boxes when invalid values are entered. The compiler won't be able to pre-compute the dependencies here because it doesn't know what DOM nodes will exist at runtime. I assume the compiler would figure out a dependency between a variable with list of fields and "form" DOM node, but not dependencies between entered data and error boxes visibility.
Sadly the website doesn't provide examples of generated code so I cannot confirm my guess.
Anyway, interesting idea. Sometimes I draft reactive frameworks on paper so I understand the challenges a little bit.
Also what I do not like in reactive frameworks as that they are invasive and require you to adapt the code for them. For example, I might have my object model (let's say a TextDocument class with lot of nodes inside), and all I need is a "View" that would display it. But React requires you to move the data into props and state, and sometimes use a giant immutable object that gets rebuilt on every user action, and Vue wraps everything with proxies which causes lots of small issues and confusion (like putting a proxy into the Set instead of original object). And also React requires installing Node and compilation which is too much for a one-page quick project. So what I want is that I pass my Document Object Model and framework just displays it without making me adapt to its architecture. For example, I pass a model of a text document and it just displays it. Without immutability, without proxies, and without writing a giant switch with all possible user commands (I think they call the approach with a large switch and immutable objects "redux"). I do not need redux, I just want to use classic MVC from 80s and not modern dubious ideas. I have M and C and only need a V.
Is this for real?
It is real but still experimental. Gotta test it in small apps first. I will move grep.codemod.com (currently vanilla js) this week to Vidact to try it out in production.
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
It seems close to https://octanejs.dev/
Also do you have any benchmark like https://krausest.github.io/js-framework-benchmark/current.ht...This comment is 10x more useful than your website. I'd suggest moving most of this copy onto the site just in a better format.
I would suggest adding a readable and formatted example of compiled code.