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

91–100 of 110 posts

Re: JavaScript Is Enough

#91

Post by mpalmer »

dashersw wrote: post #67
mpalmer wrote: post #62

Earlier quoted context omitted.

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

The value judgement implied in "invented concepts" is kind of weird, and maybe gets at a core difference in how you and I think about this.

Frameworks have APIs; they define concepts. Learning concepts isn't a bad thing in and of itself. Especially if they are concepts which let you model your application more succinctly and efficiently.

What you mean is that you are leaving it to the user to learn (or conceive of) additional concepts which are external to Gea to in order to build non-trivial reactive applications.

But "Gea requires you to write less code / know fewer concepts" can be reframed as "Gea opts out of solving some types of vanilla JS boilerplate for you". When you don't give your users "concepts", they're still going to end up writing a lot of code and learning concepts, just not within your API.

Re: JavaScript Is Enough

#92

Post by dashersw »

dashersw wrote: post #67
mpalmer wrote: post #62

Earlier quoted context omitted.

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

Thank you for the discussion, I find it very interesting and I'd love to understand how you think. Why do you think setStore and produce let you model your application more succinctly and efficiently than just a direct assignment?

And what kind of types of boilerplate do you see Gea is opting out of?

Re: JavaScript Is Enough

#93

Post by mpalmer »

dashersw wrote: post #92
dashersw wrote: post #67

Earlier quoted context omitted.

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.

Thank you for the discussion, I find it very interesting and I'd love to understand how you think. Why do you think setStore and produce let you model your application more succinctly and efficiently than just a direct assignment? And what kind of types of boilerplate do you see Gea is opting out of?

Let's briefly set aside your belief that because JS supports mutation, a framework should as well.

Immutability and one-way dataflow is an unquestionable productivity win. It eliminates an entire class of complexity, and results in well-defined boundaries for the components of your application. With two-way data binding, those boundaries have to be carefully recognized and preserved by the developer every time they touch the code.

So one place Gea won't save devs any time or grief is in testing. If any part of the app can affect any other part of the app, the surface area of a change very quickly becomes unknowable, and you are only as informed as your tests are thorough. Not boilerplate in the literal sense, but quite a bit of overhead in the form of combinatorial test cases.

Yes, JS has mutability. Yes, you can make two-way data binding work as a framework feature. That you should is an argument I don't think you've successfully made yet.

Let me ask - why do you think JSX lets you model your application more succinctly and efficiently than just a direct createElement call?

Re: JavaScript Is Enough

#96

Post by machiaweliczny »

Rookie mistake, you just conflating concepts pretending things don't exist. Good API is one that is minimal, explicit and acomplishes the job without conflating with somethings else. Congrats now I don't know if this variable is designed for rendering of state managements and when I will hit some perf issues will have no idea what causes this, same with some unintended state update or something like this. If you can do everything using same concept it's obviously harder to read as you need to simulate compiler in your head which is bad design.

Re: JavaScript Is Enough

#97

Post by dashersw »

mpalmer wrote: post #93
dashersw wrote: post #92

Earlier quoted context omitted.

Thank you for the discussion, I find it very interesting and I'd love to understand how you think. Why do you think setStore and produce let you model your application more succinctly and efficiently than just a direct assignment? And what kind of types of boilerplate do you see Gea is opting out of?

Let's briefly set aside your belief that because JS supports mutation, a framework should as well. Immutability and one-way dataflow is an unquestionable productivity win. It eliminates an entire class of complexity, and results in well-defined boundaries for the components of your application. With two-way data binding, those boundaries have to be carefully recognized and preserved by the developer every time they t…

I see your point. I designed Gea to be one-way binding only first, and then decided to add two-way binding for props passed as objects. People can still easily only use one-way binding. Maybe this becomes a preference in the compiler config?

The argument for Gea to support two-way binding is basically circular and I believe well-made at this point. I want a framework to respect a language. Breaking two-way binding when it's a concept in the underlying language is like breaking Liskov's Substitution Principle. You can do it, but you probably shouldn't.

JSX is more succinct and efficient than raw DOM API because it's declarative, where the raw API is imperative.

Re: JavaScript Is Enough

#98

Post by jazzypants »

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.

The React Compiler does not remove the virtual DOM. You literally cannot use React without a virtual DOM.
Post reply on HN