5 ms·

I was a Flex developer. No JS framework felt anywhere close to the ease and power of Flex until I saw React. React is Flex done right. React is Flex but armed

I was a Flex developer. No JS framework felt anywhere close to the ease and power of Flex until I saw React. React is Flex done right. React is Flex but armed with the knowledge that two way data binding is the fucking devil.

MaxBarraclough 6y ago
> two way data binding is the fucking devil You mean in terms of performance, or something else?
- The_Amp_Walrus 6y ago
  In terms of reasoning about your code, I expect.
- Marazan 6y ago
  Reasoning about code. Creation of inscrutable bugs. Forcing to create convoluted hierarchy of data structures to work round the problems this convenient 'feature' created. The kicker for me is it is perfectly possible to use Flex in a one-way data binding manner. Just wish I'd worked that out 13 years ago!
  - MaxBarraclough 6y ago
    Ah, the 'spooky action at a distance' aspect. Doesn't much of that apply to data-binding in general though?
    - Marazan 6y ago
      I have found that the difference between one-way and two-way to be quite profound when it comes to the complexity of bugs produced. Race conditions become an almost permanent fixture with two-way and the 'chains of causality' are exponentially more complex in a two-way situation. One-way simplifies things in quite a profound way. I remeber when watching Dan Abromov's excellent Redux tutorial physically laughing and muttering "of course" as every single two-way bug I had ever worked on flashed before my eyes.
      - MaxBarraclough 6y ago
        Switching to one-way-binding is really just replacing upward propagation with events, right? Aren't both approaches vulnerable to data-change cycles, just by different means?
        TuringTest 6y ago
        Maybe the difference is that you keep control with events, i.e. you can filter, retarget, cancel or otherwise reason in general about the way they propagate? I'm no expert, but the essence of the "reactive functional programming" programming paradigm is that you have composable high level abstractions about the streams of events (e.g. marble diagrams).[1] [1] https://blog.danlew.net/2017/07/27/an-introduction-to-functional-reactive-programming/ https://blog.danlew.net/2017/07/27/an-introduction-to-functi...
- hajile 6y ago
  Mobx is a great example. It works well for small projects, but as they grow, you get bugs. One thing winds up depending on another that depends on yet another and before you know it, you've got all sorts of unexpected updates happening. These bugs often require digging into and though the mobx implementation details as you try to step your way to the problem. You can greatly reduce this issue, but you do so by refusing to use most of the 2-way binding features. At that point, you're going to basically be doing one-way data flow anyway and might as well go all-in with a library tailored to do that.
  - MaxBarraclough 6y ago
    To mirror my other reply: This is the 'spooky action at a distance' aspect of data-binding. Doesn't it apply to data-binding in general?

MaxBarraclough 6y ago

> two way data binding is the fucking devil You mean in terms of performance, or something else?

The_Amp_Walrus 6y ago
In terms of reasoning about your code, I expect.
Marazan 6y ago
Reasoning about code. Creation of inscrutable bugs. Forcing to create convoluted hierarchy of data structures to work round the problems this convenient 'feature' created. The kicker for me is it is perfectly possible to use Flex in a one-way data binding manner. Just wish I'd worked that out 13 years ago!
- MaxBarraclough 6y ago
  Ah, the 'spooky action at a distance' aspect. Doesn't much of that apply to data-binding in general though?
  - Marazan 6y ago
    I have found that the difference between one-way and two-way to be quite profound when it comes to the complexity of bugs produced. Race conditions become an almost permanent fixture with two-way and the 'chains of causality' are exponentially more complex in a two-way situation. One-way simplifies things in quite a profound way. I remeber when watching Dan Abromov's excellent Redux tutorial physically laughing and muttering "of course" as every single two-way bug I had ever worked on flashed before my eyes.
    - MaxBarraclough 6y ago
      Switching to one-way-binding is really just replacing upward propagation with events, right? Aren't both approaches vulnerable to data-change cycles, just by different means?
      - TuringTest 6y ago
        Maybe the difference is that you keep control with events, i.e. you can filter, retarget, cancel or otherwise reason in general about the way they propagate? I'm no expert, but the essence of the "reactive functional programming" programming paradigm is that you have composable high level abstractions about the streams of events (e.g. marble diagrams).[1] [1] https://blog.danlew.net/2017/07/27/an-introduction-to-functional-reactive-programming/ https://blog.danlew.net/2017/07/27/an-introduction-to-functi...
hajile 6y ago
Mobx is a great example. It works well for small projects, but as they grow, you get bugs. One thing winds up depending on another that depends on yet another and before you know it, you've got all sorts of unexpected updates happening. These bugs often require digging into and though the mobx implementation details as you try to step your way to the problem. You can greatly reduce this issue, but you do so by refusing to use most of the 2-way binding features. At that point, you're going to basically be doing one-way data flow anyway and might as well go all-in with a library tailored to do that.
- MaxBarraclough 6y ago
  To mirror my other reply: This is the 'spooky action at a distance' aspect of data-binding. Doesn't it apply to data-binding in general?