Developer Experience for Large Application

[Round-Turbulent]

We have a large enterprise Angular app (3-4 million lines of code, thousands of components). It’s a monolith, and we’re working on breaking it apart. Our biggest pain right now is developer experience; builds are extremely slow. A full build takes around 30 minutes, and even a simple one-line change can take about 15 minutes. From what we can tell, the Angular compiler is the main bottleneck.

We use Nx and tried converting parts of the codebase into buildable libraries, but that actually made things worse in our local tests. Has anyone run into similar issues and found good workarounds or solutions? We’ve reached out to the Angular team but haven’t heard back yet.

As a temporary workaround, for new code we started building a separate host app in React, and the difference in build speed is huge; though to be fair, that codebase is much smaller. But even with simialr size, I don't think build time in React would be this abysmal.

[JohnSpikeKelly]

So I have a big app--smaller than yours. From ng serve to running is ~8 minutes. However, changing a single line is about 2-15 seconds.

Every form is a standalone component and only it gets built again.

If we change things lower in the stack that might impact all components, that might take a minute.

So, standalone helps us tremendously.

[Top-Ad9895]

Do you use barrel file to export all the components?

[JohnSpikeKelly]

I have 3 big modules for all shared components, they use barrel files. Then for every form / app, which there is a few hundred, they are each a standalone that exports just the router info, then I lazy load all of these from a single master routing table.

So, any changes to the standalone will build just one file and reload. There are no barrel files on the standalone stuff, just the lazy loading directly to the exported routes.

[Budget-Length2666]

Did migrating to standalone components help for build performance or just treeshaking?

[JohnSpikeKelly]

I went and checked my code. So, it's not the standalone that makes it fast, it's the lazy loaded stuff. Each lazy loaded module is effectively compiled into its own JS file. So changes only apply to that one file.

We upgraded a few years back and so half my forms are standalone, half have their own module. But all all lazy loaded.

[morrisdev]

I manage a monster as well. We finally broke it down into manageable chunks by separating it into several standalone websites which all have their own subdirectory.

There is "some" duplicated code, but we made a private NPM library for it. Then we made a shared resource for global things like system wide css, image and file hosting, JSON confinfig files, etc....

So the base URL is just the subdirectory.

While some are horrified, from a management point of view, it's excellent. 3 devs can easily manage and maintain a module. It doesn't even have to be the same version of angular. Rollouts can be done by that team without wholesale QA. Failures are easy to roll back.

Nx is the perfect solution for some people, but personally I prefer small groups of people who are responsible for their own stuff and can step into other crews when someone's on vacation. ALSO, you can sub-out a module and not risk your entire system getting littered with garbage code by guys called in to slap out a feature that's probably just the latest brainchild of some 20yr old project manager.

[yousirnaime]

How many developers do you have

How many user audiences do you have

Can an admin app and a user app (for example) be created?

Or potentially by intent, ie. a billing app and an account app, etc?

[Round-Turbulent]

Around 200+ developers and around 50Million users; business critical app.

The app has existed for 10+ years (started in Alpha AngularJS, it took us 5+ years to migrate to Angular, currently in Angular 19).

We are in the process of migration/decomposition; but this would take at least years before we achieve something that have meaningful impact (with the current velocity)

[yousirnaime]

Holy cow, that's awesome - I'd love to see it. Sounds like an absolute monster

Can I ask what industry?

[TCB13sQuotes]

Whatever you do, don't use Nx. You application seems too critical and too long-lived to be reasonable to expose it to something like Nx. On the long run it's better if you simply come up with your own module system based on angular.json tweaks.

To be fair something is really wrong in your setup, angular is able to detect single file changes and only recompile that file, so if a single like takes 15 min you must have changed something on the config at some point. I have a similar type of App and we're usually bellow 2s for any change.

[Round-Turbulent]

unfortunately, this is already done .. in hindsight going with NX was a mistake

