Live data from Hacker News

JavaScript Is Enough

geajs.com

21–30 of 110 posts

Re: JavaScript Is Enough

#21
post #11
post #4

You wrote and shipped this in three days, eh?

It was likely almost entirely AI-generated but there are two oddities: - MIT — Copyright (c) 2017-present Armagan Amcalar: It would be an interesting bout of hubris to give yourself a copyright that predates the beginning of the project by 9 years. - The README lists sizes as "kb" rather than "KB": I find it odd that it would get units wrong unless it was specifically instructed to do so?

Hi, the author here. Gea is built upon erste and regie that I released in 2017 and 2019. Hence the copyright. I thought a lot about this, also thought of releasing it as a new version of erste, but it would be too big of a change and re-imagination, and I didn't want to introduce the dichotomy and stress introduced by Angular 2.

Re: JavaScript Is Enough

#22
post #5

> 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?

Stores and Components are basic classes that don't introduce any new concepts (other than the fact that the JSX goes into the template method of the Component, and that they are reactive behind the scenes). There are no hooks like useState, and the design philosophy is that everything should feel as native and natural as JavaScript.

Re: JavaScript Is Enough

#23
post #12

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.

The bindings in Gea work just like in JavaScript. Two-way if an object is passed, one-way if a primitive is passed. I think it's best to stick to the idioms of the underlying language.

Re: JavaScript Is Enough

#25
post #5

> 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?

Stores and Components are basic classes that don't introduce any new concepts (other than the fact that the JSX goes into the template method of the Component, and that they are reactive behind the scenes). There are no hooks like useState, and the design philosophy is that everything should feel as native and natural as JavaScript.

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.

Re: JavaScript Is Enough

#26
post #14

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

Hi, the author of Gea here. I have a long history of thinking about one- and two-way bindings, and I believe JavaScript as the language has a great solution to this. If you pass an object to a function, it's two-way bound, and if you pass a primitive, it's one-way bound. So I built Gea to replicate this. If users choose to pass an object in a one-way bound scenario, they could create a new object and pass that in, an…

Thank you for your project, it's elegant! It's pretty obvious that one-way binding is a two-way binding with one of the roads not taken. I see that e.g. a careful naming scheme could make it obvious what is reactive, and what is not.

OTOH React arrived where it's now not by allowing a particular approach, but by enforcing it.

Re: JavaScript Is Enough

#27
post #25

Earlier quoted context omitted.

Stores and Components are basic classes that don't introduce any new concepts (other than the fact that the JSX goes into the template method of the Component, and that they are reactive behind the scenes). There are no hooks like useState, and the design philosophy is that everything should feel as native and natural as JavaScript.

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 need to do in Solid, and although I'm looking forward to the official Signal API, Solid isn't following that either.

That's basically how Gea is more native, because stores are plain classes. I hope this clarifies my point a little bit more.

Re: JavaScript Is Enough

#28
post #24

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

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.

Re: JavaScript Is Enough

#30
post #12

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.

The bindings in Gea work just like in JavaScript. Two-way if an object is passed, one-way if a primitive is passed. I think it's best to stick to the idioms of the underlying language.

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.
Post reply on HN