This article is pretty much an exact summary of why I chose angular as the platform of choice for the company I work for. People always bring up the fact that other platforms provide better performance than angular. In many cases this is true. But companies that use software in support of their main business, don't always need the increased performance. Human resources are usually more expensive than losing out on other performance increases.
The question that is nagging away at me is are you measuring the right human resources? In internal applications, the cost of the human resources of the developers is (hopefully) dwarfed by the cost of the human resources of the users. So if the application is markedly slower in use, or clunkier because a component had to be written in house, rather than taken from a pre-written library, in a way that absorbs more of the users time, that could work out far more important.
I've never coded in either React or Angular, so have no horse in the race, and don't know whether there is significant difference in the proportion of the application that would typically have to be written in house.
In internal applications, the cost of the human resources of the developers is (hopefully) dwarfed by the cost of the human resources of the users
Actually, many of these enterprise in-house applications are typically used by a handful of people, so the word "dwarfed" is probably slightly exaggerating, but obviously yes, that's a valid point, and I touch upon that in other comments here, where I say that "the fact that all Angular apps typically ends up similarly in UI and UX is an advantage since once the user has learned one app, the user has effectively learned all apps, and the context switch requirements between different apps created in Angular is hence smaller than the context switch requirements if these apps were created in React" (roughly ...)
because a component had to be written in house
I suspect this is a problem that's not more frequently happening in Angular than React.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This article is pretty much an exact summary of why I chose angular as the platform of choice for the company I work for. People always bring up the fact that other platforms provide better performance than angular. In many cases this is true. But companies that use software in support of their main business, don't always need the increased performance. Human resources are usually more expensive than losing out on other performance increases.
Thank you Shmuly :)
This is the exact reason why we choose Angular as our primary goto tool ourselves, and also produces Angular code in our data grid generator ...
The question that is nagging away at me is are you measuring the right human resources? In internal applications, the cost of the human resources of the developers is (hopefully) dwarfed by the cost of the human resources of the users. So if the application is markedly slower in use, or clunkier because a component had to be written in house, rather than taken from a pre-written library, in a way that absorbs more of the users time, that could work out far more important.
I've never coded in either React or Angular, so have no horse in the race, and don't know whether there is significant difference in the proportion of the application that would typically have to be written in house.
Actually, many of these enterprise in-house applications are typically used by a handful of people, so the word "dwarfed" is probably slightly exaggerating, but obviously yes, that's a valid point, and I touch upon that in other comments here, where I say that "the fact that all Angular apps typically ends up similarly in UI and UX is an advantage since once the user has learned one app, the user has effectively learned all apps, and the context switch requirements between different apps created in Angular is hence smaller than the context switch requirements if these apps were created in React" (roughly ...)
I suspect this is a problem that's not more frequently happening in Angular than React.