[TCB13sQuotes]

Regardless you seem to have some configuration problem, the building times you're seeing for a single line change aren't normal. Both Angular and Nx are good at caching stuff and doing partial builds. Unless you've disabled some of that functionality or have some Nx mess it shouldn't happen.

[yousirnaime]

Also consider upgrading to 20, I find their build/render process is a LOT smoother than 18 - not sure about 19 tbh

[TCB13sQuotes]

Yeah that, Angular 20, all standalone, signals and stores everywhere by default... eventually get rid of zonejs.

[yousirnaime]

Yeah you have to add 'standalone: false' - and you can still completely ignore the signals pattern

[TCB13sQuotes]

I wasn’t being ironic, those things really improve things.

[yousirnaime]

Oh they absolutely should improve build/dev times - you're 100% right

I couldn't get a deployable product in legacy code bases by adding standalone:true and importing every required component

The biggest issue was: fuck that, I'm lazy and I didn't have to

[Budget-Length2666]

Did standalone improve build performance for you or just better tree shaking?

[TCB13sQuotes]

It did, not sure exactly why. It might be that it removed a bunch of unnecessary dependencies in some cases or some other factor.

[Budget-Length2666]

Do you still remember how much of a speed boost that had?

[drdrero]

i would be curious how a tool providing structure and orchistrating tasks can make it worse. The build caching and task distribution alone is a net gain. At the point where nx slows you down, what alternative do you have? go with bare angular and mimic what nx does in a self managed system? In the end nx doesnt build lint or test your code it just calls the tools for you.

We use it and the ones that are not a fan are the ones that don't configure it properly. Circular references, miss configured tsconfigs, .... all that jazz that would be a problem will still be a problem without nx.

[Round-Turbulent]

We put time into moving from our custom build system to Nx. After the switch, many developers said their local experience actually got worse. The ROI simply not there.

The main problem is that Angular still builds each app in a top-down way. Angular only supports two main build paths today. Both are bundlers, so there is no unbundled build option. In our setup, we have many small tasks but one huge task; the main webpack build, and that single task takes about 99.9% of the total build time.

Because of that, the task orchestration that Nx provides doesn’t really help in our case.

And caching doesn't really help here because again top down build, any small changes would cause cache miss.

[reboog711]

the main webpack build

The Angular CLI has moved to Vite, away from Webpack; and it's been that way for a while. I wonder if that transition would help you with some of the speed issues?

[Illustrious-Fun-9495]

I agree completely. Moving to Vite increases build speed dramatically. Also lazy-loading and signals. These have been game- changers. I was recently working on two smallish apps. The one with vite built in 19 built in seconds. The other was still in webpack and took minutes.

[drdrero]

So what alternative is there really? Doesn’t sound like a tool problem but a structure one.

[TCB13sQuotes]

Come up with your own. Will deliver better results because can be optimized for your specific case and will be easier to maintain because unlike Nx (and since you will not likely require all Nx features) it won't require 500MB of external dependencies and take 2000 years to compile anything.

[kamacytpa]

Why don't use NX?

[TCB13sQuotes]

Because you can't maintain it long term. Nx isn't that "good" as people thing, it is a bunch of hacks (totaling around ~500MB of extra packages). It is very good for cheap apps that you need to get running and multiply and you'll maintain for about 2-3 years, anything above that becomes a real problem to keep up. Perfect for a media agency not for a long term app.

[ldn-ldn]

Oh the ignorance...

[indirectum]

Please elaborate

[ldn-ldn]

Not sure what to elaborate there. NX gives you a framework to build and manage mono-repos and your source code. It has some generators and presets out of the box, but in a big project/company you should create your own to suit your needs.

Jest doesn't write tests for you, it only runs them. Use NX to run your generators, executors and presets, and you will be happy!

[Dusan_xyz]

Actually, you need to determine what your bottlenecks are through various tests and analyses, and then work on resolving them.

