React hooks always struck me as object-oriented programming reinvented through the back door of functions. We started with pure components, decided we needed state after all, and ended up with magic functions that stash and retrieve state from some hidden context — essentially re-deriving this with worse ergonomics and an implicit ordering contract. Some part of it was the functional language paradigms like immutability that were popular elsewhere at the time bolted on to JavaScript.

What I find refreshing about Gea is that it doesn't fight the language. Stores are classes. Computed values are getters. State mutation is just assignment. I've been waiting for a framework that embraces the actual paradigms of the language it's written in, rather than inventing a parallel universe of conventions. Excited to try this one.

That said, I'm genuinely curious where the edges are. Was React's complexity accidental due to its architecture or was it the price of solving genuinely hard problems (concurrent rendering, suspense boundaries, fine-grained error recovery) (which by the way most consumers of the library did not care that much about)?

Does Gea's simplicity hold up as apps get complex, or will we eventually hit patterns where the escape hatch is the complexity React already internalized?

Disclaimer: I only read description, did not try to code.

What I like: the smart compiler that determines the actual dependencies, no need to declare them. Apparently the compiler is so smart as to compute the DOM diffs at compile time, which eliminates the need for virtual DOM.

What kills it for me: the two-way binding. The binding should be one-way to preserve your sanity as the project grows. Two-way bindings allow to build highly reactive Ruby Goldberg machines where anything can trigger anything else, and you won't know, because it's just a mutation of a property somewhere, indistinguishable from a non-reactive mutation. Two-way bindings are callback hell squared.

I want one-way data binding, immutability, and basically FRP. The biggest demonstration of FRP's immense real-life success is not React. It's the spreadsheet.

This may be good for small pieces of interactivity. But I likely would go for HTMX for that.

Not to knock on the project - it's certainly interesting.

I find it funny that the headline is "JavaSCript is enough" - yet this is a compiler on top of JavaScript that introduces magic and behavioural changes to syntax. How well does this work with testing frameworks? Can this run without the compiler?

A lot of the thinking behind this compiler comes out of the box with Rust. If only wasm worked.

This clearly AI generated website is such a turn-off.

I get that AI can be good at making websites, and someone might not care to spend a lot of time on it, but a website that looks like a slightly modified version of a generic "make an X landing page" from gpt-5.3-codex doesn't scream "I care about what I just made".

Just go super reductionist like planetscale did and have partially rendered markdown, don't put twinkling stars in the background

Two-way props! Yikes! That was a mess in the first version of Angular. I thought the consensus was that two-way props binding just opened the door to difficult to understand side-effect laden code.

Looks quite cool! I have also considered similar ideas, but have decided to not develop anything. However, there are a few important areas where we have different points of view. My main use cases relate mainly to computationally demanding applications and, thus, runtime performance is quite important.

First, the claim that one gets "reactivity for free" is not entirely true (although the costs may be negligible for many apps). The stores are wrapped in proxies, which lowers the performance of, for example, property access. This is why I rejected the idea of proxies and instead considered generating getters and setters to handle reactivity. This could, in principle, enable zero overhead reads (assuming that all the reactivity stuff were to be handled in the setter). However, this approach fails to account for, for example, array mutations. Thus, I see the point in proxies, but the cost of them can be significantly lowered performance (which may not matter for all applications).

Second, not memoizing computed values (i.e., getters) can also have a significant negative impact on runtime performance, because expensive computations may have to be executed many times. I suppose that caching could be offloaded to the developer, but this could be laborious, at least if the developer would have to keep track of when to invalidate the computation. In, for example, Excel, computed values can be accessed fast, because they are stored in memory (although the added memory usage can become a problem).

Third, you have not addressed async stores or async computed values (as far as I can tell). I will admit that considering async can be quite complicated. However, for better or worse, async is still a key part of JavaScript (e.g., sync alternatives do not exist for all APIs). Thus, the claims "JavaScript is enough", "Zero Concepts" and "You already know the entire API" are slightly imprecise, because async is not supported (although, this does not necessarily matter for many applications).

These three points were the main reasons why I chose not to pursue my similar ideas (especially in the context of computationally demanding applications). Still, I find the idea that JavaScript should be enough for reactivity to be compelling and worthwhile of further development.

> Solid has signals and createEffect... Gea takes a different path. It introduces no new concepts at all.

proceeds to introduce Stores and Components

what makes this magically easier than Solid, or any other Proxy-based reactive store frameworks?

- would be nice if it wasnt using JSX

- would have preferred a syntax like svelte

React is just JavaScript. Also vanilla JavaScript is just JavaScript

You wrote and shipped this in three days, eh?

I click, then I see an AI generated website, and AI generated pixelart. Then I leave.

There are many ways to write JavaScript, for example by destructuring variables, etc. How do Gea proxies work to retain reactivity then?

hey! Great job on this, dashersw. I‘ve believed for a while now that the compile time dependency analyzer approach is the only good way for frameworks like this. Really neat choices on the API surface as well – so simple! Launching with a headless UI lib is smart. will try both in a side project soon! thanks and cheers!

> The Vite plugin analyzes your JSX at build time, figures out which DOM nodes depend on which state, and wires up surgical patches — invisibly.

This part interests me… if it’s able to be brought to React somehow. Too many sites are shipping entirely reactive DOMs where only a tiny minority of content actually changes.

The fact that the entire project appears to have been written in three days, however, gives me some deep doubts.

How does this thing run so close to VanillaJS without carrying any extra baggage along for the ride?

undefined

At first I thought this was using a compiler to figure out data dependencies on regular javascript objects, including built in's on the window and coming from third party dependencies, so you could do this:

   <div>window width: {window.innerWidth}</div>

But it's not, it's just on objects that subclass a Store.

The contrast of most of the text against the background is not accessible.

I'm not overly impressed with the claim "Faster than Solid" when only figure presented on the hero chart is the geometric average of the Duration scores for each framework.

Digging into the individual metrics, Solid is well within the margin of error on essentially every metric to tie or even beat Gea.

On top of that, Solid beats Gea handily on bundle size, 1:4 uncompressed and 1:2 compressed.

So at best, Gea is a tie on speed with Solid, the bundle is bigger, and even time to first paint is a little worse.

Not a JS dev but the site need to move away from tinted retro look if you want to stress the modernness.

[dead]

[dead]

[dead]

[flagged]

[flagged]