Angular expert learns React 2023: server-side rendering by default!

I have been using Angular 2.x since it was released in 2016. In the past seven years, I have seen the rise of React and Vue, the releases of interesting projects like Svelte and Remix, and offsprings like React Native go to the moon both in terms of popularity and maturity. I have always kept up with React even though my day-to-day was with Angular, and I thought it would be interesting to see the differences and similarities between the two as we start off 2023. As it turned out, some things haven’t changed at all in the last years, but there were some developments that make the two more different than ever. Here are my experiences as an Angular expert about React in 2023.

1. create-react-app is your friend*

Angular CLI was released together with Angular 2, and it has been proven super useful ever since. It’s capable of setting up projects from nothing, and most of the time it proves to be useful during the full lifecycle of the project. create-react-app fills a similar role, and it will probably be the first tool you come across when learning the basics of React. Although it’s basically only an ng init as a separate npm package, it’s still a nice start for a simple single page application that will provide an Angular-like developer experience.

*: see 5. ; )

2. React is just the view; everything else is up to you*

If you have been working with Angular, you might be used to the fact that most of the things you might need comes right out of the box. Router is packaged with Angular, HttpClient takes care of the API calls, the CDK has most of the low-level building blocks you might need, etc.

With React, it’s completely different. All of these functionalities are in separate packages, and most of the time you’re free to choose your own favourite. Take HTTP Calls for instance: you could use axios (if you like async / await), jQuery AJAX (maybe you are already familiar with it) or simply go the NativeJS way with window.fetch. In some areas, a clear best solution is starting to arise: react-router-dom is the best router to use since they merged with the second-largest react router package, and usually frameworks based on React also come with a given set of tools.

Should you have any questions about framework and package selection, react.dev usually has good support, and examining the packages’ github pages and npm stats provides a good overview for the given package’s health and support.

When checking the github repos for candidate packages, remember to not fall into the star-based development pitfall: don’t assume that a repo with a lot of stars is automatically a good choice. Instead look for open issues, release frequency and daily downloads from npm as a guidance.

*: see 5. ; )

3. There are only components!

Directives? Services? Pipes? I don’t think so. In React it’s components only, everything else is plain JavaScript / TypeScript. (Luckily this also means no modules either.)

Even components should be functions instead of classes.

There was a syntax that allowed component classes to be used in React, but now it’s not recommended. When React components are rendered, either the component function is called, or the class’ render() method is called. Class-based components provided an intuitive way of storing state between render() calls, while functional components were mostly stateless and presentational only.

Since the introduction of Hooks, this has changed, and now the functional components should be used everywhere. Hooks allow the developer to store state between the component function calls, solving two problems at once: the state is now stored in it’s separate place — away from the component and available for whatever needs it — and the confusion about different component declarations is gone.

However, it’s still a good pattern to separate the components between stateful and stateless components. Stateful components should deal with hooks and otherwise manipulate state, while stateless components (also called presentational components) should only be concerned about taking care of the UI elements.

4. JSX is not HTML (although it’s close)

JSX is the syntax of choice to write markup in React, and at a first glance it looks like regular HTML. However if you have been writing HTML templates for a long time, there are some minor but important differences between the two.

The gist of the difference is that when working with JSX, you are basically writing JavaScript disguised as HTML. This means that none of the reserved keywords in JavaScript can be used in these templates. This includes two super common attributes: class and for, so instead of those you'll have to use className HTMLFor which are unique for JSX.

Also, JSX templates must have exactly one root element, so the empty tag (<> </>) is often used to contain a full JSX template. The empty tag will not be rendered in the DOM, so it’s the safe choice to use for this case.

As JSX is JavaScript in its core, it’s contained completely in the component. This means that fragments of JSX can be combined like strings to create a template: instead of *ngFor and *ngIf the NativeJS for and if should be used to compose complicated UI. Just treat JSX fragments like strings, and you’ll be fine most of the time.

5. React is meant to be rendered server-side!

OK, so this is super new and I was really surprised by it:

react.dev now suggests to only use React as part of a framework, and all the recommended production-grade frameworks are full-stack!

Next.js and Remix are the highlighted frameworks for general-use webapps, and both render React components on the server side instead of using a traditional single page application — like the one which offered by the Angular CLI and create-react-app out of the box. These suggested frameworks are similar to Angular in a way that they provide all the tools you might need, and being server-side means they could be compared to Angular Universal in a lot of ways.

I have talked about how React is just a library for the view, and every other library is freely chosen by the developer. The fact that the React team now suggests going against this method shows how problematic this approach can be: not having a constant set of tools to work together just makes the number of weird interactions and time-consuming bugs grow exponentially. Frameworks solve this issue, because when all the functionality is provided out-of-the-box and owned by one team, it’s much easier to make the tools play well with each other, and the developer experience is also bound to be much better.

These frameworks are all treating server-side rendering (SSR) as a first-class feature, and that is a big step forwards. (Or backwards, depending on your relationship with PHP.)

SSR is a must-have for commercial webapps, especially where SEO and Google rankings are a critical necessity. Making sure that new React projects all follow this mentality ultimately makes for better products, and having SSR since day 1 will shape the app’s structure so interactions between SSR and the SPA are always on the developer’s mind.

+1 Bid farewell to RxJS

RxJS is a mandatory tool in Angular that makes the learning curve that much steeper at the beginning. Reactive programming is super useful to understand and when done well, it makes data in your app flow beautifully — however if someone is still learning the basics of web development it’ll likely be a pain in the neck to deal with RxJS too. This makes it a double-edged sword, because not understanding it well will lead to a lot of frustration and bugs when multiple observables in multiple components needs to be orchestrated properly. On the other hand, beautifully written RxJS declarations make for a highly satisfying developer experience.

But hey, if you really liked RxJS, and you’d still use it, you can! Feel free to gather any necessary libraries you’d like to use in addition to React, but be prepared that you just might find that there are better alternatives for data orchestration than RxJS.

+1.5 Redux is super easy if you know ngRx

The names differ a bit, but the functionality is basically the same : )

There is so much that we haven’t mentioned here. The virtual DOM in React is a huge performance boost that is great. Reconciliation vs. Change Detection vs. Signals is a topic that could be it’s own article. So is state management, as both of these frameworks offer a number of different ways to structure data in your app.

Clap for this article if you’d like a part 2 explaining these and more, or feel free to add a comment with your suggestions!

Thanks for reading. Have a great one!