Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JavaScript Is Enough

geajs.com

Post reply on HN
Print view View original

41–50 of 110 posts

Re: JavaScript Is Enough

#41

Post by dashersw »

skyturkish wrote: post #34

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

This is one reason Gea has lots of examples in the repository. It's an area of active development—I'm working on adding compiler support for more and more patterns. Basically, since we can analyze the code statically, and follow the dependencies even if they are destructured, we can create proxies or special handlers for each situation. It's a tiring job and unfortunately there's no one global, easy solution, especially as you pointed out, some of these patterns don't work in proxies. But I believe we cover an important base of idiomatic JavaScript right now, and I'm continuing with new releases to improve the compiler's handling on more exotic ways to write JavaScript.

Of course, one down-side of the compiler approach is, for example, if there's a statement you want to make reactive whose signature is only resolved in runtime (like a computed property name) it's practically impossible to wire. But Gea exposes enough of the underlying component structure so it's kind of straightforward for a developer to manually write an observer for these cases, and do the updates to static properties (that are rendered) in runtime.

Hope this clarifies the approach.

Re: JavaScript Is Enough

#42

Post by ludwigvan »

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?

Re: JavaScript Is Enough

#43

Post by mpalmer »

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.

Re: JavaScript Is Enough

#44

Post by dashersw »

s-y wrote: post #40
dashersw wrote: post #28

Earlier quoted context omitted.

Thank you! It's the author here. I thought hard about this, and one angle Gea is bringing is that the old is new again, that's why I harkened to a retro style. I also just plain love synthwave, so... :) but you are right, and as Gea matures I believe we will iterate on the homepage.

Bro, is there anything you haven't thought hard about? I read throughout the thread and the answers sound really LLM-y. Although these days we might be calling wolf about gusts of wind. Great framework tho. Awesome job.

Heh, sorry it comes across as LLM-y, honest and human-written answers here only. I'm tired of AI slop as much as the next guy, but, yes, I _really_ took my time with Gea. I've been working on writing JS frameworks for 15 years, this is actually the 3rd generation of similar ideas, following tartJS (2011) and erste & regie (2017-2019). It took me several years to solidify what I expect from this generation, and I've been working on Gea for the past six months. That's why I thought about and evaluated many aspects raised here.

And thank you!

Re: JavaScript Is Enough

#45

Post by bluegatty »

ludwigvan wrote: post #42

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 immutabil…

Thoughtful.

I suspect everything about react seems like a backflip to get access to things we kind of needed in the first place.

Reacts complexity I believe are due to the fact that it's an overlay onto a system with high impedance mismatch - only then some degree of inherent complexity.

Re: JavaScript Is Enough

#46

Post by puskuruk »

dashersw wrote: post #38
puskuruk wrote: post #35

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

I personally don't believe anything can beat hand-built and fine-tuned vanilla JS code, and in the benchmarks we see Gea beating vanilla JS implementation (for example in partial update or swap rows). One reason for this is Gea's compiler has special cases like row swap's to be as minimal calculations and DOM operations as possible. The compiler, also, is evolving to recognize more and more patterns, and compile them…

Thank you for your detailed answer!

Re: JavaScript Is Enough

#47

Post by slopinthebag »

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:

   window width: {window.innerWidth}
But it's not, it's just on objects that subclass a Store.

Re: JavaScript Is Enough

#48

Post by slopinthebag »

dashersw wrote: post #27
tkzed49 wrote: post #25

Earlier quoted context omitted.

you continue to contradict yourself by introducing concepts and saying they are not concepts. I get what you're trying to say, that React hooks have special semantics, and that your abstraction feels more "native". again, not sure how this is more "native" than Solid signals, just as an example.

You are bringing up an important topic. The way I see it is that Gea's Store is a plain old JS class. It's just a native class. There really is no special syntax you need to pay attention to. Whereas Solid signals require you to follow a specific syntax and approach, and has its own gotchas. Like, the language doesn't have a createSignal method by default, and you don't "execute" what look like values in JS as you ne…

What is the difference between mobx or solid stores or any of the reactive frameworks that do reactivity on proxy objects?

Re: JavaScript Is Enough

#49

Post by dangoodmanUT »

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

Re: JavaScript Is Enough

#50

Post by anamexis »

dashersw wrote: post #32
anamexis wrote: post #30

Earlier quoted context omitted.

I don’t know if I’d call it an idiom — rather I’d argue that in modern JavaScript, mutating passed objects is often an anti-pattern.

I personally agree. But the default expectation (and therefore the design) should follow the practices of the language. If JS allows mutations on the objects passed to a function to be reflected on the parent, I believe frameworks should follow this paradigm. And in the end in Gea developers have full control over this, just in the same way they do in real life. `child({ ...obj })` easily solves this, for example, in…

> But the default expectation (and therefore the design) should follow the practices of the language. If JS allows mutations on the objects passed to a function to be reflected on the parent, I believe frameworks should follow this paradigm.

Why? Why should frameworks be beholden to the mutation semantics of the language, particularly with JS where there is no choice of language in the browser? Why should frameworks follow this paradigm?

Post reply on HN