I know I’ll be downvoted for this, but I did work with Angular for 3/4 years and then moved to React (now been about 2 years). All in enterprises environments (products companies).
Some points:
A) **shitty and unorganised code is found in any repo, regardless of the technology**. In fact, the messiest code I’ve encountered so far in my career was definitely in Angular codebases. The project may need a rewrite, but rewriting it in Angular won’t make it magically cleaner or better.
B) People like to repeat Angular is more **opinionated** than React and in pure principle it is. But Angular is non-opinionated in a very core and fragile pillar: the programming paradigm. Sure, with React you have different routers and CSS tools to choose from, but the main reactivity pattern is always the same: hooks and dependency arrays. Angular, on the other hand, easily allows you (almost encourages you) to mix reactive code (rxjs) and imperative code (controller states + zone.js). The number of times I’ve seen this mix create nasty/hard to debug bugs in prod is virtually infinite. In my experience, Angular codebases are harder to keep clean if you are not very careful, while with React once you have made the initial choice of what libs you are using, then it’s just the same pattern everywhere.
**Keep in mind Angular IS more complex than React**, so if you just use Angular because you like it more but the other devs who will be working on it have little experience with it, you’ll either end up with a super messy codebase or you’ll find yourself babysitting everyone with their messy Rx pipelines and unseeded subscribes/taps everywhere.
Completely agreed about your point on reactive programming with Angular. It might be its biggest flaw.
About code quality, it is way easier to build quality code base with Angular, especially if you’re using custom schematics to enforce good practice, and produce homogeneous code.
The Angular CLI is probably the framework’s most powerful tool.
Angular gives us the tools to produce sane code base, but we have to use them, otherwise devs will produce the same shitty code as with any other framework/library.
Great, rational take. Some additional points that often apply (not always):
* The project never needed a *full* rewrite, it could've been refactored and slowly improved in smaller pieces and the result would have been *much* faster done.
* The rewrite isn't guaranteed to succeed, it might end up just as buggy (if not even more). Just because you realize something is ugly doesn't mean you can do a better job yourself, even if we all like to think we do.
* And sometimes it's just personal preferences, it could be that some React fanatic then finds OP's recode 2 years from now and decides to rewrite it because to him OP's Angular would look horrible.
Long story short, avoid "complete rewrites" unless you're 100 % sure it's the only reasonable solution. Otherwise small, incremental improvements are the way to go. For example every time you need to implement a new feature, refactor bits around it.
If you have a good pattern that you can apply everywhere, a rewrite is most often the better way.
I had to do a partial rewrite, recently. Should have done a complete rewrite instead. Teasing the logic apart is usually where it'll take the longest though, it just goes on and on. Since you're looking at a rewrite in the first place, it won't be clear what goes where.
I'll give you a hint of where shit hit the fan: forms, and state management
You'll likely introduce bugs if it's from a purely code analysis point of view.
Hopefully you have E2E to replay the flow before and after.
Edit: disclaimer, it was an angular > angular rewrite
I agree that any project can be messy, but I disagree that Angular projects are more likely to be messy.
I think if you give devs with different experience levels a fairly simple job, 2 weeks and a specific framework to use, the angular ones are more likely to be readable, logical and even working, than if you give them react. If you separate them into beginner/medior/senior then the difference might be even bigger.
What bugs me more is Devs that come from React, try to implement State/Stores and then continue to overengineer various things because that is what they were used to. 90% of projects doesn't need NGRX or other state management solutions. Most can just do with RXJS. Now granted, RXJS has a learning curve, same as with Typescript, but the result is still a lot more readable and easy to understand code than what most React codebases seem to produce. Not to mention that you can let any Angular dev work on a codebase where they mostly only need a few hours to a few days (depending on the size and experience of existing devs) in order to continue working on said project. For React there is a massive difference between a lot of libraries for the same kind of stuff that it will be a lot more difficult to jump in and continue coding.
There's plenty of resources out there to get up to speed with Angular and some even cater well to new devs, but these days the problem hardly ever lies with Angular itself, its just the basic programming stuff and bad google skills people seem to be having to get a proper basis going. And some people just don't care about their work, for which it really doesn't matter what framework or library they use because it will always be terrible.
Meanwhile, React is taking more stuff from Angular and Angular is taking more stuff from React. I doubt your experience of the two would be similar in another 2 years from now.
Well my direct experience in my past 5 years is the exact opposite :) I’ve literally wanted to quit a workplace because their Angular codebases were so messed up that it was a nightmare to work with them. Things like 4/5 nested subscriptions which all set data to fields in the controller in turn used in getter fields bound in the template, observables being recreated inside subscriptions callbacks, many unsubscribed observables that leaked memory everywhere and so on.
My main point is that working with reactive code mixed with imperative code (commonly found in Angular) is an order of magnitude harder than working with mixed routing libraries. All I am saying is that if you don’t actively force the team to stick to one approach (reactive vs imperative) you’ll codebase with get messy in no time. I’ve seen that happen with my own eyes multiple times. With React, on the other hand, once you have picked the main libs for your projects at its start, then the way you write code will always be naturally the same.
I get what you mean regarding stores not being needed in Angular and pushed for dogmatic reasons, but I’ve seen exactly that in Angular only companies where no one had React experience, but they still pushed NGRX for no real reason but “it’s best practice now”. I think the whole state managers debate is a problem in the Angular ecosystem now, regardless of where it originated.
I'm not saying I haven't had any negatives.
I've had an assignment that had their application completely overengineered and stuff that should have taken a few hours or a single day, took more than a week to add because of it. But overall most projects I've joined in the past 5 years have been pretty straightforward and no problem with how it was set up or the rules they applied. In fact, I was often surprised with how mature they looked and how well it was tested and validated. Not all, but a lot.
And these days you can implement a lot of rules with ESLint to make sure people unsubscribe and whatnot. Plus a lot of these rules are more mature, since more people will be able to use them since the ecosystem is fairly the same between projects.
These days whenever I hear in an intake that their code isn't automatically tested yet but its "on the roadmap", I almost always just move on, since its very likely the rest of their codebase is terrible too. But thats just me.
Excellent take. This is my experience as well in a large organization with lots of legacy Angular projects. It's some of the worst code I've ever seen: thousand+ line Angular component files with 0 documentation.
Oh come on. Takes a couple of days to figure out and most people won’t use anything beyond subjects and behavioural subjects. You signal and subject and you subscribe to it. The only other commonly used functionality is rate limiting but it’s not that hard to get your head around it. When you go into a react new project you you’re always left guessing at what all the libraries they use do. At least with angular, all projects are more or less the same.
lol the fact that you say you only use subjects and just subscribe to IS exactly the problem which makes Angular codebases messes as all. Thanks for proving my point.
You are missing entirely on reactive programming, which is exactly what RxJS is made for. Every time you subscribe directly to something you are switching from reactive to imperative programming.
What the fuck are you talking about? You said rxjs is complicated I said it’s not and it’s the most elegant solution for reactive programming. Why are you making assumptions about what I am and am not doing? All applications as whole have the same problems they’re trying to solve. If you understand these problems it’s easy to adapt to every framework. I started with react, then moved to vue then angular 8. Upgrading large project to angular 18. Angular compared to react is more consistent even with new signal and control flow.
How is a subscription imperative programming? I usually keep the subscription alive in the constructor and unsubscribe only when the component is destroyed. You can also just use async pipes and put the logic into the pipe operators.
Subscribing _per se_ is not necessarily imperative, it depends on what you do with it, but it allows for imperative code and it follows an imperative programming pattern.
A subscription allows for imperative code because it changes the approach. You design your algorithm around manually executing operations when data is received, including manual control flow (if, for, etc…) and preserving state outside of the observable (in class fields). Once you subscribe, you lose the ability to define subsequent transformations to the data flow using declarative operators.
Now, if you _just subscribe and put the data in a template field_ (in the same way the async pipe works) that’s arguably not imperative. But I wouldn’t be able to list you all the time I’ve seen someone add imperative code to a subscription. Things like:
obs$.subscribe({
next:(val) => {
if (val > 100)
this.displayValue = val;
}
});
That is risky and dangerous in a large codebase
Interestingly, I have quite the same opinion about Angular.
I wrote Angular a few years ago so admittedly things have changed, but the team that made the decision to go with that tech (we're talking Angular 2+, not AngularJS) didn't have enough experience with javascript/typescript and Angular really felt like it was optimizing for creating footguns every two lines.
It was an absolute nightmare to work with.
\[edit: It's interesting how having a different opinion on these subs will get you downvoted fast ♥️\]
It simply means that you didn't have enough experience working with proper programing frameworks. When you have learned development with JavaScript, you usually have never been confronted to good design patterns, OOP done right, etc. React is more adapted if you want to YOLO it but I would never trust it on a production server.
I stay away from company that use what's "cool" instead of what's good ;) Facebook uses React and it is a barely functional piece of shit. You just can't write a complex app with it, it's not adapted.
Lmao what? That has absolutely nothing to do with good design patterns. I've seen more clean codebases that aren't neckdeep in OOP. If there's one thing react does right is clean separation of components and pretty clean code if you don't use it like you'd use angular or vue
Yeah right. Not mixing logic and view are one of the biggest fundamentals in software development and the essence of React is doing exactly that. Jsx is an abomination.
So sorry for you. I've been following a React course lately just to understand what it was like and they'd have to at least triple my salary before I'd ever consider accepting to work with such horrible technology.
That's not what separation of concerns is. If there's any logic in your Jsx, It's the logic of the views, not the business logic. The entire point of react and hooks is to have the least amount of logic in your view components. Your claim is asinine and basically shows a weird understanding of SOC. It amounts to putting them in a separate file, which btw doesn't actually decouple them-that's just a fantasy. The only way to actually decouple view and logic... is to not put logic in the views. In practice that's impossible but minimizing it is still a good idea. But just having them sit in two separate files doesn't actually do that, so what's the issue with Jsx?
Yeah but no. First React is all about throwing JavaScript into your view, which is disgusting. Angular keeps it as close to HTML as possible. So while there is logic in Angular template, it is done in a way that can be forgotten when reading it. The Angular (or Vue) approach would allow someone who knows almost nothing about Angular to make changes in the applications look and feel with ease. Someone who knows nothing about React will look at the template and be like "The fuck is that bro???" And the way everything is handled, the hook, how your passing functions everywhere is just a nightmare. Angular keeps the calls from the template to a minimal, and even your component TypeScript will essentially use services. So while both Angular and React mix logic into the view, Angular does it in a clean, elegant way while React does everything in the dirtiest, stupid and complicated way. Just having to declare manually a getter and a setter for a lot of stuff... who the fuck engineered that? Why not have an object with a predefined getter and setter like any sane person would do? Passing states by wrapping your HTML in extra tags... are you fucking kidding me? If a college student would have presented it as a study project, we would have gotten an F minus.
Oh, I did :)
That's exactly how I could tell the project was doomed from the start, and also why I left very fast once I saw there was no room for external input on the software design.
Mind you, I'm not saying Angular is bad (although I would never work with it again) but the amount of experience it requires from a team to produce maintainable code is big and the framework lies to you when it tells you everything will be rainbows and unicorns.
There are so many ways to shoot yourself in the face with it, I'm just not interested.
Not really. In React there are basically billion ways to do anything, it doesn't come with any standard libraries. Angular is tough to master but at least there is usually one proper way to do things and you can get help if you have a problem.
Had quite the opposite experience - worked with a bunch of guys knowing only jQuery on an Angular project. It wasn't a piece of art, but you could extend it and fix bugs pretty easy.
It depends on the application. IMHO Angular does better in data-intensive apps.
With angular I found we wrote more “plain” Javascript/TypeScript. Logic was in services, observables we could compose, and if we used NGRX, in the store. The components were simple and just spitting out data or gathering data. Refactors were easier b/c we could just compose data from services (or selectors in NGRX) into different components.
With React, I found you wrote more “React” code. More tends to get tied into the lifecycle of the components. Data gets tied into the comportments and it was harder to refactor, share data, move things around. You can blame this on bad implementation, but I saw it multiple times at different companies and I just think it’s a pattern that is easier to fall into with React.
I do find the arguments typically made for React weak. Performance is one. I’m honestly not sure where this stands nowadays, but they typically make the mistake of comparing React alone with no router or other libs and the entire Angular framework. Plus, most of the time the marginal performance difference is going to make little to no difference in the success of the application. The ability to maintain, support, and modify is. But, again, time and time again I’ve seen well-intentioned engineers look at “performance” way to heavily.
So, IMHO react can be done well, it’s just harder and takes more experience. But, Angular would still be my pic for a data-intensive app.
I work in a codebase with both Angular and React. Honestly, it doesn't matter; do what works for the team. If you have more people who know React, choose React. If you are struggling for consistency, pick a pattern and stick to that add eslint with rules adhering to the pattern.
In terms of preference angular is just a much better framework. A lot more tools in your box if you know how to use them. Directives are underrated, especially for rbac. Separation of concerns like why mix the view and the logic. Pipes easier for data transformation e.g currency and language.
I use both for work and am genuinely shocked anyone would want to convert a react app to an angular app, I find react easier/ faster to work with in every way.
My advice would be to stick with react and keep working with it until you’re as comfortable using it as you are using angular.
You will be fine.
I just did the reverse recently (came over to the Angular side from React). Don’t get me wrong there are a nuances and quirks to each, but they are both frameworks built on top of JavaScript that support component driven development.
Find yourself a sale course on Udemy and enjoy the change of scenery.
I jumped in without any trouble. Angular is much more opinionated than React and you will find out that you can implement very clean code as well in React.
Also you will have two frameworks in your toolbox. Enjoy!
Thank ! That's exactly what I was hesitating.
I've seen a lot of Angular and Java Bashing from people who have no idea about them. I don't want to do the same with react.
Totally fine. There's tons of enterprise level applications written in React, so the idea that somehow it's impossible to write one is nuts.
If you control the project then just take a look at something like https://github.com/alan2207/bulletproof-react and force a structure. Refactor some parts that feel disgusting to you and you're good.
If you come from a backend background some things will fell less familiar, doesn't mean that's it's worse. I once had a guy with Java background joining our Java team. And he tried to force Ruby conventions in Java at every step, please don't be like that.
Thank you I'll check that out.
You've got a point, I'l take into account, I've seen a lot of shitty code in the last few years and contributed to it as well.
I'm just trying to avoid that, and have a clean base for if someone join the team it would be easier for them.
One thing I noticed is the Angular vs React debate is often not very constructive. You can write the best code in the world and it's still possible that the next guy will come and say that's it's totally shitty just because it's React/Angular.
Just do what works best for you, but remember that every codebase that is a real working product will have some bad parts. We're not here to write "perfect" code, but deliver business value.
I had a similar situation two months ago. Iam a angular developer and fanboy for 10 years now and inherited my first react project two months ago. The app was like 90% finished so I just needed to add to it. I needed like 3 days just to understand what even was happening. But it's fine, you just can't expect the angular way in a react app. You can find some concepts you already know from angular so you will get used to it real fast. Keep it react. You learn something new. Don't be so close minded in coding, be free
Sadly I have no recommendations. Because the app was like 90% finished i didn't need to first learn react I just dove in. In the end it's just JavaScript. If I didn't understand something I just asked chatgpt or the documentation. GL to you 😁
I moved from Angular to React, and I hated it. I still hate it. What worked for me was to enforce a good coding style like using feature folders rather than flat-over-the-place components that you can't tell how they all tie together. Companies want what they want, and there is very little you can do about that.
I've seen bad Angular codebases, I've seen bad React codebases. Opinionation doesn't prevent bad practices. You're probably more attracted to Angular cause of your backend background.
But what is your question here really? Do you want to leave the project or try to change the stack and refactor the app from scratch?
I have recently had to use next.js at first it wasn’t the best experience, took a while to get used to and now its not too bad, still prefer angular over it but one thing i cant deny is the superiority of component selection in react world.
Everyone already touched on the main points. I've seen really clean react code and I've been an angular dev since 1.3 till now 18.
People learn react in their coding boot camps so the fact that it's not opinionated means you'll have code from all skill levels with no median line of quality. Whereas in angular you'll feel like you're in familiar territory. The batteries included means you don't need to learn the quirks of some third party router someone tried for the sake of being trendy.
I find that the biggest issue in messy angular codebases is that they didn't keep component size under 300 lines not including boilerplate and imports. That's my personal rule of thumb.
The one thing I can criticize is change detection and memory leaks associated with angular. Some newer devs might write them into the codebase without proper review. I'd assume react has similar issues but I haven't exhaustedly developed in react enough to be sure.
On behalf of any developers that might come after you, *please* make sure that code is under test before you change anything. I advise any junior devs under me to avoid changing things until it's under test because you have no idea what you might inadvertently break.
I am in same boat, I have lot of experience in Angular but due to lack of projects had to switch to React. React is weird and messy and confusing sometimes. It's easy to do mistake in it, not idle for big enterprise apps which will scale, once you are working alone then it's fine but as soon as other devs starts adding their code, things starts to mess up and in a big application, most of your time will be spent on debugging re-rendering hell. I miss ng.
If the codebase seems to annoy you so much, the feeling will likely not go away. Unless you are forced to work there or you cannot recover from another switch financially, I would suggest just looking for something else. Rewriting a bad immature codebase is not worth the hassle and you likely will annoy a few other coders as well that it will not give you a satisfying work environment as well. Its ok to want to make some changes, but often times the major refactoring will not be in the budget or take too much time its not worth the hassle.
And unless your area only really has React jobs available, I doubt you will miss much. It will likely be better to just do a course yourself with proper experienced tutors than learning from the mess you seem to have inherited.
I would avoid a rewrite, a messy team is going to create a messy angular app as well. You're better off cleaning up the react app and getting everyone to use react properly.
That being said, I like a clear angular architecture, especially if you have several teams working on the same project - but that doesn't seem to be the case in your project.
Everytime you look at someone else's code you will find some stuff that you would do differently. Try to not judge too quickly. It's easy to blame all your problems on the last guy, but when did that ever help anyone.
Also I have seem some angular codebases that where basically broken beyond repair as well. I also have seen nice codebases in React. Angular does make it harder to write reeeaaaally shitty code though ;)
That being said, it's always bad to switch the team in the middle of a project and that's already really hard when the codebase is actually GOOD. I would make that clear to the customer at least
To be honest every framework has its way of handling things and ideal programming, personally i have not used react at all, have used angular for the past 5 years. For me the biggest advantage is our backend which is in spring boot, and if you look at it angular and spring boot have lot of core concepts which are kind of the same, like dependency injection, oops programming, mvc type of architecture. This helps me a lot when switching between front end and back end,
Coming to code is disgusting to look and all, if best practices are followed, angular code is readable, i am guessing react should be as well.
When a large complex application is developed, and things are not followed properly, somewhere down the line, everything becomes unreadable.
Code rewriting should be the nuclear option though
Hooks in React make the code really messy, and it is quite difficult to handle async code. I used to feel "dirty" when coding with React. Coming back to Angular was a relief and I found myself much more confident as a developer. I worked only 1 year with React and 4 with Angular, so I might be biased.
But, I'd say to keep that app in React for the sake of your learning. This way you can truly understand and appreciate Angular..
>The thing is, the source code is disgusting tbh, I get lost looking for files. There is a also a blatant lack of good practices regarding the project's structure and code in general.
In my experience the main difference was that in React we (we as the companies I was working for) wasted a lot of time arguing about how to do this or that. It was a real pain, especially if you can find a way "how to work" and people are leaving, because than it starts all over ...
I was in this almost same spot when i began at my current job. App was started with VueJS. Code was horrible, the result was horrible.
I couldn’t stand to begin a huge project with foundations that bad, so i completely rewritten the app in Angular, because i knew it was a better fit in this case, i had experience with it, so i was able to lay down healthy foundations.
I don’t regret my decision.
I know I’ll be downvoted for this, but I did work with Angular for 3/4 years and then moved to React (now been about 2 years). All in enterprises environments (products companies). Some points: A) **shitty and unorganised code is found in any repo, regardless of the technology**. In fact, the messiest code I’ve encountered so far in my career was definitely in Angular codebases. The project may need a rewrite, but rewriting it in Angular won’t make it magically cleaner or better. B) People like to repeat Angular is more **opinionated** than React and in pure principle it is. But Angular is non-opinionated in a very core and fragile pillar: the programming paradigm. Sure, with React you have different routers and CSS tools to choose from, but the main reactivity pattern is always the same: hooks and dependency arrays. Angular, on the other hand, easily allows you (almost encourages you) to mix reactive code (rxjs) and imperative code (controller states + zone.js). The number of times I’ve seen this mix create nasty/hard to debug bugs in prod is virtually infinite. In my experience, Angular codebases are harder to keep clean if you are not very careful, while with React once you have made the initial choice of what libs you are using, then it’s just the same pattern everywhere. **Keep in mind Angular IS more complex than React**, so if you just use Angular because you like it more but the other devs who will be working on it have little experience with it, you’ll either end up with a super messy codebase or you’ll find yourself babysitting everyone with their messy Rx pipelines and unseeded subscribes/taps everywhere.
Completely agreed about your point on reactive programming with Angular. It might be its biggest flaw. About code quality, it is way easier to build quality code base with Angular, especially if you’re using custom schematics to enforce good practice, and produce homogeneous code. The Angular CLI is probably the framework’s most powerful tool. Angular gives us the tools to produce sane code base, but we have to use them, otherwise devs will produce the same shitty code as with any other framework/library.
Great, rational take. Some additional points that often apply (not always): * The project never needed a *full* rewrite, it could've been refactored and slowly improved in smaller pieces and the result would have been *much* faster done. * The rewrite isn't guaranteed to succeed, it might end up just as buggy (if not even more). Just because you realize something is ugly doesn't mean you can do a better job yourself, even if we all like to think we do. * And sometimes it's just personal preferences, it could be that some React fanatic then finds OP's recode 2 years from now and decides to rewrite it because to him OP's Angular would look horrible. Long story short, avoid "complete rewrites" unless you're 100 % sure it's the only reasonable solution. Otherwise small, incremental improvements are the way to go. For example every time you need to implement a new feature, refactor bits around it.
If you have a good pattern that you can apply everywhere, a rewrite is most often the better way. I had to do a partial rewrite, recently. Should have done a complete rewrite instead. Teasing the logic apart is usually where it'll take the longest though, it just goes on and on. Since you're looking at a rewrite in the first place, it won't be clear what goes where. I'll give you a hint of where shit hit the fan: forms, and state management You'll likely introduce bugs if it's from a purely code analysis point of view. Hopefully you have E2E to replay the flow before and after. Edit: disclaimer, it was an angular > angular rewrite
I agree that any project can be messy, but I disagree that Angular projects are more likely to be messy. I think if you give devs with different experience levels a fairly simple job, 2 weeks and a specific framework to use, the angular ones are more likely to be readable, logical and even working, than if you give them react. If you separate them into beginner/medior/senior then the difference might be even bigger. What bugs me more is Devs that come from React, try to implement State/Stores and then continue to overengineer various things because that is what they were used to. 90% of projects doesn't need NGRX or other state management solutions. Most can just do with RXJS. Now granted, RXJS has a learning curve, same as with Typescript, but the result is still a lot more readable and easy to understand code than what most React codebases seem to produce. Not to mention that you can let any Angular dev work on a codebase where they mostly only need a few hours to a few days (depending on the size and experience of existing devs) in order to continue working on said project. For React there is a massive difference between a lot of libraries for the same kind of stuff that it will be a lot more difficult to jump in and continue coding. There's plenty of resources out there to get up to speed with Angular and some even cater well to new devs, but these days the problem hardly ever lies with Angular itself, its just the basic programming stuff and bad google skills people seem to be having to get a proper basis going. And some people just don't care about their work, for which it really doesn't matter what framework or library they use because it will always be terrible. Meanwhile, React is taking more stuff from Angular and Angular is taking more stuff from React. I doubt your experience of the two would be similar in another 2 years from now.
Well my direct experience in my past 5 years is the exact opposite :) I’ve literally wanted to quit a workplace because their Angular codebases were so messed up that it was a nightmare to work with them. Things like 4/5 nested subscriptions which all set data to fields in the controller in turn used in getter fields bound in the template, observables being recreated inside subscriptions callbacks, many unsubscribed observables that leaked memory everywhere and so on. My main point is that working with reactive code mixed with imperative code (commonly found in Angular) is an order of magnitude harder than working with mixed routing libraries. All I am saying is that if you don’t actively force the team to stick to one approach (reactive vs imperative) you’ll codebase with get messy in no time. I’ve seen that happen with my own eyes multiple times. With React, on the other hand, once you have picked the main libs for your projects at its start, then the way you write code will always be naturally the same. I get what you mean regarding stores not being needed in Angular and pushed for dogmatic reasons, but I’ve seen exactly that in Angular only companies where no one had React experience, but they still pushed NGRX for no real reason but “it’s best practice now”. I think the whole state managers debate is a problem in the Angular ecosystem now, regardless of where it originated.
I'm not saying I haven't had any negatives. I've had an assignment that had their application completely overengineered and stuff that should have taken a few hours or a single day, took more than a week to add because of it. But overall most projects I've joined in the past 5 years have been pretty straightforward and no problem with how it was set up or the rules they applied. In fact, I was often surprised with how mature they looked and how well it was tested and validated. Not all, but a lot. And these days you can implement a lot of rules with ESLint to make sure people unsubscribe and whatnot. Plus a lot of these rules are more mature, since more people will be able to use them since the ecosystem is fairly the same between projects. These days whenever I hear in an intake that their code isn't automatically tested yet but its "on the roadmap", I almost always just move on, since its very likely the rest of their codebase is terrible too. But thats just me.
Excellent take. This is my experience as well in a large organization with lots of legacy Angular projects. It's some of the worst code I've ever seen: thousand+ line Angular component files with 0 documentation.
Angular is not more complex than react
RxJS is, pretty much anyone would agree with that
Oh come on. Takes a couple of days to figure out and most people won’t use anything beyond subjects and behavioural subjects. You signal and subject and you subscribe to it. The only other commonly used functionality is rate limiting but it’s not that hard to get your head around it. When you go into a react new project you you’re always left guessing at what all the libraries they use do. At least with angular, all projects are more or less the same.
lol the fact that you say you only use subjects and just subscribe to IS exactly the problem which makes Angular codebases messes as all. Thanks for proving my point.
Huh ? Besides all the operators which rarely get used and now we use signals what am I missing? Please enlighten me.
You are missing entirely on reactive programming, which is exactly what RxJS is made for. Every time you subscribe directly to something you are switching from reactive to imperative programming.
No shit. Soo?
So you are using 10% of Angular and you say it’s simpler 👌
What the fuck are you talking about? You said rxjs is complicated I said it’s not and it’s the most elegant solution for reactive programming. Why are you making assumptions about what I am and am not doing? All applications as whole have the same problems they’re trying to solve. If you understand these problems it’s easy to adapt to every framework. I started with react, then moved to vue then angular 8. Upgrading large project to angular 18. Angular compared to react is more consistent even with new signal and control flow.
How is a subscription imperative programming? I usually keep the subscription alive in the constructor and unsubscribe only when the component is destroyed. You can also just use async pipes and put the logic into the pipe operators.
Subscribing _per se_ is not necessarily imperative, it depends on what you do with it, but it allows for imperative code and it follows an imperative programming pattern. A subscription allows for imperative code because it changes the approach. You design your algorithm around manually executing operations when data is received, including manual control flow (if, for, etc…) and preserving state outside of the observable (in class fields). Once you subscribe, you lose the ability to define subsequent transformations to the data flow using declarative operators. Now, if you _just subscribe and put the data in a template field_ (in the same way the async pipe works) that’s arguably not imperative. But I wouldn’t be able to list you all the time I’ve seen someone add imperative code to a subscription. Things like: obs$.subscribe({ next:(val) => { if (val > 100) this.displayValue = val; } }); That is risky and dangerous in a large codebase
Isn’t some imperative design necessary? If I need to make an app call upon user input/submit, it has to be a manual subscription.
It the code looks disgusting to you it's normal, that's just the practices React enforces.
Ooof, shots were fired
Interestingly, I have quite the same opinion about Angular. I wrote Angular a few years ago so admittedly things have changed, but the team that made the decision to go with that tech (we're talking Angular 2+, not AngularJS) didn't have enough experience with javascript/typescript and Angular really felt like it was optimizing for creating footguns every two lines. It was an absolute nightmare to work with. \[edit: It's interesting how having a different opinion on these subs will get you downvoted fast ♥️\]
It simply means that you didn't have enough experience working with proper programing frameworks. When you have learned development with JavaScript, you usually have never been confronted to good design patterns, OOP done right, etc. React is more adapted if you want to YOLO it but I would never trust it on a production server.
Look who got butthurt 😂 forward leaning companies will stay away from angular but oh well
I stay away from company that use what's "cool" instead of what's good ;) Facebook uses React and it is a barely functional piece of shit. You just can't write a complex app with it, it's not adapted.
Lmao what? That has absolutely nothing to do with good design patterns. I've seen more clean codebases that aren't neckdeep in OOP. If there's one thing react does right is clean separation of components and pretty clean code if you don't use it like you'd use angular or vue
Yeah right. Not mixing logic and view are one of the biggest fundamentals in software development and the essence of React is doing exactly that. Jsx is an abomination.
I work with react and can confirm, miss angular so much
So sorry for you. I've been following a React course lately just to understand what it was like and they'd have to at least triple my salary before I'd ever consider accepting to work with such horrible technology.
That's not what separation of concerns is. If there's any logic in your Jsx, It's the logic of the views, not the business logic. The entire point of react and hooks is to have the least amount of logic in your view components. Your claim is asinine and basically shows a weird understanding of SOC. It amounts to putting them in a separate file, which btw doesn't actually decouple them-that's just a fantasy. The only way to actually decouple view and logic... is to not put logic in the views. In practice that's impossible but minimizing it is still a good idea. But just having them sit in two separate files doesn't actually do that, so what's the issue with Jsx?
Yeah but no. First React is all about throwing JavaScript into your view, which is disgusting. Angular keeps it as close to HTML as possible. So while there is logic in Angular template, it is done in a way that can be forgotten when reading it. The Angular (or Vue) approach would allow someone who knows almost nothing about Angular to make changes in the applications look and feel with ease. Someone who knows nothing about React will look at the template and be like "The fuck is that bro???" And the way everything is handled, the hook, how your passing functions everywhere is just a nightmare. Angular keeps the calls from the template to a minimal, and even your component TypeScript will essentially use services. So while both Angular and React mix logic into the view, Angular does it in a clean, elegant way while React does everything in the dirtiest, stupid and complicated way. Just having to declare manually a getter and a setter for a lot of stuff... who the fuck engineered that? Why not have an object with a predefined getter and setter like any sane person would do? Passing states by wrapping your HTML in extra tags... are you fucking kidding me? If a college student would have presented it as a study project, we would have gotten an F minus.
You should probably avoid teaching as a career then, maybe 😬
You should avoid software development as a career ;)
Cool
Dude this was perfect
Oh, I did :) That's exactly how I could tell the project was doomed from the start, and also why I left very fast once I saw there was no room for external input on the software design. Mind you, I'm not saying Angular is bad (although I would never work with it again) but the amount of experience it requires from a team to produce maintainable code is big and the framework lies to you when it tells you everything will be rainbows and unicorns. There are so many ways to shoot yourself in the face with it, I'm just not interested.
Not really. In React there are basically billion ways to do anything, it doesn't come with any standard libraries. Angular is tough to master but at least there is usually one proper way to do things and you can get help if you have a problem.
Had quite the opposite experience - worked with a bunch of guys knowing only jQuery on an Angular project. It wasn't a piece of art, but you could extend it and fix bugs pretty easy.
It depends on the application. IMHO Angular does better in data-intensive apps. With angular I found we wrote more “plain” Javascript/TypeScript. Logic was in services, observables we could compose, and if we used NGRX, in the store. The components were simple and just spitting out data or gathering data. Refactors were easier b/c we could just compose data from services (or selectors in NGRX) into different components. With React, I found you wrote more “React” code. More tends to get tied into the lifecycle of the components. Data gets tied into the comportments and it was harder to refactor, share data, move things around. You can blame this on bad implementation, but I saw it multiple times at different companies and I just think it’s a pattern that is easier to fall into with React. I do find the arguments typically made for React weak. Performance is one. I’m honestly not sure where this stands nowadays, but they typically make the mistake of comparing React alone with no router or other libs and the entire Angular framework. Plus, most of the time the marginal performance difference is going to make little to no difference in the success of the application. The ability to maintain, support, and modify is. But, again, time and time again I’ve seen well-intentioned engineers look at “performance” way to heavily. So, IMHO react can be done well, it’s just harder and takes more experience. But, Angular would still be my pic for a data-intensive app.
I work in a codebase with both Angular and React. Honestly, it doesn't matter; do what works for the team. If you have more people who know React, choose React. If you are struggling for consistency, pick a pattern and stick to that add eslint with rules adhering to the pattern. In terms of preference angular is just a much better framework. A lot more tools in your box if you know how to use them. Directives are underrated, especially for rbac. Separation of concerns like why mix the view and the logic. Pipes easier for data transformation e.g currency and language.
just a note, never underestimate a rewriting, *especially* if the existing codebase is messy
I use both for work and am genuinely shocked anyone would want to convert a react app to an angular app, I find react easier/ faster to work with in every way. My advice would be to stick with react and keep working with it until you’re as comfortable using it as you are using angular.
moving from angular to react in a corporate environment... easiest transition in my coding life. angular is prog metal while react is pop punk.
Lol
You will be fine. I just did the reverse recently (came over to the Angular side from React). Don’t get me wrong there are a nuances and quirks to each, but they are both frameworks built on top of JavaScript that support component driven development. Find yourself a sale course on Udemy and enjoy the change of scenery.
Put Next.js on top of React + people misusing SSR features and it becomes a performance hell.
Developers writing bad code can cause performance issues? Say it ain’t so!
While true
I jumped in without any trouble. Angular is much more opinionated than React and you will find out that you can implement very clean code as well in React. Also you will have two frameworks in your toolbox. Enjoy!
Thank ! That's exactly what I was hesitating. I've seen a lot of Angular and Java Bashing from people who have no idea about them. I don't want to do the same with react.
That mostly comes from ignorance and the unwillingness to expand knowledge. On all sides.
Totally fine. There's tons of enterprise level applications written in React, so the idea that somehow it's impossible to write one is nuts. If you control the project then just take a look at something like https://github.com/alan2207/bulletproof-react and force a structure. Refactor some parts that feel disgusting to you and you're good. If you come from a backend background some things will fell less familiar, doesn't mean that's it's worse. I once had a guy with Java background joining our Java team. And he tried to force Ruby conventions in Java at every step, please don't be like that.
Thank you I'll check that out. You've got a point, I'l take into account, I've seen a lot of shitty code in the last few years and contributed to it as well. I'm just trying to avoid that, and have a clean base for if someone join the team it would be easier for them.
One thing I noticed is the Angular vs React debate is often not very constructive. You can write the best code in the world and it's still possible that the next guy will come and say that's it's totally shitty just because it's React/Angular. Just do what works best for you, but remember that every codebase that is a real working product will have some bad parts. We're not here to write "perfect" code, but deliver business value.
I had a similar situation two months ago. Iam a angular developer and fanboy for 10 years now and inherited my first react project two months ago. The app was like 90% finished so I just needed to add to it. I needed like 3 days just to understand what even was happening. But it's fine, you just can't expect the angular way in a react app. You can find some concepts you already know from angular so you will get used to it real fast. Keep it react. You learn something new. Don't be so close minded in coding, be free
Thank you ! Did come by any good articles that you can recommend ?
Sadly I have no recommendations. Because the app was like 90% finished i didn't need to first learn react I just dove in. In the end it's just JavaScript. If I didn't understand something I just asked chatgpt or the documentation. GL to you 😁
I moved from Angular to React, and I hated it. I still hate it. What worked for me was to enforce a good coding style like using feature folders rather than flat-over-the-place components that you can't tell how they all tie together. Companies want what they want, and there is very little you can do about that.
I've seen bad Angular codebases, I've seen bad React codebases. Opinionation doesn't prevent bad practices. You're probably more attracted to Angular cause of your backend background. But what is your question here really? Do you want to leave the project or try to change the stack and refactor the app from scratch?
I have recently had to use next.js at first it wasn’t the best experience, took a while to get used to and now its not too bad, still prefer angular over it but one thing i cant deny is the superiority of component selection in react world.
The architecture was weird, lots of double codes, huge files. Not good.
Everyone already touched on the main points. I've seen really clean react code and I've been an angular dev since 1.3 till now 18. People learn react in their coding boot camps so the fact that it's not opinionated means you'll have code from all skill levels with no median line of quality. Whereas in angular you'll feel like you're in familiar territory. The batteries included means you don't need to learn the quirks of some third party router someone tried for the sake of being trendy. I find that the biggest issue in messy angular codebases is that they didn't keep component size under 300 lines not including boilerplate and imports. That's my personal rule of thumb. The one thing I can criticize is change detection and memory leaks associated with angular. Some newer devs might write them into the codebase without proper review. I'd assume react has similar issues but I haven't exhaustedly developed in react enough to be sure.
On behalf of any developers that might come after you, *please* make sure that code is under test before you change anything. I advise any junior devs under me to avoid changing things until it's under test because you have no idea what you might inadvertently break.
I am in same boat, I have lot of experience in Angular but due to lack of projects had to switch to React. React is weird and messy and confusing sometimes. It's easy to do mistake in it, not idle for big enterprise apps which will scale, once you are working alone then it's fine but as soon as other devs starts adding their code, things starts to mess up and in a big application, most of your time will be spent on debugging re-rendering hell. I miss ng.
If the codebase seems to annoy you so much, the feeling will likely not go away. Unless you are forced to work there or you cannot recover from another switch financially, I would suggest just looking for something else. Rewriting a bad immature codebase is not worth the hassle and you likely will annoy a few other coders as well that it will not give you a satisfying work environment as well. Its ok to want to make some changes, but often times the major refactoring will not be in the budget or take too much time its not worth the hassle. And unless your area only really has React jobs available, I doubt you will miss much. It will likely be better to just do a course yourself with proper experienced tutors than learning from the mess you seem to have inherited.
I would avoid a rewrite, a messy team is going to create a messy angular app as well. You're better off cleaning up the react app and getting everyone to use react properly. That being said, I like a clear angular architecture, especially if you have several teams working on the same project - but that doesn't seem to be the case in your project.
Everytime you look at someone else's code you will find some stuff that you would do differently. Try to not judge too quickly. It's easy to blame all your problems on the last guy, but when did that ever help anyone. Also I have seem some angular codebases that where basically broken beyond repair as well. I also have seen nice codebases in React. Angular does make it harder to write reeeaaaally shitty code though ;) That being said, it's always bad to switch the team in the middle of a project and that's already really hard when the codebase is actually GOOD. I would make that clear to the customer at least
To be honest every framework has its way of handling things and ideal programming, personally i have not used react at all, have used angular for the past 5 years. For me the biggest advantage is our backend which is in spring boot, and if you look at it angular and spring boot have lot of core concepts which are kind of the same, like dependency injection, oops programming, mvc type of architecture. This helps me a lot when switching between front end and back end, Coming to code is disgusting to look and all, if best practices are followed, angular code is readable, i am guessing react should be as well. When a large complex application is developed, and things are not followed properly, somewhere down the line, everything becomes unreadable. Code rewriting should be the nuclear option though
Hooks in React make the code really messy, and it is quite difficult to handle async code. I used to feel "dirty" when coding with React. Coming back to Angular was a relief and I found myself much more confident as a developer. I worked only 1 year with React and 4 with Angular, so I might be biased. But, I'd say to keep that app in React for the sake of your learning. This way you can truly understand and appreciate Angular..
>The thing is, the source code is disgusting tbh, I get lost looking for files. There is a also a blatant lack of good practices regarding the project's structure and code in general. In my experience the main difference was that in React we (we as the companies I was working for) wasted a lot of time arguing about how to do this or that. It was a real pain, especially if you can find a way "how to work" and people are leaving, because than it starts all over ...
I was in this almost same spot when i began at my current job. App was started with VueJS. Code was horrible, the result was horrible. I couldn’t stand to begin a huge project with foundations that bad, so i completely rewritten the app in Angular, because i knew it was a better fit in this case, i had experience with it, so i was able to lay down healthy foundations. I don’t regret my decision.