alt.hn

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?

by ludwigvan

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.

by nine_k

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

by dangoodmanUT

proceeds to introduce Stores and Components

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

by tkzed49

    Separating the read and write capabilities of a store provides a valuable
    debugging advantage.

    This separation facilitates the tracking and control of the components that
    are accessing or changing the values.

    import { produce } from 'solid';

    setStore(produce(state => {
      state.users[2]?.loggedIn = false; 
    }))

    It's just a native class. There really is no special syntax you need to pay attention to.

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.

by Acmeon

  store0.url = "...";
  store1.res = await fetch(store0.url);

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.

by apatheticonion

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.

by afavour

- would have preferred a syntax like svelte

by vivzkestrel

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

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.

by mpalmer