pure

This seems like an unrelated potshot at TS. It sounds like the person you're replying to didn't have a yarn.lock or package-lock.json, so 2 years later, they're pulling in different versions of every dependency. Of course things are going to break.

Definitely correct me if I'm wrong, but I also thought hooks were for factoring out common logic and sharing it among functional components. I see lots of "hooks" libraries floating around.

For Context, like you said, it existed before, but everyone was told not to use it. After the new API came out, people started suggesting ditching Redux for Context, and I know a lot of people did that. Using Context in that way is very similar to creating a stateful service in Angular and injecting it into your components.

Angular is really a great framework. I think a lot of people complaining about Angular haven't actually built an app in Angular 4+. I also wish the Angular team had just called Angular 2 something else, since the 1 -> 2 transition frustrated a lot of people who jumped ship and never looked back. I also understand that people just have different preferences, which is fine, too.

Out of the box, you get: routing with lazy loading, full TypeScript support and a TypeScript-first ecosystem, a great CLI that completely abstracts Webpack and the build process, easy and mostly automatic updates with the CLI, reactivity with RxJS baked-in and supported widely in the community, a great forms library, and, of course, a component-based approach to UI development. The uniformity is a big benefit. It's easy to ramp up on a new Angular project, and there are fewer decisions to make when starting a new one. The built-in parts of the framework are all high quality and an easy bet. There's no need to evaluate different routers, form libraries, HTTP clients, get back up to speed on configuring Webpack only to forget how until next time, etc.

It's also interesting to see the React community move towards some of the things that Angular has been doing for years: embracing TypeScript, extracting business logic to services (or you can call them Hooks), creating injectable shared state (or you can call it Context).

I started with apollo-client on a new app, but switched to using ngrx and turning off apollo-client caching (basically using apollo-client as a fancy graphql request library - I should probably just use apollo-link directly). My main problem was that it felt like it required both developers and components to have too much knowledge of the individual queries that the app was making. Instead of writing an app that happened to use graphql, I felt like I was writing a graphql app.

An example of that is updating the state after mutations that modify lists (e.g. creates or deletes). It's up to the developer to remember all other queries that could be affected by a mutation and to update them manually after the mutation completes (more info: https://github.com/apollographql/apollo-client/issues/3505 and https://www.apollographql.com/docs/angular/features/cache-up...). If you add a new component that performs a query that could be affected by a previous mutation, you have to remember to also go back to that mutation and update your query from it. With ngrx (or redux), the consistency is baked in, and part of the beauty of it is that if you update the state, anyone who happens to be reading that state will get updated automatically.

I actually think "more PRs" usually does mean "better project" in the sense that smaller PRs are easier to review and reason about than larger ones. To me, though, I think the incentive here goes the other way - I'd want to put everything in one big PR so it looks like my client is getting a lot of work for their money. Either way, it's hard to imaging tying payments to PRs not having some impact on the coding process, which seems like a negative thing to me.

I don't know why you're getting downvoted. The single member S-Corp is a very common setup for individual freelancers/consultants precisely for this reason. FICA taxes aren't paid on distributions.

To do this, the single member has to pay themselves a "reasonable salary", but there aren't strict guidelines on this. It's a gray area, and some people push it (and lose), but it's a very common setup.

I've only used TS on the frontend, but I had the same opinion as you until I dug into a couple of TS projects. I don't know if I've ever caused a JS production bug that was a type error at its core, but I've had plenty of bugs like that in development. TS lets me cut out those little dev cycles where I'll write some code, rebuild the app, then see an obvious error in the JS console when I run the app. That adds up to a lot of wasted time over a week of coding. Smart autocomplete and smart variable renaming is also really nice, and I have way more confidence refactoring a TS project than a JS one. I think using TS does result in fewer production bugs, but the big win for me has been having fewer development bugs.

Which frameworks do this?

I was wondering the same thing. I was surprised that it looked like he launched Android and iOS versions at the same time, which makes me think it's probably a cross platform framework. I'd definitely love to hear more about the dev stack.