alt Hacker NewsThank 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?