Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
soylatte81yI feel the same way about Ember.js at my workplace they do their best to add nice things to the framework but it's frustrating to be nowehere near React in terms of ease of use. Even React is starting to become an old man in the world of Web frameworks.
Every single thing in Angular automatically handles its garbage, if you have memory leaks that's your fault.
Angular and React cannot compare because they are not supposed to. React is just a library for reactive components. Angular is a web framework.
If you want flexibility, and ease of use, use React, if you want robustness and team scalability, use Angular.
DEVil6668551yWhat I hate most of Angular are the “zones” which makes integration with older JS libraries far more complicate than it should be.
nibor49801yIn other news, Apples are not the same as Oranges
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.
@i-like-foxes I don't know what type of observable you mean, the HttpClient does not need, Forms do not need it, the Router does not need it. If you have your own RxJs Observables that cause leaks that's not Angulars fault.
My point is, that Angular has a definitive way of doing things. Everyone that joins a project knows what to expect and can quickly start developing as long as he knows the business use case. With React, there is so many libraries, and architectural patterns you may choose, that you never know what the application might look like at the end. Especially for beginners designing applications, this kind of flexibility is not actually a good thing. But you might disagree with me.
@i-like-foxes Well obviously your codebase will be different, and you can always add on top, but the fundamentals are always the same. React is much more "low-level" than Angular.
Components, Services, Modules, Interceptors, Pipes, Tests, HTTP Requests etc. will always look (except for its contents) the same and anybody will know what to look for, and what to expect when opening a file.
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.?"
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.
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.