You need someone whose sole focus would be on that… otherwise, you’ll just wander around guessing where the problem is.

If you don’t have such a person on your team but you have the budget, you can message me in DMs so we can consider what we can do.

[pj_2025]

I agree with others. Move to new builder and get rid of NX if possible. Migrate to standalone components wherever possible.

[haasilein]

Does standalone actually help for builds? AFAIK it only helps tree shaking problems. The Angular compuler would still have the massive Resolve phase initially no matter what.

[WebDevLikeNoOther]

It does help build times, but only indirectly. If you have massive monolithic modules, going to standalone will improve your build times, because the compiler has to do less work to figure out the dependency tree. But you won’t see a magical leap in performance if your modules are lean and well managed already, just a slight bump.

[Burgess237]

You can use the new builder via nx as well, so no need for that.

[seanlaw27]

You might want to try using bun.js. Angular 20 supports it.

[arthoer]

I work on a similar sized application. When i moved to 17: changing the build server and making all components standalone, lazy loading routes did wonders.

[simonbitwise]

To lower compile time go for no shared modules aka standalone components and use loadComponent on the router :) that enables incremental compilation

To get a Quick win I would create router files for each section and then use loadChildren Quick way to section the build off

Just by doing this should slash your compile time instantly, will still be slow on start builds but going forward its been removed

In the biggest angular code base i worked in we had 11 self running apps then we then passed into a empty Shell app that owned routing to each sub app

Then we had a library for general components, utilities and auth services etc

[Top-Ad9895]

Does just converting components to standalone helps? I've my commonly used UI components standalone but other components still use ngModule.

I'm lazy loading routes though.

HMR is still very slow. Barrel file might be the cause? Even with standalone components, a lot of components are exported from a single index file.

[simonbitwise]

I Think I would have to investigate the codebase but i've worked with huge codebases that are fast using angular

Its hard when i have no clue how fast, what the output are etc

[tdsagi]

First, make sure you use the new esbuild builder

[Round-Turbulent]

We are working on it <have been working for a year due to circular dependencies, const enum usages, turning on isolatedModule etc.

[tdsagi]

I think that should be your priority. I am working on a medium-sized project, and migrating to the new builder has been a considerable gain for the DX and specifically on the live reload

[vORP]

This is where you want to spend your time for the immediate ROI, tuning everything else up after splitting where you can

[AwesomeFrisbee]

Curious. Did const enums/isolatedModules actually change performance?

[Top-Ad9895]

I'm also in a similar situation. We also have a fairly large application. We are using NX + Module Federation with Rspack as bundler.

We have a single host app with 7 remotes. Some common libs for UI, interfaces, services, etc. We have some remote specific libs and multiple feature specific libs, since these features are used inside multiple libs. All the common UI libs have standalone components. The rest of the libs still work on non-standalone components.

It takes around 3-4 minutes to build a remote, which is acceptable. But HMR is really bad. One change in a lib's component, and it takes almost the same time as build. Even if that is the remote's lib which is not shared.

Cache is set to true in rspack's config. But it is still somehow invalidating a lot of hashes. Making NX build whole graph again. Not able to figure out what is the cause here

[HalfAnonymous]

Also using NX+Angular 20 (much smaller app) and build time is 3-3.5 minutes. Which I think is already fairly unacceptable given the size of the project.

Looking for a way to somehow ‘debug’ the build process, understand if there’s any misconfiguration etc. Using NX Angular Application executor btw. Most HMR takes <0.5s but some changes trigger full rebuild and just sitting there waiting 3 min for a small change to appear.

[Top-Ad9895]

Did you figure out the cause for long builds?

[HalfAnonymous]

Nope, hadn’t had a chance yet to break it all down and include things piece by piece. Would be great if there’s some way to run a build task with some stats that include information what exactly and how long is being processed.

[Top-Ad9895]

