Earlier quoted context omitted.
That is a remarkably pedantic nitpick. If you're going that far, you should really be complaining that it's not "KiB".
I don't think it's pedantry, it's looking for clues as to the age of this.
nah, it's pedantic
JavaScript Is Enough
101–110 of 110 posts
Re: JavaScript Is Enough
#102Earlier quoted context omitted.
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 wh…
> 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.
Re: JavaScript Is Enough
#103Earlier quoted context omitted.
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 wh…
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.
Re: JavaScript Is Enough
#104Earlier quoted context omitted.
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 wh…
> 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 object…
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.
Re: JavaScript Is Enough
#105Earlier quoted context omitted.
> 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 object…
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.
Plain objects whose accessors contain nontrivial logic deferred using function calls - to be fair
Re: JavaScript Is Enough
#106Earlier 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…
> `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.
Feel free to question anything you like and I'll help you find the answers.
This is a well-trodden path. All aspects of object mutation and its effects are obvious and well-known. What is pass by ref and what is pass by val is also pretty obvious. One can easily pass in primitive values and not worry about two-way binding if they choose to. One can also easily not mutate any props they receive from their parents. This is already the best practice in eslint for like 10 years. This is not easy, this is trivial.
I'd rather see some real concerns.
Re: JavaScript Is Enough
#107Earlier 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.
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) a…
I see mpalmer counters each specific claim, dashersw shifts to a slightly different argument rather than directly addressing the rebuttal.
One guy is doing the tech founder equivalent of a TED Talk ("my thing is more native and requires fewer concepts!") while another is quietly pointing out that the emperor has no clothes, and has receipts. One keeps doubling down because this is clearly his baby, while other is just some experienced dev who's watched too many "simple mutable state" frameworks turn into maintenance nightmares. One person is selling a vision. The other is explaining why that vision has been tried and mostly rejected by the industry for good reasons.
Only one of them is learning from the conversation.
Re: JavaScript Is Enough
#108Earlier quoted context omitted.
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) a…
I see mpalmer counters each specific claim, dashersw shifts to a slightly different argument rather than directly addressing the rebuttal. One guy is doing the tech founder equivalent of a TED Talk ("my thing is more native and requires fewer concepts!") while another is quietly pointing out that the emperor has no clothes, and has receipts. One keeps doubling down because this is clearly his baby, while other is jus…
This content is generally unwelcome and appears to be generated, which is against HN commenting rules.
Re: JavaScript Is Enough
#109Earlier quoted context omitted.
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) a…
I see mpalmer counters each specific claim, dashersw shifts to a slightly different argument rather than directly addressing the rebuttal. One guy is doing the tech founder equivalent of a TED Talk ("my thing is more native and requires fewer concepts!") while another is quietly pointing out that the emperor has no clothes, and has receipts. One keeps doubling down because this is clearly his baby, while other is jus…
Yeah, sure :)
Re: JavaScript Is Enough
#110Earlier quoted context omitted.
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.
Plain objects whose accessors contain nontrivial logic deferred using function calls - to be fair
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.