4 ms·

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

dashersw 8mo ago
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(...)`. MobX also comes with its own syntax. In the end Gea is basically as simple as a plain old JavaScript class, made reactive by its compiler.
- mpalmer 8mo ago
  > 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; }))
  - dashersw 8mo ago
    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.
    - mpalmer 8mo ago
      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.
      - pkomarov1 7mo ago
        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.
        mpalmer 7mo ago
        This content is generally unwelcome and appears to be generated, which is against HN commenting rules.
        dashersw 7mo ago
        Yeah, sure :)
    - dashersw 8mo ago
      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?

dashersw 8mo ago

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(...)`. MobX also comes with its own syntax. In the end Gea is basically as simple as a plain old JavaScript class, made reactive by its compiler.

mpalmer 8mo ago
> 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; }))
- dashersw 8mo ago
  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.
  - mpalmer 8mo ago
    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.
    - pkomarov1 7mo ago
      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.
      - mpalmer 7mo ago
        This content is generally unwelcome and appears to be generated, which is against HN commenting rules.
      - dashersw 7mo ago
        Yeah, sure :)
  - dashersw 8mo ago
    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?