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?

▲

dashersw 3 days ago | parent [-]

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.

▲

mpalmer 3 days ago | parent | next [-]

> Maybe this becomes a preference in the compiler config?

Maybe, but it could be more complicated for you, the maintainer, than it's worth!

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

But that's also the difference between (e.g.) Solid's signals vs a plain (proxied) object that's passed around and mutated. I'd go so far as to say that mutable objects are one of the most "imperative" things about JS.

▲

dashersw 3 days ago | parent [-]

I don't want to recurse into philosophy but one could argue an assignment is more declarative than a function call :) Solid is function calls everywhere, and extra code, vs plain objects.

▲

mpalmer 3 days ago | parent [-]

Plain objects whose accessors contain nontrivial logic deferred using function calls - to be fair

	▲	dashersw a day ago \| parent [-]
		I am pondering about this, but would love to see an example to make it more concrete. The way I see it is that this reactivity is completely on the compiler's side, and there's no more ambiguity or pitfalls than misrepresenting a dependency array in a react hook.

▲

mpalmer 3 days ago | parent | prev [-]

Should an application framework written in Rust encourage the usage of `unsafe` blocks in application code? It certainly allows for more power and flexibility, and it's supported in the language.