[ridicter]

My experience with react with different: you have to spend a large amount of time upfront in order to get the basic features of a single page app. You burn a lot of mental energy figuring out which forms library, router library, etc to use. When it's time to upgrade, you have no guarantees that your libraries will continue to play together nicely. And quality and standards between libraries can vary dramatically.

I prefer the Angular approach. The initial learning curve is steep, but once you get over that, it becomes a rapid development framework, as all the pieces work together cohesively. The Angular CLI makes creating components, services, updating, etc a breeze, and helps maintain structure as your scale your app up. The core libraries (like routing, forms) are developed and maintained by Google, so you can expect a solid level of quality. The typescript-first approach means that your IDE can help you explore APIs, auto import, and work with third party libraries just as well. And the strong foundation provided by the core framework means that third party libraries have a better starting point upon which to supplement/extend.

[mattlondon]

Same experience here with Angular - I have heard it described as "batteries included". It has basically everything you need to do 99% of all projects right out of the box (notable missing thing is something cohesive to properly manage application state in a nice way).

Takes a bit of effort to learn, but once you are up and running with Angular things are pretty fast to put together.

[ridicter]

I think using managing state with an observable data service is a pretty good option w/o resorting to 3rd party libraries: https://blog.angular-university.io/how-to-build-angular2-app...

Alternatively, you could use Akita, which is built on top of this basic model, but offers a ton of additional functionality and the ability to use Redux Dev Tools.

Finally, you also have NgRX, which is based on Redux--but also adds a ton of overhead and boilerplate. I actually opted for Akita since it is way more ergonomic and offers most everything I need.

[mattlondon]

Yeah the "inject a state service into everything you need" is one way of doing it, but it gets messy and it tightly binds your components with that particular state handling approach (e.g. re-using components across projects might get difficult if you have a bespoke state service for Project A and you want to use A's components also in Project B & C etc). We also found that there are big concerns about which components are allowed to access and update which state - e.g. why does a tiny inconsequential GUI control used to copy something to a clipboard potentially get access to read and mutate the entire application's state? You can start sharding it up and put in "ACLs" of sorts ... but that is some of the messyness I mentioned :)

Not seen Akita previously - will take a look. Thanks!

[zdragnar]

I dont know how much has changed in the two years since I last touched it, but Angular's blessed packages and ecosystem were more of a time sink than anything else- the flex layout package in particular was substantially buggier than simply using postcss with what was at the time css-next (I think it is preset-env now?)

Additionally, baking in rx-js felt like a serious mistake- not only was there the roller coaster ramp up of learning angular, but helping others on the team learn rx-js on top of it while trying to be productive probably cut our output in half.

It didnt help that we had a mix of junior developers and experienced .net devs all learning at the same time- half the battle was explaining which feature came from ES2015, typescript, angular or rx-js.

Hindsight may be 20/20, but I am reasonably confident that we could have been significantly better off with react. Ember was never an option because they are only just now getting features react and angular developers have been taking for granted for years.

[ridicter]

I never used the flex layout package. That's a third party library, and I think sticking with CSS grid + flex makes more sense. (Alternatively, you can just use bootstrap or tailwind or whatever.)

RxJS is actually one of my favorite parts to Angular, but it _does_ lengthen the learning curve quite a bit. Once you get past that, you can have amazingly reactive apps. One of my beefs with ReactJS is that it doesn't play as well with RxJS. Now that I think of it, you're not actually required to use RxJS with Angular: you can convert observables to promises (`toPromise()`).

I could see how having junior/new developers could make things a lot harder. I remember first learning typescript and having to keep the TS playground open at all times to see how it compiled to ES5.

[mattlondon]

Yeah when I first started learning Angular I had similar thoughts "Why did they make this so hard?!?!?!" regarding RxJS. To be fair regarding Typescript & ES2015, you'd get that with React too (since in my mind you;d be insane to start something new in raw Javascript these days when Typescript has made our lives so much so much so much better).

Now though I find RxJS to be a really elegant mental model for dealing with asynchronous stuff. I wish there was more Reactive/Rx* stuff around in the things I work with. Its really nice.

[vips7L]

I've had the opposite experience regarding RxJava. I really think "reactive" is an anti-pattern. Its made my companies code base much harder to reason about.

[bobthepanda]

> You burn a lot of mental energy figuring out which forms library, router library, etc to use

Why do you need a specific forms or router library? Those are both things you can do with vanilla ES2015+ and React.

The library problem is self-inflicted, but it doesn't help that search engines tend to boost a lot of half-baked Medium posts about why you should use slightly-nicer flavor-of-the-month library to wrap something really basic like the fetch browser API.