Framework-Agnostic Architecture: Future-Proofing the Front End

Context

As front-end development matured at FAS, a new failure mode emerged: success itself. Teams were now using Angular, Vue, and AEM in production. Framework-specific implementations risked lock-in, costly rewrites when standards changed, and fragmentation across platforms.

At the same time, the business needed consistency across all digital experiences and the ability to adapt quickly when the underlying technology shifted. These two goals, consistency and adaptability, usually pull in opposite directions.

My role

I played a key role in defining and reinforcing a framework-agnostic architecture inside AXS. This was a strategic architectural decision more than a technical one, it shaped how teams thought about front-end systems, not just what they built. The goal was for AXS to outlast any individual framework choice.

What I did

Designed AXS as framework-agnostic. Components are independent of application frameworks. The same component logic runs across Angular, Vue, and AEM through framework adapters and standards-based custom elements. The implementation is intentionally separated from the application’s technical stack.

Enabled cross-framework component reuse. Same component, same props, same behavior, across stacks. Teams stopped reimplementing UI for each framework.

Future-proofed the platform. Explicitly designed to avoid dependency on any single framework, and to adapt easily to new frameworks, security requirements, and platform shifts. The system is built to “quickly adapt and support any new or better frameworks”, that’s not a marketing line, it’s the architectural premise.

Standardized developer experience across frameworks. Shared component library, Storybook documentation, consistent APIs. One mental model regardless of which framework an engineer works in. Lower learning curve when moving between stacks.

Defended the architecture in real-time decisions. Pushed back on proposals to introduce framework-specific dependencies or external component ownership. Reinforced the discipline so it stayed true under delivery pressure.

Resistance

Pressure toward framework-specific solutions. Teams naturally want faster, local solutions tuned to their stack. The trade-off: short-term wins, long-term fragmentation.

Competing architectural philosophies. Recurring proposals to adopt alternative component frameworks or diverge from the agreed direction. Each one would have reintroduced inconsistency.

Cross-framework complexity. Building genuinely reusable components across Vue, Angular, and AEM is harder than building in any one stack. It demanded discipline, strong standards, and continuous alignment.

How I handled it

Optimized for long-term system health over short-term convenience. Anchored decisions in business flexibility, the framework-agnostic design means the organization is not locked into any technology choice and can evolve safely. Kept the architecture practical, not theoretical: real components, in real applications, proven at scale.

Outcome

• Multi-framework support at scale. Angular, Vue, AEM, all in real production systems.
• Reduced rework and duplication. Components are reused across platforms; teams avoid rebuilding the same UI multiple times.
• Organizational flexibility. Vanguard can adopt new frameworks without rewriting everything. Modernization is incremental.
• Platform evolution unlocked. The same architectural decision is what makes web components, AI-driven development workflows, and the Gen UI work all possible.

Why it matters

This is the highest-leverage architectural decision in the whole sequence. It decouples the organization’s front-end capability from any single technology choice, which is what allows scale, longevity, and adaptability.

From framework-driven development to platform-driven development.

The same instinct shows up again in Chapter 6: when generative UI became the new substrate, AXS was already ready for it because the architecture had never been tied to one stack to begin with.