4 ms·

Yes, when I first read about Flux (which was after I learned RxJS) I kept thinking that you are essentially writing by hand things that could be generated autom

by muraiki 11y ago

Yes, when I first read about Flux (which was after I learned RxJS) I kept thinking that you are essentially writing by hand things that could be generated automatically. It's like going from nested callbacks in early Node.js to Go. :) I prototyped a decent amount of UI in Cycle and thought that it was great. Using virtualdom with it was really enjoyable and a lot easier to reason about than what is seen in the typical JQuery-based RxJS/Bacon/Kefir examples. However, I found the interaction between exception handling in Cycle and RxJS to be strange at times... maybe I'm just not experienced enough with them yet, but I swear I had some swallowed exceptions that I could never track down. That being said, I feel that this is "the future" (standard disclaimer applies). Currently I'm using Knockout.js for UI stuff at work and I've found that by maximizing the use of pure computed observables and minimizing mutation of observables (essentially, implementing unidirectional data flow) I can get pretty good results.

WorldMaker 11y ago
Yes, exception handling with Observables, just like with Promises, gets to be a bit more complicated, especially as browser Dev Tools haven't quite caught up to them yet. (With Promises native to ES2015 that's getting fixed and native Observables are tentative for ES2016 or ES2017 which would be great. Also, now that Promises are native, I'm really hoping for a big Node push towards more Promise-friendly APIs.) The great thing about Observables, though, is that even though exception handling is more complicated as you first learn it: it's a lot more consistent as you get used to it than the callback/event-handler world. That said, I do think Cycle swallowed exceptions it shouldn't have early on (especially without good browser dev tools support) and seems to be getting better at console.loggging them if not propagating them through observable streams as sometimes it should. My fallback is still Knockout as well. It has served its role, with its very basic observables, very well over the years.

by muraiki 11y ago

WorldMaker 11y ago

Yes, exception handling with Observables, just like with Promises, gets to be a bit more complicated, especially as browser Dev Tools haven't quite caught up to them yet. (With Promises native to ES2015 that's getting fixed and native Observables are tentative for ES2016 or ES2017 which would be great. Also, now that Promises are native, I'm really hoping for a big Node push towards more Promise-friendly APIs.) The great thing about Observables, though, is that even though exception handling is more complicated as you first learn it: it's a lot more consistent as you get used to it than the callback/event-handler world. That said, I do think Cycle swallowed exceptions it shouldn't have early on (especially without good browser dev tools support) and seems to be getting better at console.loggging them if not propagating them through observable streams as sometimes it should. My fallback is still Knockout as well. It has served its role, with its very basic observables, very well over the years.