.png)
My favorite Angular Setup in 2025
Angular continues to evolve rapidly. What should we use in 2025? Especially if we start with a new project. Inspired by a Reddit discussion, this guide shares my personal take (=opinionated) on the most effective tools, libraries, and practices for Angular development in 2025. The video version of this article is available on YouTube. Reactivity: Go for Signals Signals represent one of the most significant shifts in Angular's approach to reactivity. While some pieces like Signal Forms and httpResource are still in development, and effect remains in developer preview, my recommendation is clear: go all in with Signals. Why shouldn’t you wait for Signal Forms and httpResource? The answer lies in the cost of rewrites. If you skip Signals now, you’ll likely default to RxJS for reactivity. But transitioning from RxJS to Signals later will require a much more extensive rewrite. Your have to realize that with RxJS, the paradigms are different, a lot of things are different. On the other hand, by adopting Signals, you can ensure that your application is already aligned with Angular's future. For areas not yet "signalized" (e.g., Reactive Forms or HTTP communication), you can step out of the Signal reactivity and handle them the traditional way for now. For instance, you could use an effect to set the value of a FormGroup. The key point is that starting with Signals means you only need to adjust the non-signalized parts of your code in the future. If you skip Signals now, you’ll face the daunting task of refactoring the entire application later. That said, this doesn’t mean you should completely replace RxJS with Signals. My advice: Start with Signals, and if RxJS doesn’t offer any significant benefits, stick with Signals. Otherwise, go with RxJS. For new applications, I’d also recommend adopting resource or rxResource from the start. While these APIs are currently experimental and might evolve, by the time your application goes live (which is often well beyond 2-3 months of initial development), they are likely to be stable. Go learn more about Signals, you can check out my video Angular CLI Over Nx I prefer the Angular CLI because it provides everything I need to get started without adding unnecessary layers of complexity. While Nx offers pre-configured tooling, I find that manually setting up what I need with the Angular CLI is straightforward and works seamlessly with Schematics or pre-configured setup tools from that tool. Starting with Nx introduces an additional layer of abstraction, which can feel overwhelming, especially in the early stages of a project. It also comes with its own learning curve and migration processes, which usually requires extra effort. In my experience, beginning with the Angular CLI and transitioning to Nx later, if needed, is the more practical approach. That said, Nx offers value when your application grows. Its features, like advanced build tooling and mono repository management, become indispensable for large-scale projects. And if the time comes to adopt Nx, the process is straightforward — just run nx import. For library development, however, I would choose Nx from the start. Angular CLI • Overview • Angular The web development framework for building modern apps. angular.dev Nx: Smart Monorepos · Fast CI Nx is a build system, optimized for monorepos, with plugins for popular frameworks and tools and advanced CI capabilities including caching and distribution. nx.dev Angular Material + Tailwind When it comes to UI development, I use Angular Material together with Tailwind. Angular Material provides a robust library of components that integrate seamlessly with Angular. Since it is part of the Angular project (which consists of Material, the CLI, and the framework), it’s officially maintained and always kept in sync. For me, Tailwind CSS is not a replacement for a UI library but the perfect complement to Angular Material. While Material handles most of my UI needs, Tailwind is used for fine-grained customizations, like positioning elements, tweaking margins, and adding utility classes. I rarely encounter unique UI needs or work with an existing design system. Most of the time, I develop what I like to call "UI-boring" enterprise applications, where the combination of Angular Material and Tailwind is more than sufficient. Angular Material UI component library UI component infrastructure and Material Design components for Angular web applications. material.a
Angular continues to evolve rapidly. What should we use in 2025? Especially if we start with a new project.
Inspired by a Reddit discussion, this guide shares my personal take (=opinionated) on the most effective tools, libraries, and practices for Angular development in 2025.
The video version of this article is available on YouTube.
Reactivity: Go for Signals
Signals represent one of the most significant shifts in Angular's approach to reactivity. While some pieces like Signal Forms and httpResource are still in development, and effect remains in developer preview, my recommendation is clear: go all in with Signals.
Why shouldn’t you wait for Signal Forms and httpResource? The answer lies in the cost of rewrites. If you skip Signals now, you’ll likely default to RxJS for reactivity. But transitioning from RxJS to Signals later will require a much more extensive rewrite. Your have to realize that with RxJS, the paradigms are different, a lot of things are different.
On the other hand, by adopting Signals, you can ensure that your application is already aligned with Angular's future. For areas not yet "signalized" (e.g., Reactive Forms or HTTP communication), you can step out of the Signal reactivity and handle them the traditional way for now. For instance, you could use an effect to set the value of a FormGroup.
The key point is that starting with Signals means you only need to adjust the non-signalized parts of your code in the future. If you skip Signals now, you’ll face the daunting task of refactoring the entire application later.
That said, this doesn’t mean you should completely replace RxJS with Signals. My advice: Start with Signals, and if RxJS doesn’t offer any significant benefits, stick with Signals. Otherwise, go with RxJS.
For new applications, I’d also recommend adopting resource or rxResource from the start. While these APIs are currently experimental and might evolve, by the time your application goes live (which is often well beyond 2-3 months of initial development), they are likely to be stable.
Go learn more about Signals, you can check out my video
Angular CLI Over Nx
I prefer the Angular CLI because it provides everything I need to get started without adding unnecessary layers of complexity. While Nx offers pre-configured tooling, I find that manually setting up what I need with the Angular CLI is straightforward and works seamlessly with Schematics or pre-configured setup tools from that tool.
Starting with Nx introduces an additional layer of abstraction, which can feel overwhelming, especially in the early stages of a project. It also comes with its own learning curve and migration processes, which usually requires extra effort. In my experience, beginning with the Angular CLI and transitioning to Nx later, if needed, is the more practical approach.
That said, Nx offers value when your application grows. Its features, like advanced build tooling and mono repository management, become indispensable for large-scale projects. And if the time comes to adopt Nx, the process is straightforward — just run nx import.
For library development, however, I would choose Nx from the start.
Angular CLI • Overview • Angular
The web development framework for building modern apps.
angular.dev
Nx: Smart Monorepos · Fast CI
Nx is a build system, optimized for monorepos, with plugins for popular frameworks and tools and advanced CI capabilities including caching and distribution.
nx.dev
Angular Material + Tailwind
When it comes to UI development, I use Angular Material together with Tailwind.
Angular Material provides a robust library of components that integrate seamlessly with Angular. Since it is part of the Angular project (which consists of Material, the CLI, and the framework), it’s officially maintained and always kept in sync.
For me, Tailwind CSS is not a replacement for a UI library but the perfect complement to Angular Material. While Material handles most of my UI needs, Tailwind is used for fine-grained customizations, like positioning elements, tweaking margins, and adding utility classes.
I rarely encounter unique UI needs or work with an existing design system. Most of the time, I develop what I like to call "UI-boring" enterprise applications, where the combination of Angular Material and Tailwind is more than sufficient.
Angular Material UI component library
UI component infrastructure and Material Design components for Angular web applications.
material.angular.io
Tailwind CSS - Rapidly build modern websites without ever leaving your HTML.
Tailwind CSS is a utility-first CSS framework for rapidly building modern websites without ever leaving your HTML.
tailwindcss.com
Testing: Jasmine/Karma and Playwright
To be fair, choosing the right testing tools is not easy at the moment. Since I go with the Angular CLI, I’ll stick to the only officially supported testing framework: the combination of Jasmine and Karma.
You might have heard that this pair has reached its end-of-life. That's not true. End-of-life applies only to Karma, which handles running the tests in the browser. Karma will be replaced by the Modern Web Test Runner in the future, but we don’t have to care about that. The commands we use in our tests are Jasmine, and that’s not going to be replaced. It will just stay.
What about Jest or Vitest? There are plans to support Jest officially. I hope it’s going to be Vitest, which is the modern tool, but I’m afraid the Angular team leans toward Jest.
Additionally, I use the Angular Testing Library, which runs on top of Jasmine. It enhances the testing experience by
- providing utility functions to select elements via user-facing selectors, such as roles or labels, instead of relying on implementation details like class names or
data-testid. - It simplifies the configuration of the
TestingModulevia arenderfunction. - It handles asynchronous tasks and triggers the change detection automatically
testing-library.com
Since I don't write a test per file (aka. Unit Test), but for features a as a whole, I disable the automatic generation of a test in the CLI.
There is also a video about this "don't write tests for each file"
For end-to-end (E2E) testing, it’s going to be Playwright. If I don’t have existing code, I don’t see any reason to use something else. Playwright is fast, modern, and reliable.
Unfortunately, there’s no plan to support component testing in Angular with Playwright, but I can tell you that some work is going on in the background. It might come, maybe in the form of a community-driven effort.
And guess what, there I have also a video about Playwright
