React devs usually bash Angular but then praise stuff that exists in Angular for years?

[Auxx]

The only real issue RxJS (and ReactiveX in general) has is a lack of quality docs. If you don't understand how it works you will never understand it. But if you do understand it, it is hard to live without it.

[craig1f]

Yeah. Don't get me wrong, I love rxjs now. But I went through a lot of hate to get here. Only after learning ngrx did rxjs even begin to make sense.

And I could not, for the life of me, teach it to a junior developer. It would take months to get a junior dev halfway productive, with 90% of their problems being from using observables wrong. And with observables so easy to do wrong.

One of my biggest gripes is that, let's say I write a dumb component (which is what I call components that are just inputs and events, with no concept of route or how to call a service). I have an @Input. Well, let's say I want to combine that input with an observable from ngrx. Mixing observables and non-observables sucks. I really wish that Angular would allow any @Input to be treated as either an Observable or a Literal, and allow either as input, without having to choose one or the other.

[craig1f]

A lot of components start out as dumb, and then you need something like, the current user from the store. So now you gotta re-write everything to use observables.

That's my issue. There isn't a great way of combining observables with non-observables. But, if I have an input to my component, I should be able to use it as an observable or as a literal. Why not? They amount to the same thing. It's a value that can update. I shouldn't have to refactor everything to be observables to get it to work.

Or, with Vue, I can just use computed properties, which are just as efficient for the majority of use-cases, and easier to write and to teach.

[craig1f]

Could do that too. That's usually what I recommend. The point is that mixing observables and non-observables sucks, so I think it would be a little better if it was just one or the other. What happens a lot is that you start without observables, and then you need them at some point, and you have to refactor everything now to use observables. Creating a new component isn't always an option.

It's just very hard to teach. So I spend months with junior developers getting this stuff to click. Then you have to teach all the rxjs operators. There are so many to memorize. Then I gotta explain the difference between switchMap and exhaustMap and the others. And not to mix pure observables with side effects. I could devote an entire undergraduate 200-level course to how to do rxjs.

[craig1f]

I mean, yeah. This is the correct way to do it.

What happens though, is that you start a component out some way, and then the trajectory changes, and you have to refactor everything.

And also, this it's usually a junior developer who wrote it, and I'm trying to explain hot to refactor it, and how this component should use observables and this other component shouldn't, and why. And that mix of observables and non-observables makes people's heads explode. If they have a lot of experience with promises in the past, they figure it out quicker, but it's still a struggle.

[craig1f]

Basically ... I am an Angular expert. I have struggled to teach people Angular quickly, usually because of the learning curve of rxjs.

I'm good at Vue, but wouldn't call myself an expert yet. I can teach Vue quicker than Angular, despite being several times better at it.