Building a component architecture before components existed

The problem

A UK professional services software company had built a successful business on established desktop technology. Their software served thousands of users daily, but the market was shifting toward web-based interfaces.

The technical challenge was significant: how do you introduce modern web development patterns to a team experienced in desktop application development, while maintaining the reliability your customers depend on?

The constraints

The team faced several practical constraints that ruled out a simple "rebuild everything" approach:

• Existing investment: Years of business logic and customer workflows built into the current system
• Team expertise: Strong desktop development skills, limited web development experience
• Customer continuity: No tolerance for extended downtime or disruptive changes
• Budget reality: No appetite for a multi-year ground-up rewrite

The web landscape in 2014-2015 was also challenging. Modern frameworks like Vue.js and React were still emerging. jQuery remained dominant, but jQuery projects often became difficult to maintain as they grew - spaghetti code, tight coupling, and unpredictable state management.

Our approach

Rather than wait for framework maturity or attempt a risky rewrite, we designed a custom jQuery architecture that borrowed patterns from emerging component-based frameworks.

Component-like structure

We introduced organisation principles that would later become standard in React and other modern frameworks:

• Encapsulated modules: Each UI element owned its own markup, styles, and behaviour
• Clear data flow: Explicit patterns for passing data between modules
• Lifecycle methods: Initialisation, update, and cleanup hooks for predictable behaviour
• Event-driven communication: Loose coupling between modules through a central event bus

Progressive adoption

The framework was designed for gradual adoption rather than big-bang replacement:

• New features built using the component architecture
• Legacy code wrapped in compatibility layers
• Team members could learn patterns incrementally on real projects

Knowledge transfer

Beyond the technical architecture, we invested heavily in transferring knowledge to the team:

• Regular code reviews focusing on architectural patterns
• Documentation of conventions and best practices
• Pair programming sessions to embed the thinking behind the patterns

Outcomes

Technical foundation

The component architecture delivered immediate benefits:

• Maintainable growth: New features followed consistent patterns, reducing cognitive load
• Testability: Isolated modules were easier to test and debug
• Team productivity: Clear conventions reduced decision fatigue and code review friction

Natural React transition

The most significant long-term outcome: when the company adopted React around 2020, the team transitioned naturally.

• Familiar patterns: React's component model mapped directly to patterns the team already used
• Low learning curve: Concepts like props, events, and lifecycle hooks were already embedded
• Preserved investment: Architectural thinking transferred, even as implementation details changed

Organisational capability

The team developed capabilities that extended beyond the specific technology:

• Ability to evaluate new frameworks against established patterns
• Confidence to adopt modern tools when the timing was right
• Foundation for ongoing modernisation without disruption

Pattern evolution

The jQuery framework anticipated several patterns that became standard in modern frameworks:

State management: Rather than scattering state across DOM elements and global variables, modules maintained internal state objects with controlled mutation patterns. This directly mapped to React's state management and Redux patterns.

Template binding: While not as sophisticated as React's virtual DOM and JSX, we implemented conventions for updating DOM elements in response to state changes - a manual version of what modern frameworks handle automatically.

Component communication: The event bus pattern for cross-component communication foreshadowed React's prop drilling and context patterns, and the move toward more sophisticated state management solutions.

Why this worked

The success came from focusing on principles rather than specific technologies:

1. Separation of concerns: Keeping markup, style, and behaviour organised
2. Explicit data flow: Making dependencies visible rather than hidden
3. Lifecycle awareness: Understanding when code runs and why

These principles are framework-agnostic. Learning them through jQuery made the team ready for whatever came next.