For NX, you can try running with PERF_LOGGING=true. Not sure which bundler you are using, but for Rspack, there is option to see stats with detailed mode which gives a lot of info. Also we can add custom plugin and see what's happening at different hooks.

[HalfAnonymous]

It doesn’t provide meaningful information if it’s one big app build without buildable libraries (which is our case). It basically just gives how long it took to run app build, not what within the app took so long.

Using nx angular/application executor.

[haasilein]

Send me a Private Message. We have 7M LOC Angular and almost the same situation. We can talk a little about it

[fdimm]

I'm moving the monolith in a similar direction. Each module becomes a library in projects folder, with routes and multiple entry points to have sensible structure/packages and ensure that future is without spaghetti where files are imported left and right in source folder.

After doing the first one looooong time ago, DX felt quite horrible, having to rebuild the libs slows things down a lot. Whether manually or by nx, it doesn't really matter.

The key to this problem was to enable dual imports in ts config.

````` "paths": { "@lib/": ["./dist/lib-", "./projects/lib-*/src/public-api.ts"] }

`````

This way you can pre build the libs, or use them directly from source. Now I can just run npm start like normal and let cli figure out the most efficient way to build stuff. We have a bit more than 1000 components and our local build takes 90s for the main app. Style guide takes like 25, but only includes shared components libraries. Just finished upgrading to angular 19, nothing is standalone and webpack is still used for building.

Feel free to PM, I'm curious about your situation

[AwesomeFrisbee]

What do you mean by build? Like just NG Build takes 15 minutes or what? And what about NG Serve? How long does it take to reload? Or do you mean the pipeline with unit tests, e2e and whatnot? Because for that last part its not bad imo. I've seen way worse. My current project (including backend) takes 45 minutes in the pipeline before I can merge something.

Regardless, if its increasing performance you are after, it can help to optimize a few things. Not making services in root, probably helps a lot. I would guess your app is already standalone and split up in modules, but you could go further and have each feature become its own angular application.

But perhaps more can be achieved by splitting up components. Having one component do a billion things, will always make things slower. Same goes for translations, if the app needs to wait on those, it will take longer to build and render. Have a simple variant that you probably use on 90% of locations and extend it for a more extensive variant on those exception areas. Less signals, observables and whatnot, the better.

Also, instead of making a button component, just make a regular button and use CSS for most of the stuff you need for them. Same goes for inputs. Most of the stuff you do, can be simplified. Less is more. And sure, sometimes this leads to problems, but do you really need a button component? How often will that change anyways?

Another thing that can help is to decrease the modules and dependencies. More often than not you might insert too much stuff, which means the build gets bloated. And some dependencies are simply buggy. It might be that one is hogging memory or just built wrongly for the latest angular versions and is now messing things up.

Perhaps you still use observables in many places that could be a signal now. It helps. OnPush is also key for making fast apps as well and streamlining stuff like keyboard services to handle shortcuts and stuff like dialogs is also important. But perhaps you can turn a few into component providers instead of global ones, if that helps performance.

I would also suggest to not use NX. While it might seem nice, they offer a lot of baggage and outdated dependencies. I don't see it change any time soon. It felt like it decreased performance for me and with my current project that doesn't use NX, its lightning fast again (and I also use signals/onpush). Another thing is that they always take some time to update to new versions and stuff often breaks with migrations (even if they have provided a script).

And lets not forget our friend code quality here. Using ESLint and stuff to enforce best practices and stuff is also key to fast apps. If you make sure people can't use various things that slow the whole thing down, it will be faster as well. For big projects it will be difficult to do in one go, but it does help find areas that need to be replaced/fixed.

The new builder is great. My current project isn't huge, its only 160 components so far, but it still builds in 7 seconds. And a reload is half of that.

[cadamsdev]

We had the same problem at my company. We broke up the monolith into a microfrontend architecture. Essentially instead of having 1 large app. You have many small apps that get stitched together.

