Do you use Angular or React for your software development projects? Is it always an easy decision? Full Stack Developers Greg West and Andy Weir debated the pros and cons of both. Here’s what they think.
An experienced Frontend Software Developer will have likely used both Angular and React for different projects throughout their career; if they have, they probably have a preference on which they’d prefer to use moving forward.
Current version of Angular (Angular v2+) is a complete rewrite of Angular v1 (2010 version), which was launched in 2016. It’s a Typescript framework backed by Google. React was launched in 2013, can be written in Javascript or Typescript and is backed by Facebook. It could be argued that React has a better reputation overall, possibly because it’s been around longer than the current version of Angular. It’s used on more websites than Angular, has very good community support, and is higher starred on Github. But does that mean it’s better?
When does freedom become too much freedom?
The main difference between Angular and React is the extent to which the user can make their own decisions. Angular restricts the developer far more than React – but that can be seen as both a good thing and a bad thing.
React is a UI framework – it does what it does well, and whilst it’s got plenty of opportunity to plug in other bits and pieces: things like state management, networking access, and test frameworks, the developer is largely on their own. Having said that, fans of React would argue that a developer using React is never on their own because of the vast community associated with it.
React gives the user options at every turn, for example, there might be eight different ways to do styling and nine different ways to do forms in React, amounting to well over 50 ways to do just those two different things. Some developers love the flexibility this offers, whilst others prefer to have more rigid parameters.
Angular is much more opinionated and keeps the user on the straight and narrow. It could be argued there’s a steeper learning curve using this framework – you need to know a lot more. Having said that, the fluidity of React means even if you move from one project to another, it can sometimes feel as if you have gone to a totally different React, so there’s often an immediate learning curve here too.
If you like the freedom to decide everything down to the finest detail, you probably won’t like Angular. But if you want to get on and develop at a fast pace without being forced to exercise your creativity building bespoke framework, you probably won’t like React.
Typescript
If you don’t get on with Typescript, it’s likely Angular’s not for you; there’s no other option, you have to use it. React allows you to choose between Javascript or Typescript. If you do want to use Typescript in React, you might find the types quite clumsy to use.
Using Typescript can often prevent errors that would otherwise be missed, but for those that are used to Javascript, it can feel quite alien.
Dependency Injection
Angular has IOC infrastructure that makes you register everything inside modules, and then injects them into constructors, which some people find overly complicated. However, this seemingly laborious process can lead to more loosely coupled code.
One of Angular’s best features is the ability to be able to change things without causing a ripple effect. The combination of Typescript, plus Dependency Injection, plus services means the developer ends up with the same kind of loosely coupled architecture on offer with back-end code languages (C#, C++, Javas), in the frontend.
This is great if you’re building something sizeable and don’t want sprawling code that makes it difficult to keep control of where the dependencies are and how everything links together.
React fans tend to consider that ES6 modules are much better than Angular’s offering when it comes to Dependency Injection. Angular uses ES6 as well, which pro-React developers consider to be bizarre.
JSX
Advocates of React tend to praise JSX. If you’ve used JSX syntax you’ll know it’s React’s own sub language that lets you write what looks like HTML syntax inside your JavaScript; that means you can have your logic, styles, and presentation in the same file, and it allows you to make all changes in one place.
Angular doesn’t let you do this it forces you to separate HTML, CSS and logic, and encourages you to put them into separate files. Some developers consider this to be ok because they should be split up anyway, but the question is whether or not it should be imposed on the developer by the architecture or the language they’re using.
One downside of JSX is that everything is an HTML tag (or looks a bit like an HTML tag), and it’s easy to go down a very procedural route in the way you write code. Things you normally wouldn’t think of using an HTML tag to express, you’ve expressed in React; it’s a Javascript function but you’re using a HTML tag, and that means you can’t separate things out.
Backwards Compatibility
If you Google ‘Angular’, it’s possible you’ll spend time looking at Angular JS for a time before realising. Angular has opted to move things forward in a different way to React, choosing to keep evolving with versions and manoeuvring the framework forwards, rather than maintaining backwards compatibility.
React’s is well known for its excellent backwards compatibility, but it could be a double-edged sword. Having something that’s backwards compatible for a long period of time is great if you have something old, but it can lead one into a false sense of security where the owner doesn’t feel it necessary to update or change anything, because it will always be up-to-date. An example of this is WordPress – it’s very popular, and it’s also very backwards compatible, but it has a high number of security holes.
Routing
In Angular, a developer uses Typescript to define routes, rather than with HTML tags. This means you see your routes as routes, not routes as HTML tags with properties that define your routes.
Therefore, if you deal with payments, users, bookings etc, you can guard against only allowing payment admin to access the payment side, user admin to access the user paths, and booking admin to access the booking paths – you can make sure it all has to pass the logged in guard.
React is well known for being scalable, and within the context of building UI, it is – you can build components, you can nest those components, you can compose and combine those components. However, there’s no way to deal with the logic, like communicating with backend servers. How do you break apart by business domain, or business model?
Angular comes with a mechanism set up to do it for you; you can bundle together routes, components and services into a module. Therefore, you could have a payments module that deals with all your payments related content, and a bookings module that deals with all your bookings related content.
Once you’ve done that, rather than having individual components attached to your routes, you can have a whole module attached to your routes, allowing /payments that fires up the payments module. The payment route is assigned to the payments module – the module takes over and you’re left with nicely decoupled architecture. Payments just do payments – there’s no danger of it leaking out into other places.
The pro-React team would argue that there are React plugins that do the same and make everything much simpler.
Lazy loading
Angular gives the developer the powerful ability to scale their code when they’re dealing with lots of different business domains, or different domain models.
The combination of the routing and modules makes it easy to lazy load module – it won’t load into the browser until you need it, so if you never touch payments you never load in the payments module.
Angular is market fitted scale – when there’s lots of admin with multiple pages and dashboards, many would consider this to be the framework to go with.
Conclusion
React can do very simple things, and very complex things. It’s easier to learn and does what it does well, but it can’t do everything.
React fans tend to be the developers who enjoy writing code and freedom to make design choices, and have the patience to stay the course.
I enjoy writing React – I don’t get that from Angular; it’s old and it’s creeking, and it shows. React sparks joy, Angular does not spark joy.
Greg West
Full Stack Developer
In Angular, there’s only one solution and you have to learn it, but once you do, it’s all there for you and there’s little room for error – but also little opportunity to change it.
If you want to carve your own path through the world, Angular could be frustrating, but if you just want to get on and do some work without having to choose one of the many ways to do one thing, then it’s great.
Andy Weir
Full Stack Developer
Both, React and Angular, address Agile in different ways. React empowers the developer and favours motivation, simplicity, emergent design. Angular lets the developer get on with the job in hand and favours technical excellence, delivering value early and frequently.
