Express and React, NestJS and Angular
Express.js remains the go-to framework for Node.js development. On the client side, Angular, React, and Vue dominate the landscape. Pair these with MongoDB, the most widely adopted NoSQL database, and you arrive at the standard JavaScript tech combos: MEAN, MERN, and MEVN.
React and Express share a lot of DNA. Both are minimalist, JavaScript-centric, and ship with only the essentials in their core packages. They give developers considerable freedom when it comes to tooling and application architecture.
On the server side, the direct counterpart to Angular is NestJS. Its author drew heavy inspiration from the patterns Google’s team introduced in Angular while building it.
Angular and NestJS share several traits that set them apart from the Express/React pairing:
- TypeScript as the primary language
- Heavy reliance on decorators
- A modular dependency injection system with providers, imports, and exports
- A curated collection of officially supported libraries
- A feature-rich core package out of the box
- A dedicated CLI
Both approaches have their strengths and trade-offs. The real pitfall is mixing incompatible philosophies within a single stack — MERN’s pieces fit together neatly, but the same cannot be said for MEAN.
That is why I would like to put forward a stronger alternative: the NAN stack.
Introducing NAN
NAN brings together three technologies: NestJS, Angular, and Nx. The synergy between NestJS and Angular was explained earlier. Nx is a toolkit designed for monorepo workflows, but it proves equally valuable when building large, single applications. For full-stack developers, sharing code, tooling, and a single repository between the backend and frontend is a huge win — and Nx delivers that and more.
Interestingly, the team at nrwl also picked up on this pairing. They added support for generating projects in either the Angular-Nest or React-Express combination.
Relational databases are still relevant
The most significant departure from MEAN is the absence of a database from the NAN stack. Locking in a database would impose an unnecessary constraint. A competent backend or full-stack developer should be comfortable with both NoSQL and classic relational databases. More importantly, they should be able to evaluate which database suits a project’s needs and let that decision guide the technology — not the other way around.
The point I am making is that any Node.js developer should recognize that NoSQL is not the right fit for every application type. If that is the case, they should advise the client that a different technology may serve the project better. Even if NoSQL is the only database you are comfortable with, choosing it should be a justified decision rather than a default.
Wrapping up
MEAN achieved remarkable popularity, spawned several variations, and set the direction many companies and developers followed when picking their specialization. Today, though, there is a strong successor worth considering for those who favor the Angular and NestJS approach. I am confident that NAN will rise to the same level of adoption, refine the formula, and earn its place in the JavaScript ecosystem.