React to Angular — a beginner’s perspective
I am now a Developer. In many ways, I always was. But now it’s my job title, and someone is even paying me to do it. I am living the dream, people. As those who have followed my blog will know, I have dabbled with React, and I liked it. I liked it a lot. However, my new place of employment is an Angular house. Which is a bit like realising that after a dalliance with a Montague, you’re actually a Capulet.
It would seem the geek universe is very passionate about the whole React vs Angular thing. As a coding beginner, stumbling like a newborn foal into my first dev role, I am not going to claim any authoritative view as to which is “better”. But what I can do is share my first impressions of Angular, and the key differences between Angular and React that are worth wrapping your head around as a beginner to both.
A rose by any other name..
Firstly, it’s worth noting that React and Angular have a lot in common. Both are designed as performant solutions to creating complex yet responsive web apps. Both sit firmly in the front-end (ie. the code is designed to be executed in the browser). Both attempt to make the interplay between Javascript and HTML more flexible and intuitive, and both require you to break down your codebase into lovely re-usable components.
So what are the differences?
Angular is often referred to as a framework, whereas React is a library. Which basically means that Angular is a lot more opinionated about how you should structure your codebase, and will manage your whole front-end for you, including the flow of data going in, out and around it.
In fact, with Angular 2+ it even goes slightly beyond the front-end with the options of AOT and pre-rendering. AOT (Ahead Of Time) is where you can pre-compile your app on the server — ie. translate the typescript into browser-ready Javascript. Pre-rendering is where you deliver a ready made starter view straight to the browser, while the app catches up with loading in the background, creating a super slick browsing experience. This can currently be done with Angular Universal, which will be bundled in as part of Angular 4.
React is focussed on serving up views, and the logic needed to serve up those views. Unless your website is very simple, you will probably want to add on extras such as Redux to manage the data flowing around your app. Or you could choose from all sorts of other add-ons; React is a piece of the jigsaw that does it’s own thing without caring about the rest of the picture. This allows you to experiment with different options to try and acheive the perfect tech stack for your needs.
Another key difference is how the unholy matrimony of Javascript and HTML is managed. I have to say React is a lot more intuitive in this respect. That’s because in React, the magic of JSX allows you to just throw HTML right into your Javascript. Barring some minor tweaks, it really is just plain old HTML, so the learning curve is minimal.
With Angular however, you are funnelling JS into your HTML. As HTML cannot be easily made to cope with executing Javascript, Angular has to play an active role in managing the situation. This happens in the form of it’s many Angularisms (mainly called ngSomething), which means learning Angular is almost like learning a whole new programming language. They are also known more formally as Structural Directives. Examples such as ngIf and ngFor allow you to change which elements are displayed in the DOM based on logic that links to your component variables — right in your HTML.
An Angular state of mind
As mentioned earlier, Angular is quite opinionated about how you should structure your app. The diagram below is taken from their website..
The traditional React approach to file structure is to combine display data and logic into one file for any given component, but break components down into their smallest possible sub-components to keep this clean and tidy. However, this will lead to an unwieldy number of components for a complex web app, which could be tricky to manage and maintain.
The Angular way requires you to separate your HTML from your component logic, with a hearty dose of dependancy injection coming from services and modules. While this separation of concerns will bring joy to fans of the Single Responsibility Principle, this does mean that a bit more boilerplate is required to link all the separate elements of a component together.
Modules and Services
Module files are there to tell Angular how your app or component fits together. This is where you can specify the other modules that your component requires (imports), the components that you want to make available for re-use elsewhere in your app (exports), the components it needs to display (declarations), the services it makes use of (providers) and the root component that needs to be inserted into the host web page (bootstrap).
Services are there to manage the flow of data, either providing a structure for your app to interact with a database or API, or abstracting any static or mock data from the rest of your logic. This is also where you can rope RxJS into the mix to make a lovely reactive data flow using the Observer pattern. You can read more about this here and here.
Typescript
Angular is written in Typescript, and they expect you to use Typescript with it. Typescript is a superset of ES5 that will compile to straight-up Javascript. Although it is not strictly speaking a statically typed language (read more in this great blog post), it brings many of the benefits of one — the ability to define variable types and interfaces and check your code against these definitions at compile time, as well as nifty features such as auto-completion. Being able to define interfaces (ie. state explicitly what you expect the structure of a given object to be) not only adds rigour to your codebase, but also acts as clear and reliable documentation for your code.
Wisely and slow; they stumble that run fast
A final tenuous link to a Romeo and Juliet quote. Although I am still a fan of React, I am also so excited to be using Angular every day, and can see the benefits of both. Now is truly an exciting time to be a Javascript developer, but let’s not forget — it’s not what you use, it’s how you use it.
