Thanks for sharing your thoughts, Ryan. Impressive how you’ve explored all these modern frameworks. Except Angular. Is that by choice?
The timing was never right really. Around Angular 1 time period I was firmly in the Knockout side of things and reactivity. I got into Knockout originally through working with a Microsoft partner and it just felt really nice way to escape .NET. It served as my comparison point for every other JS UI Library afterwards.
So when I went to learn a full framework I learned Ember as it seemed like it had a similar reactive data model. It was just a superficial judgement call but the $scope thing seemed like a hack on. And I wanted my ViewModels for a better term to own their own state. In the end I felt Ember 1 and my projection of what I thought Angular 1 was were just the wrong model for client development.
Then React came out and I was like yeah these guys get ViewModels, they just call them components. Same simple “just a view” library like KnockoutJS. By using MobX I could keep a similar dev experience to Knockout if I wanted. My work into Compilers lead me to Svelte, and when Vue previewed their Composition API it was the same thing again.
So facetiously I could say I only learned one UI Library: KnockoutJS. And over time every other library whether they realized it or not converged on that point. In all honesty once I was on this path I never found myself in a position to take on a whole other thing. The ecosystems and patterns of these lighter libraries are all more or less the same. Once I was engaged.I just spent the time to dig deep and get to the bottom of their particular intricacies.
Who knows? Maybe nows the time. There seems to be a lot of Angular experts around here.
That’s interesting, I started out with Knockout and Durandal Definitely a less steep learning curve than Angular and RxJS. I’ve used many others over the years.
Funny enough I also got into RxJS for a while too. I thought Solid was going to be built off those observables. And early sketches used a lot of Behavior Subjects as the reactive layer. It just got really verbose and complicated to do certain simple things and forced my hand a bit around how to handle views. For good reason the most successful(non-Angular… can’t speak for Angular) approaches I’ve seen with RxJS use less granual updates since it’s easier to do something like wrap the whole view in a combineLatest more or less. I loved the clear transformation pipelines, the succinct declarative logic, but I wasn’t happy with all my ideas for that interopt point. I decided that I would just make it really easy to pipe Rx Observables into Solid’s signals and made a
solid-rx library for that.
Really Angular is just this strange missing piece for me. That I just haven’t really found the right moment. I’ve touched a lot of things around it.
Angular didn’t start out with RxJS. The Angular team adopted RxJS shortly before the stable v2.0.0, but they left us with a choice.
By default, we can use excessive dirty checking any time an asynchronous event happens. Zone.js intercepts all tasks and triggers a change detection cycle which dirty checks all bindings and template expresssions in the full component tree.
If we opt-in to
OnPush change detection strategy (per component), components and their subtrees of components are only dirty checked when input property values are changed.
Because Angular supports the imperative style, it’s reactive APIs are not very easy to use and don’t feel very reactive.
There’s a movement to build fully reactive applications without Zone.js (the
NgZone) and with
OnPush change detection in all components. The Angular team doesn’t fully support this in the framework, but userland libraries are working to improve and support this:
Angular uses RxJS to expose router-related events, but they’re only needed for advanced use cases.
Angular also uses RxJS for its
HttpClient. As this always emits a single value and then completes, you would think that this is one of the poorer use cases for RxJS. However, it does allow aborting the request simply by unsubscribing or
Angular has a reactive forms API which exposes observables for value updates and validation state updates. Unfortunately, it is weakly typed. And again, they left us with the choice of template-driven forms (all state is managed in the HTML-like component templates) or the reactive forms (state is managed in TypeScript, directives bind the form properties to the component template).