4 ms·

When working in the [react] ecosystem I feel like I'm constantly trying to couple together chains that call functions on functions on objects. This is a

When working in the [react] ecosystem I feel like I'm constantly trying to couple together chains that call functions on functions on objects. This is a very good explanation of how I feel as well. At work I use React, but on sideprojects I'm a Vue fan. React feels like layers and layers of render functions, with chains passed down and pared down as you get deeper, which becomes excessively cumbersome to reason about. Vue feels like it compartmentalizes things much more effectively. A component can just be a component, not a stateless function that renders a react component that wraps around a redux plugin component, with each step having its own little isolated DSL.

anonytrary 8y ago
> React feels like layers and layers of render functions, with chains passed down and pared down as you get deeper, which becomes excessively cumbersome to reason about This is like saying recursion is hard to reason about because you're dealing with a function which calls itself then calls itself then calls itself and there are layers and layers of calling itself with chains of arguments passed down through the many layers. > a stateless function that renders a react component that wraps around a redux plugin component IMO React's recursion makes it much easier to reason about than something imperative like Vue, while its function composition enable powerful patterns for reusing logic.
- sametmax 8y ago
  Recursion is hard to reason about. As a teacher, it's one of the first concepts my students have a hard time with.
- bmarkovic 8y ago
  Recursion IS hard to reason about, and then implementing it efficiently (in a runtime / compiler) is also hard, and then an efficient implementation restricts your expressiveness, and then when someone else needs to read such code, it's hard for them to reason about it. There are actually a lot of similarities with React. Neither are useless nor bad per se, but given options, in majority of cases both are more of a smartass thing to do rather than the most optimal or most maintainable / developer friendly thing to do.
  - anonytrary 8y ago
    > Recursion IS hard to reason about, and then implementing it efficiently (in a runtime / compiler) is also hard Regarding recursion, I find that recursion is easier to understand than an equivalent while-loop, but maybe it's personal preference. Also, most people shouldn't have to worry about optimizations like tail recursion. > when someone else needs to read such code, it's hard for them to reason about it. I'll admit, there are a few negatives with React, but they don't outweigh the positives. Micro-optimizations in user-land should never be seen by designers and if they are, then something is wrong. React's diffing algorithm is a leaky abstraction and forces the designer to be aware of component optimization, since how you break up your components affects how much work the diff has to do. The new context API is inelegant and it feels like a square peg in a round hole. Additionally, shouldComponentUpdate is the wrong abstraction -- it is very imperative and it pushes you to break your components down into smaller components even if your app's organization suffers. Reusability and organization should be the only two reasons for creating new components -- performance shouldn't be a plausible reason, because it creates a higher degree of overlap between the developer and the designer.
kiliancs 8y ago
> React feels like layers and layers of render functions, with chains passed down and pared down as you get deeper, which becomes excessively cumbersome to reason about. This reads more like a design problem than with React. React gives you the component and some good practices and advices in the documentation, but how you compose them is in the end your responsibility. > Vue feels like it compartmentalizes things much more effectively. A component can just be a component, not a stateless function that renders a react component that wraps around a redux plugin component, with each step having its own little isolated DSL. I think it's unfair using DSL here. Even Redux makes a big point out of not creating too many conventions nor sugaring, and people actually complain about the boilerplate. Redux's `connect` is a function that does no magic: returns a function that will return you a component (which like you point out could even just be another function) with props mapped as per your initial arguments. No DLS, no magic. That a component can be just a component, not a stateless function to me doesn't make much sense, given how functions are primitive constructs and components are not. I think the fact that components can be just stateless functions is good because it means composing components is no different from composing functions. And again, if a stateless component renders another component and wraps a redux connected component it either makes sense based on what the developers are trying to achieve or maybe they are just over-complicating things, but React wouldn't be responsible for either decision.

anonytrary 8y ago

> React feels like layers and layers of render functions, with chains passed down and pared down as you get deeper, which becomes excessively cumbersome to reason about This is like saying recursion is hard to reason about because you're dealing with a function which calls itself then calls itself then calls itself and there are layers and layers of calling itself with chains of arguments passed down through the many layers. > a stateless function that renders a react component that wraps around a redux plugin component IMO React's recursion makes it much easier to reason about than something imperative like Vue, while its function composition enable powerful patterns for reusing logic.

sametmax 8y ago
Recursion is hard to reason about. As a teacher, it's one of the first concepts my students have a hard time with.
bmarkovic 8y ago
Recursion IS hard to reason about, and then implementing it efficiently (in a runtime / compiler) is also hard, and then an efficient implementation restricts your expressiveness, and then when someone else needs to read such code, it's hard for them to reason about it. There are actually a lot of similarities with React. Neither are useless nor bad per se, but given options, in majority of cases both are more of a smartass thing to do rather than the most optimal or most maintainable / developer friendly thing to do.
- anonytrary 8y ago
  > Recursion IS hard to reason about, and then implementing it efficiently (in a runtime / compiler) is also hard Regarding recursion, I find that recursion is easier to understand than an equivalent while-loop, but maybe it's personal preference. Also, most people shouldn't have to worry about optimizations like tail recursion. > when someone else needs to read such code, it's hard for them to reason about it. I'll admit, there are a few negatives with React, but they don't outweigh the positives. Micro-optimizations in user-land should never be seen by designers and if they are, then something is wrong. React's diffing algorithm is a leaky abstraction and forces the designer to be aware of component optimization, since how you break up your components affects how much work the diff has to do. The new context API is inelegant and it feels like a square peg in a round hole. Additionally, shouldComponentUpdate is the wrong abstraction -- it is very imperative and it pushes you to break your components down into smaller components even if your app's organization suffers. Reusability and organization should be the only two reasons for creating new components -- performance shouldn't be a plausible reason, because it creates a higher degree of overlap between the developer and the designer.

kiliancs 8y ago

> React feels like layers and layers of render functions, with chains passed down and pared down as you get deeper, which becomes excessively cumbersome to reason about. This reads more like a design problem than with React. React gives you the component and some good practices and advices in the documentation, but how you compose them is in the end your responsibility. > Vue feels like it compartmentalizes things much more effectively. A component can just be a component, not a stateless function that renders a react component that wraps around a redux plugin component, with each step having its own little isolated DSL. I think it's unfair using DSL here. Even Redux makes a big point out of not creating too many conventions nor sugaring, and people actually complain about the boilerplate. Redux's `connect` is a function that does no magic: returns a function that will return you a component (which like you point out could even just be another function) with props mapped as per your initial arguments. No DLS, no magic. That a component can be just a component, not a stateless function to me doesn't make much sense, given how functions are primitive constructs and components are not. I think the fact that components can be just stateless functions is good because it means composing components is no different from composing functions. And again, if a stateless component renders another component and wraps a redux connected component it either makes sense based on what the developers are trying to achieve or maybe they are just over-complicating things, but React wouldn't be responsible for either decision.