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

61–70 of 110 posts

Re: JavaScript Is Enough

#61

Post by dashersw »

mpalmer wrote: post #57
dashersw wrote: post #27

Earlier quoted context omitted.

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…

It's just a native class. There really is no special syntax you need to pay attention to. Don't confuse syntax with code. Solid has no special syntax (other than JSX of course). This isn't comparing apples to apples. Solid has a Store primitive too, and it's a "plain old" proxied object. How is `createStore` less native than `new Store()`? The `new` keyword didn't even exist in JS until 2015, and the underlying seman…

I'm not following—the `new` keyword has been with us since JavaScript's inception. You might be confusing it with the `class` syntax, but before that we could always `new` functions.

And yes, Solid has signals that require you to know how to write and work with them. I answered another comment on the thread about Solid stores—they also introduce a couple of gotchas and weird syntax. You just can't do `this.users.push(...)` or `this.users[2].loggedIn = true` in Solid stores.

Therefore `createStore` is less native than `new Store()`, because `new Store()` just gives you a plain (proxied) object you can manipulate in various ways and reactivity will persist thanks to the compiler.

And Gea's design goal is also fine-grained reactivity, which it delivers without getter functions in the code that the developer writes, but rather, the handlers are generated via the compiler.

Re: JavaScript Is Enough

#62

Post by mpalmer »

dashersw wrote: post #59
slopinthebag wrote: post #48

Earlier quoted context omitted.

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

Solid stores are a great improvement over raw signals, but they still come with their own gotchas. First off, it's an entirely new syntax. You need to learn its documentation. You always have to use setStore, and it has a weird syntax like `setStore("users", 2, "loggedIn", false)` and even pushing items to an array is weird. In Gea it's just regular JavaScript: `this.users[2].loggedIn = false` or `this.users.push(...…

> You always have to use setStore

This is a design choice, and explained in their docs:

    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.
> You need to learn its documentation. You always have to use setStore, and it has a weird syntax like `setStore("users", 2, "loggedIn", false)` and even pushing items to an array is weird.

It's optional, and incidentally quite expressive and powerful. But they also support mutable drafts out of the box.

    import { produce } from 'solid';

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

Re: JavaScript Is Enough

#63

Post by dashersw »

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.

Re: JavaScript Is Enough

#64

Post by dashersw »

bythreads wrote: post #58
dashersw wrote: post #51

Earlier quoted context omitted.

Thank you for the thorough comments! I wholeheartedly agree. And while I believe React invented most of its problems (mostly because we've been engineering GUI solutions since mid-70's and, as I always say, Excel, the god of all UI apps, shipped in 1985) I also acknowledge modern problems like suspenses that occur as a result of elevated expectations. Gea is frankly very new, and for example doesn't ship a solution f…

Would love to se tagged template Literals and w eb components as first citizen in this - lit.dev etc.

In fact the precedent to Gea, my previous framework erste made use of `pug` tagged template literals! I started with that base, but then decided to ship with JSX instead. This would be a great addition to Gea and would love to see it as a community contribution. I'm hesitant about web components but if we could help web components to feel more "plain old JS" to write, it would be awesome!

Re: JavaScript Is Enough

#65

Post by dashersw »

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.

Yeah afaik React Compiler doesn't really replace virtual DOM.

Re: JavaScript Is Enough

#66

Post by mpalmer »

dashersw wrote: post #56
mpalmer wrote: post #43

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

Solid is honestly a beast, and I love it! It was a great challenge to even match its performance, let alone beat it. While on several metrics they are within margin of error, select row, swap rows, remove row, and clear rows performances are significantly better on Gea's side. Having said that, pure performance wasn't the goal as much as the developer experience. I wanted to build something that felt _native_ to the…

It's impressive for sure!

But all of those metrics differ by something like 1 millisecond, and you've only got benchmark data from an M4 Macbook Pro. On the strength of this, you promise us:

"The fastest compiled UI framework — ahead of Solid, Svelte, Vue, and React."

I know you've put quite a bit of work into the underlying libraries here, but this is the sort of claim people are sure to poke at. Is the Gea code used in the benchmark published anywhere?

Re: JavaScript Is Enough

#67

Post by dashersw »

mpalmer wrote: post #62
dashersw wrote: post #59

Earlier quoted context omitted.

Solid stores are a great improvement over raw signals, but they still come with their own gotchas. First off, it's an entirely new syntax. You need to learn its documentation. You always have to use setStore, and it has a weird syntax like `setStore("users", 2, "loggedIn", false)` and even pushing items to an array is weird. In Gea it's just regular JavaScript: `this.users[2].loggedIn = false` or `this.users.push(...…

> You always have to use setStore This is a design choice, and explained in their docs: 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. > You need to learn its documentation. You always have to use setStore, and it has a weird syntax like `setStore("users", 2…

I understand this bit. The bit that I don't understand is how you compare the two invented concepts like `setStore` and `produce` to just `state.users[2]?.loggedIn = false`. To me it's very clear Gea's syntax requires you to write less code, while also requiring you to know less concepts.

Re: JavaScript Is Enough

#68

Post by dashersw »

mpalmer wrote: post #66
dashersw wrote: post #56

Earlier quoted context omitted.

Solid is honestly a beast, and I love it! It was a great challenge to even match its performance, let alone beat it. While on several metrics they are within margin of error, select row, swap rows, remove row, and clear rows performances are significantly better on Gea's side. Having said that, pure performance wasn't the goal as much as the developer experience. I wanted to build something that felt _native_ to the…

It's impressive for sure! But all of those metrics differ by something like 1 millisecond, and you've only got benchmark data from an M4 Macbook Pro. On the strength of this, you promise us: "The fastest compiled UI framework — ahead of Solid, Svelte, Vue, and React." I know you've put quite a bit of work into the underlying libraries here, but this is the sort of claim people are sure to poke at. Is the Gea code use…

Thank you! And you are right. I hadn't submitted it to the original js-framework-benchmark repo yet, but I just added the benchmark code on gea's repo. You can find it on https://github.com/dashersw/gea/blob/main/benchmark/src/benc..., and the store on https://github.com/dashersw/gea/blob/main/benchmark/src/stor...

Re: JavaScript Is Enough

#69

Post by dashersw »

afavour wrote: post #8

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

I wish I could bring it to React! That would save so many developers and so much natural resources!

I've been working on the library for 6 months, and it's built upon my previous libraries tartJS (2011), erste (2017) and regie (2019). I just like to squash my commits before I make a public release, and that just happened 4 days ago :)

Re: JavaScript Is Enough

#70

Post by dashersw »

anamexis wrote: post #50
dashersw wrote: post #32

Earlier quoted context omitted.

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…

Because JavaScript _is_ the language and people know it. I never understood the concept of a "React developer", for example, although I saw many junior devs who were very well-versed in React and didn't completely understand JavaScript.

In the end, it's a design choice. Of course frameworks don't inherently _need_ to be beholden to the standards of the underlying language, but I think this is just simpler, therefore a worthy goal to pursue.

Post reply on HN