DEV Community

Cover image for React or Angular for enterprise?
Martin Beierling-Mutz
Martin Beierling-Mutz

Posted on

React or Angular for enterprise?

I recently had a discussion with colleagues about React vs. Angular for enterprise applications. I'd like to bring this discussion to the dev.to community as well.

The core arguments were:

  1. React comes with less built-in tools than Angular. Therefore, React setups need to complement vanilla React by installing open-source dependencies. This makes the on-boarding of new developers to a project built with React more difficult, as any unknown dependencies need to be learned first. Whereas Angular has necessary concepts and tools built-in, which Angular developers already know and therefore have a quicker on-boarding to a new project.

  2. Angular uses Typescript by default and is built with Typescript in mind. React isn't. Certain patterns in React are hard or cumbersome to type correctly. As Typescript is generally preferred over JS in enterprise projects, Angular is the better choice.

🤔💭 What are your thoughts on this? 🤔💭

Top comments (25)

Collapse
 
thespiciestdev profile image
James Allen • Edited

When you have full-stack responsibilities and your front-end is Angular and your back-end is NestJS, you can have a wonderful experience.

On top of this, I also see bonus points when you have a monorepo setup and shared resources between both ends (while my builds are so-so, I am waiting patiently for out-of-the-box Bazel support!)

Collapse
 
embiem profile image
Martin Beierling-Mutz • Edited

Interesting. So NestJS borrows concepts from Angular, as it says it's "heavily inspired by Angular"?

I see how this could be very efficient.

In the React community, GraphQL is becoming really popular. It's basically pushing more work to the frontend and using the concepts of components for data fetching. But I'm not aware of any full-stack combo like Angular & NestJS.

Collapse
 
rhymes profile image
rhymes

Programmers have serious issues with naming things: next.js, nuxt.js, nest.js

🤣🤣🤣🤣

Collapse
 
shafqatevo profile image
shafqatevo

NestJS does have GraphQL server by way of wrapping Apollo GraphQL server.

Collapse
 
jmdembe profile image
Jessica Dembe

My team has an Angular application with nest and I agree with this 100%.

Collapse
 
rhymes profile image
rhymes

Why nobody ever mentions Vue? 🤣

Just kidding, I assume you've considered that as well and for some reason you've moved on.

What do you mean by "enterprise application"? It's quite a generic (and in my opinion a little bit overused) term. Do you mean that it must adhere to some pre-existing standard? Are there constraints or requirements involved? Does the fact that you seem to know React better helps? Is the team already knowledgeable on either of them?

I read your post and thought "well, he's leaning towards Angular", but then I read your comment and I thought "well, he's leaning towards React now" :D

In a sense I don't think there's a wrong choice to make here because all the major libraries have either a big company backing them or a big community with companies using them. You can build great apps with either.

What if you build a proof of concept with each technology and then decide? Can you afford that?

If onboarding new devs is a big factor probably Vue needs to be considered as well, it's the easiest to grasp and omakase (which also means most devs use Vue in the same way with the same libraries):

React has the advantage over Vue to be everywhere right now so it might be easier to find devs (but I live in my bubble where Angular doesn't really appear so I'm definitely biased on this)

Collapse
 
denisinvader profile image
Mikhail Panichev

+1 to Vue: it has a "standard" libraries for common issues so you can create a "framework" based on it with optional features and well-known packages. And you can also write your code in style you like more: HTML centric like Angular or functional style with JSX like React (without so much boilerplate) and even combine them in different modules.

At my job, recently we started to create the biggest project (it definitely an enterprise level project) since we started Vue and with my experience from projects, I don't see any troubles with well designed Vue code base.

I also don't like that fact that companies follow trends. For example, the Russian company Yandex, which created the BEM concept, a few years ago had its own js library to handle stuff in BEM style. Now they use React almost everywhere. I don't like it, because they had some solution and just threw it out instead of improving it. It's like a monopoly or globalization in web development, the lack of competitiveness

Collapse
 
embiem profile image
Martin Beierling-Mutz

I love Vue! It's just not there yet to propose in a big company IMO, where sometimes even React is cool an new. It's also about change. Angular was pretty common, now React starts to become pretty common. And that is basically what I mean by "enterprise": Slow change, long chains of approval and lots of people working on one project. In environments like this, changing frameworks is a huuuge deal.

Collapse
 
dinsmoredesign profile image
Derek D • Edited

