Intro - I'm an Angular developer and the title is not click-bait.
I've been working with Angular (From V4 to V9) for at least 1.5 years ...
For further actions, you may consider blocking this person and/or reporting abuse
Nice 😄,
I think
Angularis for large projects.Reactfor mid size projects.Is
Reactmaintainable for large projects ?Hi SaijuT, I've been working with React for 5 years now on projects of every size.
In my opinion, it is possible to have a large maintainable React project, but you really need a strong architectural design at the root to create the perfect folder/code structure for that project.
The biggest issues in React are component responsibility, communication and state-management. If every component is in the right place in the architecture and everything is done perfectly, then you're good.
Also, it's really important to think in React. Sometimes I see projects with a mix of React-style functional code, javascript classes (OOP stuff in general), hoc and other patterns.
Mixing is not good for maintainability. Which brings us to have a team that writes the same code (eslint helps with that). If not, it's just a nightmare.
Using a framework like Next.js or a state-management library like Redux helps less-experienced devs to have a forced structure which improves maintainability. Typescript and tests are also a must.
At the end of the day, maintainability is a matter of best practices and well-designed software. Sometimes we, as developers, prefer spending more time on coding than on planning stuff on a piece of paper.
This is just my opinion and experience so far. What do you think? :)
Appreciate 😄, for taking time to write. Actually as of today I have just learned
Angularbasics. Right now I am not in right position to compare both. But i asked the question with intention of just knowing what others think.Few more questions:
Angularis it more maintainable with build inTypescriptsupport or is it up to the developer to make the project maintainable ?Typescriptto buildReactapps or Just vanillaJavascript?I've used React with both vanilla Javascript and Typescript. My opinion on that is that with Typescript you don't have to worry about static type errors. It's just another thing off your mind. And kind of forces you to design more because you have to think in advance what kind of data you have/receive. So yes, it really helps with maintainability. Also, it's easier for other people to read through your code and know instantly if that prop is supposed to be a string, a number or both.
I don't know much about Angular, but what I know is that it has more of a horizontal structure, compared to the tree-like structure of React. This means that in Angular you have a few folders with many files, while in React is easier to work with many folders (one per component) with usually a lot of files within (js, styles, tests, reducers for state-management, schemas and types, API calls and so on).
Of course, in either of them, you can structure the folders as you most like them. But usually, you wouldn't want to go against the way the library thinks.
I hope that makes sense! :D
I'll give my two cents on the thread: React is more "free" and, in my opinion, is less feasible for junior developers. Even if angular has a steeper learning curve, it provides structure, rules and linting, something you have to do yourself in React. That's the point of this topic: React is empowered by Angular, in some ways.
Absolutely agree. Many things done by create-react-app (mostly linting and structure rules) have probably been taken from Angular and frameworks from every language. I believe we could gain experience from every library/framework we learn and use it with the most appropriate for the project (or simply our favourite, in simpler cases :) )
In a way, I agree with the title in the sense of "know Angular beforehand to see how much better you could be doing things with React".
After having to learn both to work with on enterprise projects, I prefer React hands down. I feel Angular is too cumbersome and one needs like a lot of boilerplate to get started (I know it's useful to have an opinionated way to do things and to scale better but still...)
Still, I don't really like either of them as much as plain JS but they're the most popular and the ones that have given me work for the last 2.5 years so yeah...
I agree with most of your comment. You HAVE to learn one of those two to get a nice job but still, vanila JS gives you that bit of "Hey man, I'll take care of it" vibe on your projects ahah
Still, I guess React is more vanillajs*ish*, so maybe that's why many experienced developers choose it. Don't you agree?
I think that makes sense. Taking out JSX, React is pretty much a more organized way of writing vanilla JS.
And I can see how if someone is already very used to writing JS, putting the markup and the styling inside .js files will make them feel "at home".
Especially with hooks, nowadays React looks like your writing "just javascript"
This summed my experience with it as well. Coming from Angular and moving to React, you can appreciate the training wheels you get with Angular while bringing what you've learned to React. What causes me to stick with React is perhaps the level of flexibility and state-awareness. Angular requires you to pipe async traffic through god-knows how many observables and chains, while in React, all components receive the state snapshots. If you hide rxjs behind a layer of abstraction, I'm sure you can eventually achieve a similar experience with Angular, but the default change detection will probably destroy your app in the meantime.
The issue with Angular vs React is that it's not a "this one is better for x size app" problem, it's a "React is a toolbelt and Angular is a prebuilt template with strict rules" problem. You can use React the same way you do Angular, or you can use React for different things. A software engineer should be aware of the differences and should not expect the same things from each technology.
Yes agree. Thanks. :)
I completely agree with that. In my conclusion, in fact, I say exactly that. Having both in my tool belt allows me to essentially get the best of both words.
I actually tried to learn angular back in 2017 but couldn't wrap my head around it at first. Eventually I ended up on a team that was doing react and it all started to make sense.
You mention taking the services concept from angular and using it in react, i'm curious about that do you have any code examples you could point to?
Hi Omar, I'm sorry I can't as I'm answering from a PC without the source code, but simple enough, I just used the "http service rule" from Angular, which allows you to build services around HTTP Requests, and brought it inside utility files which I import and use whenever I need those. The concept of singletons, also, is widely popular and used in Angular and using it in React gives a lot of flexibility if you know how to deal with it.
Once I first introduced with react, I didn't really understood it, then shifted to node then to nestjs coming to nestjs made me come to angular, despite it's being difficult I actually grasped it pretty quickly, even quicker than I did for react, maybe having all the stuff in one file wasn't for me, I really liked architecture you get out of the box with angular and having separation of concerns. And currently I'm doing my project in angular which I originally planned to do it with react, nestjs saved me.
I bet learning vuejs for you took 3 minutes only.
I guess you were being sarcastic, but still I'll answer: It took me a couple of weeks to grasp some benefits from the framework and, during that period, I just used the runtime version and never had the chance to look at components in Vue, so I guess I still had a long journey to master it.
No. I mean Vuejs is easier than Reactjs TBH.
Oh ok, sorry for the misunderstanding then :)
As said, it took me much more time for less gains as I was pretty much a javascript newbie and many things weren't easy for me to understand.
Of course there are many people starting from Vue and switching to React for many reasons and it could suite too, mine was just a "Here's how it worked for me" kind of post :)