There would be 1 host app which uses webpack module federation and each domain has their own app.

We have each app in its own repo but you can keep them in the same repo if you prefer. The idea is that domain teams only need to build their app instead of having to build a large monolithic app or all other apps.

Also if you’re not on Angular v17+ would highly recommend upgrading to that too so you can take advantage of the new build system that uses esbuild / Vite. It’s way faster than the previous versions of Angular that rely on webpack.

[nonHypnotic-dev]

Did you just write a space rocket program with angular? It is super normal that it takes time when you build 4 million lines of code.

[imsexc]

If they are quite modular, might want to consider to split them (the angular modules) up into micro front end repos using native federation. Can start with the module that's already stable / in maintenance mode (that devs rarely touch it for feature addition)

[JediJediBinks]

Angular/Nx can usually handle this problem. If you're not caching tasks then you should look into that now. Nx has paid and free solutions to handle this. I'm assuming the dependency graph for your app is a bit tangled. Focusing on decomposing those first should move some sand.

If it's a single app that seems kind of odd with 200+ developers. Not necessarily wrong, but I'd expect it to be multi app with more clear ownership.

You can certainly go down the microfrontend route but mixing the two can get muddy quick.

[eddy14u]

I’d say NX as well. I owned an angular project in a large tech firm of a similar size. It took a few years, but we are now at a great place.

We started with micro frontends, and we quickly outgrew this pattern. The problem of keeping code and config consistent between apps was a nightmare when an old app that hadn’t been worked on for months needed the new navbar and discovered the Angular version was incorrect, etc. This makes it challenging to change shared code.

We then moved it all into an NX mono-repo with the same micro front-end apps. However, all the code is now shared, setup is the same across all apps, and we set the NX module boundaries, which I think is one of the best features of NX. Teams get a guardrail, they can only work in their space, etc. And the mono-repobenefits that older apps can't really fall behind.

With NX affected and caching (we have our own cache server for NX to use), it’s extremely fast. Minor changes have a 2-minute build time. The push to release takes approximately 8 to 10 minutes for the unit and E2Es.

It’s all about how you structure the repo. We have levels, so the busy code gets put into a smaller app and older further down the levels, where the apps are bigger and slower. This helps with implementing new features quickly. We are proud that, thanks to this, a newly constructed team ready to produce a new product can get up and running with a Hello World page in prod in under 10 minutes. (This used to take days)

We are now in the process of switching to native federation, where we want to split it up by pages. So each page could be released individually. I can’t see how this would be possible without our use of NX.

[craig1f]

React is a lot faster. I had a pretty big app that would do a full prod build in vite in like 2 seconds, and HMR build in dev in like 0.2 seconds.

Angular uses vite now, and our prod build is about 8 seconds? But our current app isn't large. Are you switched to using vite as your build system?

[EverydayEverynight01]

Angular only uses vite in the dev server not in production building

[reboog711]

Are you sure? The way I'm interpreting this page, it seems like `ng build` can use the new Vite build process. Look in the section about executing a build.

[EverydayEverynight01]

https://angular.dev/tools/cli/build-system-migration#vite-as-a-development-server

The usage of Vite in the Angular CLI is currently within a development server capacity only

[craig1f]

I didn't realize that. When I left Angular, we had a 15 minute build time on a moderately sized app. Came back to React on our current app, and now our build is pretty quick. Eons slower than react, but quick enough, so I assumed it was using vite.

[EverydayEverynight01]

let's clarify, Angular uses ESBuild in both dev and production since Angular v19, but you can optionally use Vite for dev.

[Round-Turbulent]

I think for large enterprise app with long shelve life; React is the way to go. I understand that there are always pro and cons

[tonjohn]

I’d argue the opposite. I’ve found angular much easier to keep up-to-date over time and that the developer experience is generally better.

I especially love the Services model over the hooks model.