Case Studies: Successful Angular.js Projects by Sodio

A look at how Sodio has applied AngularJS across real-world projects, what architectural decisions held up, and where the framework's constraints shaped what we built.

What Makes AngularJS Still Relevant in Production Systems?

AngularJS (Angular 1.x) is frequently declared dead. The Angular team officially ended long-term support in December 2021. Yet a non-trivial number of production systems still run on it, and some of those systems handle serious business logic. The question worth asking is not whether AngularJS is the right choice for a greenfield project in 2025 (it is not), but whether teams who inherited or built on it made sensible architectural decisions, and what those decisions cost them over time.

At Sodio, we have built and maintained AngularJS systems at scale. Some were new builds in the framework's prime years. Others were stabilisation and migration projects. The patterns that succeeded and the ones that failed are worth documenting clearly.

How Does AngularJS Perform Under Real Load?

AngularJS's two-way data binding is its most cited performance liability. The digest cycle checks every watcher on every $scope.$apply() call. At under 2,000 watchers, this is rarely perceptible. Above 2,000, especially with nested ng-repeat and complex expressions, frame drops become measurable.

What we did about watcher count

On one internal enterprise dashboard project handling multi-source financial data feeds, we hit approximately 4,500 active watchers on the main view. The fix was not architectural — it was surgical:

• Replacing two-way bindings with one-time bindings (::value) wherever write-back was unnecessary dropped watcher count by roughly 40%.
• Switching inner ng-repeat blocks to use track by with a unique identifier eliminated unnecessary DOM diffing.
• Splitting the single large controller into smaller components with isolated $scope let us destroy and recreate scopes rather than carry watchers across the session.

After these changes, the digest cycle time on Chrome DevTools dropped from around 18ms to under 6ms on a mid-range laptop. Not a theoretical improvement: users reported the interface felt noticeably faster before we told them we had changed anything.

Virtual scrolling

For tables with over 10,000 rows, we used angular-virtual-scroll rather than paginating server-side. This trades network latency for DOM size. Whether that trade-off is right depends on how frequently users scan large datasets vs. drilling into individual records. In our case, the users did a lot of scanning, so holding data client-side and virtualising the render was the better call.

A Financial Reporting Module: Decisions We Would Make Differently

One project that ran for about three years on AngularJS was a financial reporting module integrated with a legacy ERP backend. The frontend consumed REST endpoints from a Node.js middleware layer and displayed structured reports with drill-down capabilities.

The AngularJS choices that worked:

• ui-router with nested states mapped cleanly onto the drill-down navigation model. Each report level was a named state with its own resolve block.
• Angular's dependency injection made unit testing services straightforward. We ran the test suite with Karma and Jasmine, and the coverage stayed above 75% throughout the project lifecycle.
• $http interceptors handled auth token refresh without duplicating logic across services.

The choices that created technical debt:

• We used $broadcast and $on for cross-controller communication early on. This became genuinely difficult to trace once the application had 30+ controllers. We should have moved to a shared service with explicit subscriptions from the start.
• We deferred the migration to a component-based architecture (which AngularJS 1.5 introduced via .component()) too long. Refactoring controllers into components later took about six weeks of effort that could have been front-loaded.
• The build pipeline used Grunt. By the time the project matured, the ecosystem had moved to Webpack and the difference in build times was significant: roughly 45 seconds for a full build vs. under 10 seconds on equivalent Webpack configs we tested.

What Does Migrating From AngularJS to Angular Actually Cost?

Google's official migration path is the ngUpgrade hybrid approach, where Angular 2+ and AngularJS run simultaneously in the same application. In practice, this is workable but expensive. You are running two change detection systems, two DI containers, and two module systems simultaneously.

The realistic migration cost factors:

Factor	Typical impact
Component count	Each AngularJS controller-template pair needs rewriting
Service layer complexity	AngularJS services often carry implicit $scope assumptions
Third-party dependencies	angular-* libraries rarely have Angular equivalents
Test coverage	High coverage slows refactoring speed but reduces regression risk
Team TypeScript fluency	Angular 2+ is TypeScript-first; learning curve is real

For one system we evaluated, a 60,000-line AngularJS codebase with modest test coverage, the honest estimate for a full ngUpgrade migration was 14 to 18 months of one senior frontend engineer's time, plus testing. The business case for migration has to be strong enough to justify that. In some cases, the right answer is to freeze the AngularJS layer and build new features as separate micro-frontends in a modern framework, communicating via a shared event bus or Module Federation.

Is AngularJS the Wrong Choice for New Projects in 2025?

Yes, plainly.

AngularJS has no security patches, no LTS support, and its ecosystem is in maintenance mode at best. Any new project choosing it would inherit known CVEs without the prospect of official fixes, and would face increasing difficulty finding engineers who want to work in it.

If you have a team that knows Angular (2+), React, or Vue, any of those is a better starting point. If you are in a context with strict framework constraints, Svelte and Solid are worth evaluating for their smaller runtime footprints and more predictable reactivity models.

The only argument for AngularJS in 2025 is existing investment: a large codebase that works, a team that knows it deeply, and a migration cost that exceeds the business value of modernising. Even then, a migration roadmap should be active, not indefinitely deferred.

Conclusion

AngularJS did a lot of things well for its era. The projects we built on it taught us that framework choice matters less than the discipline applied to it: watcher management, component boundaries, service architecture, and build tooling all determined whether the system aged well or became painful to maintain.

If you are maintaining an AngularJS system and deciding what to do with it, the most useful first step is an audit of watcher count, test coverage, and third-party dependency health. Those three numbers will tell you more about migration risk than any general advice will.

If you are considering building something new and wondering whether Sodio can help you make that architectural call, we are direct about trade-offs. Reach out and we can talk through what you are actually building.

FAQ

Is AngularJS still used in production systems? Yes. Many enterprise systems built between 2013 and 2018 still run on AngularJS. Official LTS ended in December 2021, which means no security patches from Google. Teams running it in production should have a migration plan, even if the timeline is measured in years rather than months.

What is the biggest technical risk in an AngularJS codebase? Watcher bloat and unmanaged $scope chains are the most common performance risks. On the security side, the absence of official CVE patches is the more serious concern. Any dependency audit on an AngularJS project will surface outdated transitive dependencies that carry known vulnerabilities.

Can AngularJS and Angular 2+ run in the same application? Yes, using Google's ngUpgrade library. This lets you bootstrap Angular inside an AngularJS app and migrate components incrementally. The trade-off is a larger bundle, dual change detection overhead, and increased architectural complexity during the transition period.

How long does a typical AngularJS to Angular migration take? It depends heavily on codebase size, test coverage, and how component-oriented the existing code is. A well-structured 30,000-line codebase with good coverage might take six to nine months. A larger, controller-heavy codebase with minimal tests can easily exceed 18 months of dedicated effort.

Should we rewrite or migrate incrementally? Incremental migration with ngUpgrade reduces risk by letting you ship and test changes continuously. A full rewrite is faster on paper but carries significant regression risk, especially if test coverage is low. The right call depends on your release cadence and how much of the existing code actually needs to change versus being preserved as-is.

Have a project in mind? Contact Sodio Technologies to discuss your requirements and explore the right technology solution for your business.