I work for the largest credit union in the state and our projects certainly classify as "enterprise." We have no problem using Vue in our applications and we've implemented it in 20+ apps so far.

I evaluated all three of the big front end frameworks and, even though I had the most experience with Vue personally, it, by far, made the most sense to our team.

Angular is complex, there's a lot of boilerplate and, while TypeScript was initially interesting to our C# devs, along with the similar structing to .NET, learning it well required more time than we were willing to put aside for it. Not only that, but we felt like it would have slowed down our development time because, while it was robust, we were writing a lot more code and code reviews themselves became more difficult.

React is awesome. Personally, I love most of its concepts and the more functional approach, but its lack of structure became difficult because there are barely any rules enforced. Sure, your organization can adopt certain patterns, but on projects where you're up against short deadlines, these are the first things to go out the window. You can always go back and refactor, but that time rarely happens for us and I hate that mindset. A lot of the code on unstructured React applications starts to look like spaghetti code from the jQuery days, which is exactly what we were trying to avoid.The functional style is also pretty foreign to our .NET guys who would have to work on the front end occasionally. Moreover, I also feel like React is, by far, the least stable of the big three. Not necessarily in up time or codebase, but more that the React team doesn't really seem to know what they want and rather than making core concepts better in new releases, choose to just release more and more new features, which is a time sink to learn.

Also - I'm not a fan of Redux and ReactRouter being community controlled projects (Yes, I realize some of the React Core Team contributes to them, but they are not Facebook projects), they're both fantastic libraries, but these are key features that are a necessity in most large applications; for the React team to not have their own implementation is strange. While React has added some features lately to remedy the reliance on Redux, that's just another thing our team would've had to learn. Moreover, the way routing is done within ReactRouter is just totally backwards to me; defining routes inside your view as components makes no sense.

Vue strikes a happy medium between structure and freedom for us. Vue, VueRouter and Vuex are all part of the core Vue ecosystem and the Single File Component structure means you can pick up working on an application anywhere and fairly easily understand what's happening. The only thing I feel needs more work in Vue is their validation packages - I'm a huge fan of the concepts of Vuelidate but they keep changing their API to the point where if I were to update older apps, they'd break. VeeValidate is a very robust package but it can add a lot of unnecessary weight if you don't need a whole lot from it. I'm also not huge on the DOM-based validation vs model-based. I like the data-driven concepts of Vue and feel like VeeValidate doesn't really adhere to those same notions. I'd also love to see immutability built into Vuex, as that's bitten me a few times in the past, where it wouldn't have been an issue in Redux, but you learn to counteract it after you make the mistake the first couple of times :D

Thread Thread
 
rhymes profile image
rhymes

Great overview, thanks!

Collapse
 
rhymes profile image
rhymes

Got it! It makes sense, it's the youngest of the three and the one with likely the smallest community.

I hope you find a way to discern between the other two. See if you can build a couple MVPs with the devs and judge on those.

Collapse
 
airblader profile image
Ingo Bürk

Disclaimer: I can't speak for Vue, I only have experience with React and Angular.

I agree with both core arguments; however, I wouldn't say that makes Angular the better choice. The clear benefit of React is a smaller learning curve for new team members, as even with external dependencies like redux (and it's variants) there's still much fewer additional and often hard to understand topics you're forced to face right away (change detection, rxjs,...) That said, things like Typescript and rxjs out of the box are things I love about Angular.

At the end of the day I think you can write solid enterprise applications with either framework, and I tend to avoid trying to find an answer to the "but who is better" question. I'd rather be happy we get to choose from more than one framework. :-)

Collapse
 
tomdavidson profile image
Tom Davidson • Edited

I don't think enterprise matters. Does the org want everything, including the kitchen sink, built-in? An highly opinionated way of doing, so they don't need to create their own? Does the org need to pick the same framework a different "enterprise" uses because someone in management golfs together? If yes, then Angular it is, and if your real lucky your brand new parent company uses AngularJS... so now you do to.

Angular emphasizes a declarative, HTML, perspective whereas React places emphasis on a JavaScript perspective, but I think in most projects you end up doing a lot of both. In all seriousness I think current NG comparison can boil down to all-in-one vs smaller individual pieces that are closer to web components.

Collapse
 
itsasine profile image
ItsASine (Kayla)

Since this thread is a week old, I'll just add a little tidbit:

In my large company, they're 100% Angular. Mainly because a central body has to approve all tech stacks and it's easier to start a project if you use the blessed one (Springboot, Angular, MySQL).

