6 ms·
I think FRP is one of those technologies where going full-hog (all the things are event streams!) results in confusing code and a dogmatic, difficult, and unple
by m_fayer 11y ago
I think FRP is one of those technologies where going full-hog (all the things are event streams!) results in confusing code and a dogmatic, difficult, and unpleasant development experience. However, if you apply it just enough, you'll have coherent one-directional dataflow, effortless propagation of state changes, and a nice testable push architecture as a free side-effect. It's a way to tame the state-monster. And there will be numerous small isolated parts of your codebase that are unrelated to the aforementioned goals, where sticking to FRP would be masochistic and pointless.
A major part of mastering a technology or paradigm is knowing when to apply it and when the costs of it outweigh the benefits. Then again, I prefer hybrid-friendly languages like scala, so maybe the haskell and clojure people are onto something that I'm missing.
- Cymen 11y agoI agree with you. I also like being "closer to the machine" so to speak. One day, my dev browser will support ES6/7 and I won't need babel + webpack/browserify while doing locally development, debugging will be done on unmunged code and TDD will be easy to practice as the feedback loop will be back to normal.
- likeclockwork 11y agoIf you ditch Babel you won't be able to use ES8/9.
- hazza1 11y agoFor me ES6/7 has addressed all the low hanging fruit, I really hope ES8/9 is about removing features with only a few additions.
- wangii 11y agoeverybody agrees to add "only a few additions", except has different set of them!
- tracker1 11y agoAgreed... about the only thing from ES7 that I feel the burning need for is await/async, which I've been using for some time via Babel, and it makes the code so much easier to reason with... the hardest part is explaining to people that an async function returns a Promise and can be wrapped/used as such.