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

81–90 of 110 posts

Re: JavaScript Is Enough

#81

Post by dashersw »

apatheticonion wrote: post #80

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.

Heh, sorry, I (the author) wasn't the one who created the post. But the idea is reactivity in JS shouldn't require new syntax.

Gea works best with the compiler, I documented a non-compiled (only compiles JSX) browser usage here: https://geajs.com/docs/browser-usage.html but this obviously requires manual store observers and manual DOM updates, which means it's not _really_ benefiting from Gea.

Re: JavaScript Is Enough

#83

Post by dashersw »

vivzkestrel wrote: post #82

- would be nice if it wasnt using JSX - would have preferred a syntax like svelte

Gea in fact supports regular HTML strings out of the box—that's what the compiler turns the JSX into anyway. However IDE tooling is still in the works for syntax highlighting regular HTML.

What syntax would you prefer from Svelte? Like for hooks / stores, or rendering?

Re: JavaScript Is Enough

#85

Post by slopinthebag »

dashersw wrote: post #63
slopinthebag wrote: post #47

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.

This is an interesting idea, though, thanks for bringing it up! I will think about it and try to add it to the compiler. Especially native objects like `window` would be great to create handlers for in the compiler. It would make life really easy for the developer.

Yeah, I experimented with this a while ago, basically compile templates to get their dynamic data dependencies and then poll them for changes, although I did it at runtime. I was able to have thousands of components running with fairly minimal cost, turns out strict equality checks are pretty cheap, although there was issues with defining custom objects or anon functions inside the template. A compiler could be much smarter about this, including nested field access on objects, ignoring temporary objects and functions, and deduping checks so only the minimal amount of values would be polled each frame. Values out of the viewport can "sleep" or be polled on a lower frequency. It's kind of an interesting paradigm because it doesn't require anything on the part of the developer to write their state management in a specific way or to wrap third party dependencies in a reactive wrapper.

Of course polling is not fashionable as it's seen as "crude" or "unoptimised" but typically most UI's only have a few dozen input sources at most visible on a screen, and polling that amount of data amounts to less than a ms even on slower mobile hardware. In extreme cases with thousands of data points the compiler could be smart and "short-circuit" the checks, or the component could opt into manual update calls.

But it's super powerful to have what amounts to true immediate mode UI, the entire issue of state management basically goes away. `window.state` becomes a perfectly viable option haha.

Anyways, cool framework.

Re: JavaScript Is Enough

#87

Post by ksh09 »

wg0 wrote: post #52
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…

You can now use React Compiler and there would be no virtual DOM. Already being used in production at large code bases.

I genuinely don't know what lead to the compilers when we already had a simpler concept of signals.

Re: JavaScript Is Enough

#89

Post by dalmo3 »

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…

> `child({ ...obj })` easily solves this, for example

Spreading doesn't prevent you from mutating nested fields. The fact that you think this is an easy problem puts all your other choices under question.

Post reply on HN