4 ms·

My gripe with RxJS is how difficult it is. I've put thousands of hours into learning it and I just know the rest of the team don't understand the long chains I'

My gripe with RxJS is how difficult it is. I've put thousands of hours into learning it and I just know the rest of the team don't understand the long chains I've written with it. I have the same problem where people are doing backflips to do simple things and I'll come in afterwards like... What ARE you trying to do here? And why are you not cleaning these up? Originally I was trying to stay away from behaviour subjects as recommended by the RxJS purists but now I just want to use them everywhere so its easier for everyone else to get values out of a stream

WorldMaker 6y ago
Sure, and that's pretty much exactly why Angular seems to refuse to commit. The EventEmitter in Angular's core is a really odd BehaviorSubject duck, and it shows. That says everything about their commitment to RxJS purity, and that behavior "from the top" leads to how much Angular pushes everyone to want to abuse BehaviorSubject, to do a lot of bad RxJS and never learn to do it right, because it's that rotten to the core. That impression that RxJS is too difficult for mortals becomes the self-fulfilling prophecy that Angular is right not to do RxJS right or commit to it, because it makes doing RxJS right in Angular harder. Half the component examples I see in the wild use RxJS wrong or badly, and of course that stuff gets copied and pasted everywhere. I've already sent patches to at least a few documentation examples that are supposed to be "best practice" that failed to actually live up to best practices because Angular failed them in setting a good example to live by. Angular has created the worst of both worlds that makes RxJS harder than it should be by failing to use it properly (providing too many bad habit escape hatches and failing to commit to it), but also making it almost impossible to avoid and subsequently polluting the entire ecosystem with bad examples, worse documentation, and terrible habits (all of which goes right back up to the top and terrible design decisions such as Angular core's EventEmitter). If Angular committed to being an AOT change detection only system it would probably be much more like Svelte. If Angular committed fully to RxJS it would be something different entirely [0] and maybe sure it would be harder for a lot of devs to grasp at first, but instead of the pit of failure that currently awaits devs trying to learn RxJS in place in Angular, maybe they'd have a pit of success that a lot more devs would learn RxJS given a safe place to do it with fewer papercuts and bad examples to learn from. [0] It probably wouldn't be CycleJS either, as they'd still probably avoid Virtual DOM techniques. This thread has me picturing what you could do with a compile-time template Observable pipeline and I'm almost curious enough now to build a prototype of it just to show Angular how dumb it is and what it could be.
- WorldMaker 6y ago
  I really can't stop thinking about an Observable-only AOT compiled template language-based framework. You could achieve a compile-time version of React's Suspense framework incredibly cheaply (from a user developer standpoint) entirely in the way you compile-time compose, schedule, and subscribe Observables in a template and its child templates. So much of the work that React's Suspense has to do at runtime, such as scheduling things to arrive at requestAnimationFrame() time, debouncing/throttling updates, coordinating (composing) related updates in child components, all have simple RxJS operator equivalents, and you could declare all of that simply in templates leaving the compiler to do the final RxJS operator compositions and most users of the templates to not have any idea how complicated some of those final compiled compositions may be, but directly gaining the benefits of them (such as cleanly debounced AOT-compiled DOM updates at requestAnimationFrame time; complexly coordinated multi-component update patterns). It's an amazing sounding framework in my head. Very worried I at least need to build a prototype of it now or it will continue to haunt my dreams.

WorldMaker 6y ago

Sure, and that's pretty much exactly why Angular seems to refuse to commit. The EventEmitter in Angular's core is a really odd BehaviorSubject duck, and it shows. That says everything about their commitment to RxJS purity, and that behavior "from the top" leads to how much Angular pushes everyone to want to abuse BehaviorSubject, to do a lot of bad RxJS and never learn to do it right, because it's that rotten to the core. That impression that RxJS is too difficult for mortals becomes the self-fulfilling prophecy that Angular is right not to do RxJS right or commit to it, because it makes doing RxJS right in Angular harder. Half the component examples I see in the wild use RxJS wrong or badly, and of course that stuff gets copied and pasted everywhere. I've already sent patches to at least a few documentation examples that are supposed to be "best practice" that failed to actually live up to best practices because Angular failed them in setting a good example to live by. Angular has created the worst of both worlds that makes RxJS harder than it should be by failing to use it properly (providing too many bad habit escape hatches and failing to commit to it), but also making it almost impossible to avoid and subsequently polluting the entire ecosystem with bad examples, worse documentation, and terrible habits (all of which goes right back up to the top and terrible design decisions such as Angular core's EventEmitter). If Angular committed to being an AOT change detection only system it would probably be much more like Svelte. If Angular committed fully to RxJS it would be something different entirely [0] and maybe sure it would be harder for a lot of devs to grasp at first, but instead of the pit of failure that currently awaits devs trying to learn RxJS in place in Angular, maybe they'd have a pit of success that a lot more devs would learn RxJS given a safe place to do it with fewer papercuts and bad examples to learn from. [0] It probably wouldn't be CycleJS either, as they'd still probably avoid Virtual DOM techniques. This thread has me picturing what you could do with a compile-time template Observable pipeline and I'm almost curious enough now to build a prototype of it just to show Angular how dumb it is and what it could be.

WorldMaker 6y ago
I really can't stop thinking about an Observable-only AOT compiled template language-based framework. You could achieve a compile-time version of React's Suspense framework incredibly cheaply (from a user developer standpoint) entirely in the way you compile-time compose, schedule, and subscribe Observables in a template and its child templates. So much of the work that React's Suspense has to do at runtime, such as scheduling things to arrive at requestAnimationFrame() time, debouncing/throttling updates, coordinating (composing) related updates in child components, all have simple RxJS operator equivalents, and you could declare all of that simply in templates leaving the compiler to do the final RxJS operator compositions and most users of the templates to not have any idea how complicated some of those final compiled compositions may be, but directly gaining the benefits of them (such as cleanly debounced AOT-compiled DOM updates at requestAnimationFrame time; complexly coordinated multi-component update patterns). It's an amazing sounding framework in my head. Very worried I at least need to build a prototype of it now or it will continue to haunt my dreams.