However, I'm thinking the central unit is going to change their stance on Angular soon. We have many projects on 1.5 still, and projects last year that were allowed to start on 4 aren't particularly allowed to update every year. I don't see ulta huge company continuing to buy into a stack that has frequent major version updates. They hem and haw at projects jumping from 6 to 7 even though the breaking changes were minimal. In the move fast and break things world of JS frameworks, I could totally see my place bailing and going to Tymeleaf or .NET again.

Collapse
 
ausmurp profile image
Austin Murphy

In my experience with both Angular and React, you end up writing the same amount of boilerplate when you have the projects fully working the way you need with all needed packages included. Once you use them both enough you realize, they're actually very similar. Biggest difference is JSX (React) vs html template w directives (Angular). The rest is about the same honestly. In Angular you can release your project as a web component library and then use those components you built in Angular, inside of React. Lol. I mean it's all coming to a similar end game, they're just getting there in slightly different ways. I think eventually they'll all adopt web components and be interchangeable.

Now the recent negative Outlook toward TypeScript I don't get. TS is so awesome. I do all of my front end development to with TS. I've done plenty of pure JS and have found TS just matches the way I personally think about software. I'm a more visual front end developer though so perhaps that plays a part.

Collapse
 
embiem profile image
Martin Beierling-Mutz

My personal opinion is very much in favor of React. This may very well be because I didn't use Angular too much.

In general I think it really depends a lot on the resources you have available and where their strengths are.

You can create great products with both, but only if you have the enough developers.

Regarding the on-boarding time, my opinion is that React developers actually know a lot of the popular dependencies like Redux or React-Router. But I have to agree that some setups, especially with older dependencies might take some time to on board new devs. I don't know Angular enough to compare the two, though. Would love to hear about your experiences.

Collapse
 
snesi profile image
David Domingo

I've worked with both, but preferred angular over react. Specially for Enterprise stuff. I feel like with angular you have less stuff to think about or worry about.

Collapse
 
chiangs profile image
Stephen Chiang

Personally I'd always recommend angular 2+ for enterprise level apps, but a big factor I always mention to a customer when consulting is to have a look at the market of developers. You don't want to pick a technology or framework that isn't as common or popular amongst the pool of developers you have in the area; then the onboarding time could be drastically different than the initial argument for angular.

In my area the 'biggest fish' has decided that react would be the common framework for all new projects, so service providers are scrambling for react talent. I would love to be a fly on the wall to hear how that decision was made... It's like the chicken or the egg... Did they choose it because it was popular or of out popular because they chose it?

I am not so sure it was the right choice but that the outside looking in. Time may tell.

Collapse
 
fnh profile image
Fabian Holzer

The company I work for is rather strongly invested in Angular. In the last three years, quite a lot of work has been spent building new modules of our system with Angular as technological basis for the UI part. One rather important point back in 2016 was the consequent usage of TypeScript. For the most part the system is, and the backend part for the foreseeable future will continue to be based on Java. Therefore, the cultural gap, if you will, is somewhat easier to bridge than to pure JS options.

Collapse
 
mehmoodahmed profile image
mehmoodahmed • Edited

Martin have you developed any enterprise application in angular latest versions? Can you share some enterprise applications developed in angular? Can you share some global big companies which are using it? I think react have all this. And what about dependencies Issues and too frequent releases? Why?

Collapse
 
revskill10 profile image
Truong Hoang Dung

React is just javascript, it'll give you highest flexibility in your hand.
So i prefer React now.
Not sure about next years though.

Collapse
 
mehmoodahmed profile image
mehmoodahmed

But angular is still not reliable. Angular Have good features and built on Microsoft typescript which is a future but yet I didn't see any enterprise application and big clients of it. The biggest issue is the rapid development that's why dependency packages doesn't support it .

Collapse
 
flamesoff profile image
Artem • Edited

Absolutely agree :) React is great, but for enterprise-sized applications Angular is the best structured and fail-safe tool.

Collapse
 
josemunoz profile image
José Muñoz

React also supports Typescript, and I think the learning curve in Angular is steep compared to React, Vue is increasingly popular as well and it should also be in the conversation IMO

Collapse
 
tonywr71 profile image
tonywr71

I wrote a pretty detailed article on this, which I posted on Linked In. It's still largely valid.

linkedin.com/pulse/which-javascrip...