@i-like-foxes

Recently we had a guy on board for some consulting that wrote a book about Angular that's more than 1000 pages thick.

I bet he'd write a better feature using Angular than most of my React colleagues I still know.

I never claimed Angular forces memory leaks on you, Angular doesn't leave you any choice but to create unfixable memory leaks. And sure, if we end up agreeing, things might be mainly on the same level between React and Angular. Might be true.

So what does Angular bring to the table that I accept the developer pool I could potentially hire from, which is just way smaller than anything React?

Furthermore, there's a fine-tuned, daily optimized product that takes care of SSR vs. a shitty page within the Angular docs.

And in the end:

Sure, if you put all your trust into Angular, fine. But please let's pray together that the one lib, that's many times your only choice, will care for Angulr 14, 15, 16.

My point isn't at all that I do not think there are many capable Angular Developers that can produce a decent (at least if it doesn't include SSR) SPA using Angular.

@Marl3x

No matter what you're talking abut. C, C++, Rust, whatever... You could always say: "If you have memory leaks, it's your fault."

For sure, they could be fixed, and they could even be avoided in the first place, but that doesn't mean that it doesn't say anything about the technology if developers keep running into them constantly iusin gone technology, while for the other technology I'd consider it to be a not too easy interview question asking the candidate "How would you produce a memory leak in a React App.?"

@Marl3x

That's just not true. I work on a big project, where teams maintain their own angular projects and there are teams that definitely do things very differently than other teams.

The first time I had sex was done within 20 seconds at most, probably much less.

Unfortunately, maintaining problematic TS is not behind you after 20s.

The first time I had sex was done within 20 seconds at most, probably much less.

Unfortunately, maintaining problematic TS is not behind you after 20s.

@DEVil666

You should also know that you can't be sure it'll work as expected if you use async await because of zones.

@Marl3x

I value if frameworks prevent you from creating memory leaks and do not require that you don't make any mistakes.

Any observable you subscribe to, at least if it's not in a template, you need to unsubscribe.

And you can like or prefer Angular over React. Fine.

But there's no technical reason or actual rationale behind the claim that Angular is inherently more stable, enterprise/ reliable, or whatever.

And if a framework allows mixing two completely different methods for change detection, I don't feel like Angular is that same option, where I came to rely on the result even when having some less experienced devs on the team.

@HiFiWiFiSciFi
Everybody can build almost every feature possible.
But it seems hard to do it in a way that you still can add features 2 years later, without taking 10 times the time a similar feature took in the beginning.

@HiFiWiFiSciFi
Sorry but no.

The least helpful thing is not realising why certain things might not as easy as you think.
The idea that frontend wouldn't require any programming skills is just ignorant.

Not approaching things in a way that acknowledges why it matters to do things as good as possible and that might way harder and not at all the same as getting it to work.

I think a real patriot would never use React. It's communist and they even support black lives matter.