3 ms·
> The problem with these libraries are significant ramp up time. Unlike what the authors are claiming it’s not because it’s a difficult or greatly different men
by lorean_victor 7y ago
> The problem with these libraries are significant ramp up time. Unlike what the authors are claiming it’s not because it’s a difficult or greatly different mental model to grasp, it’s because the API is clunky and poorly designed.
Regardless of the quality of API design, reactive programming (and by extension RxJS) does indeed require a different mental model, as it is a different model for the flow of a program.
> You’ll notice most of the popular and highly successful abstractions all share the common trait of being easy and quick to pick up.
That is subjective. I remember how many people found node's async callback style unintuitive and confusing on first sight, and I personally find (at least the core abstractions of) RxJS pretty intuitive.
> If the author’s haven’t factored in ease of use and uptake it’s already failed at its first principles.
Yes this is part of the goal with CONNECTIVE, to bridge the gap between the description of a reactive flow (the code) and the most intuitive way to think about it (a directed graph), so that the end-result would be much more easily readable and intuitive code. I would love to hear if you have any more specific feedback on this front.
- karmakaze 7y agoI don't believe this is the 'most' intuitive. A spreadsheet is a directed graph but that's not how people think when they use it--they just write function expressions. Svelte 3 does a better job of making it intuitive. [0] https://svelte.dev/blog/svelte-3-rethinking-reactivity https://svelte.dev/blog/svelte-3-rethinking-reactivity
- lorean_victor 7y ago> Svelte 3 does a better job of making it intuitive. It might just as well be the case. Svelte is going is towards traditional reactive programming languages, which for example because of the implicit change propagation, typically bare the possibility of glitches, which translates into unreliability on the most basic level of the program. I do not know how Svelte 3 handles glitches (or change propagation for that matter), but am just mentioning this as a one of the hurdles of that approach that actually makes it less intuitive (though definitely it looks more magical). > A spreadsheet is a directed graph but that's not how people think when they use it--they just write function expressions. That is true, though people also do not utilize spreadsheets to even one percent of what is possible to do with them, mostly due to the fact that the representation masks the directed graph and makes it harder for people to think of a little bit more complex things they can achieve with it. Saying this as a person who (with a friend) has created a full-blown CRM using google sheets. > I don't believe this is the 'most' intuitive. I can't (and didn't) claim it is either. I just suspect it is a really intuitive model since it reflects the actuality of what is being programmed. EDIT: on closer inspection of Svelte 3's implementation of reactivity, it seems that they are not actually implementing support for reactive programming, just keeping the DOM reactive to variable changes in a transient way. This of course means that it will (most probably) not result in glitches, since its not true reactive programming. On this front it is notable that: 1) CONNECTIVE (and RxJS) are general-purpose libraries, not just for front-end, 2) I suspect that mere DOM reactivity of Svelte will also not hold up in more complex front-end settings, where you would need (and benefit from) proper reactive logic.