frontend-patterns/research/plan/ResearchProgram.md

# Frontend Patterns Research Program

## 1. Objective

Develop a coherent Alexander-style pattern language for frontend architecture and design that is useful to both human practitioners and software agents.

The work should move from source collection toward:

1. common vocabulary,
2. recurring forces,
3. candidate patterns,
4. pattern relations,
5. generative sequences,
6. architecture decompositions,
7. technology mappings,
8. machine-readable retrieval and reasoning.

## 2. Research thesis

Frontend architecture is not fundamentally organized around frameworks.

It is organized around recurring decisions concerning:

- authority,
- addressability,
- projection,
- interaction,
- mutation,
- synchronization,
- reconciliation,
- composition,
- execution,
- quality boundaries.

Named architectures and frameworks are configurations or implementations of these decisions.

## 3. First research case

Use Ryan Carniato's "The Grand Unifying Architecture of Frontend" as the first extraction exercise.

Research tasks:

1. reconstruct its Navigation → Content → Affordance model,
2. identify implicit assumptions,
3. extract candidate patterns,
4. identify the forces each pattern resolves,
5. identify where server-authority assumptions cease to hold,
6. compare against local-first architectures,
7. compare against hypermedia architectures,
8. compare against SPA and server-component architectures,
9. map findings into the responsibility model,
10. retain useful concepts without treating the article as the canonical ontology.

## 4. Research streams

### Stream A — Historical GUI architecture

Study:

- MVC,
- MVP,
- Presentation Model,
- Presentation / Domain Separation,
- Flux / Redux,
- Elm architecture,
- event-driven UI.

Goal:

Identify durable state, dependency and interaction patterns that predate current web frameworks.

### Stream B — Web navigation and hypermedia

Study:

- document web,
- REST/hypermedia,
- progressive enhancement,
- HTML forms,
- HTMX-style server interaction,
- browser navigation semantics.

Goal:

Understand addressability, navigation, mutation and server projection.

### Stream C — Rendering and execution

Study:

- CSR,
- SSR,
- SSG,
- hydration,
- partial hydration,
- islands,
- server components,
- resumability,
- streaming,
- edge execution.

Goal:

Separate projection patterns from execution placement and delivery mechanisms.

### Stream D — State authority and synchronization

Study:

- client/server state,
- remote caches,
- optimistic UI,
- local-first,
- CRDTs,
- event sourcing,
- offline-first,
- subscriptions,
- push/pull synchronization.

Goal:

Establish a coherent authority/synchronization/reconciliation language.

### Stream E — Composition and organizational architecture

Study:

- component composition,
- feature slicing,
- microfrontends,
- design systems,
- frontend platform architecture,
- backend-for-frontend patterns,
- monorepos and deployment independence.

Goal:

Separate software composition from ownership and deployment boundaries.

### Stream F — Quality patterns

Study:

- accessibility,
- progressive enhancement,
- performance,
- fault containment,
- security,
- privacy,
- observability,
- recovery.

Goal:

Represent cross-cutting frontend qualities as architectural patterns and forces rather than afterthoughts.

## 5. Research method

For each source or architecture:

### Step 1 — Extract claims

Record what the source says without prematurely normalizing terminology.

### Step 2 — Identify forces

Ask what competing constraints make the proposed solution useful.

### Step 3 — Extract candidate patterns

Look for recurring configurations rather than named technologies.

### Step 4 — Normalize vocabulary

Map source-specific language into the current canon where possible.

### Step 5 — Find counterexamples

Test whether the pattern still holds under:

- offline operation,
- local authority,
- real-time collaboration,
- very low interaction density,
- high interaction density,
- independent deployment,
- unreliable networks,
- strong accessibility requirements.

### Step 6 — Establish relations

Record:

- requires,
- enables,
- refines,
- alternatives,
- conflicts,
- resulting contexts.

### Step 7 — Test generativity

Ask whether the pattern helps produce a next architectural decision.

### Step 8 — Promote cautiously

Move a concept into `patterns/` only when it is sufficiently stable and reusable.

## 6. Initial source families

Create a source catalog spanning:

- Christopher Alexander and pattern-language literature,
- Martin Fowler GUI architecture,
- REST and hypermedia literature,
- Redux / Elm / Flux,
- Feature-Sliced Design,
- microfrontends,
- local-first,
- web.dev rendering literature,
- Patterns.dev,
- framework architectural documentation,
- accessibility and progressive-enhancement literature,
- distributed-systems synchronization concepts.

## 7. Initial pattern extraction targets

Priority candidate patterns:

### Authority

- Server Authority
- Local Authority
- Replicated Authority
- Derived State
- Single Writer

### Address & navigation

- URL as Application State
- Resource Address
- Hierarchical Route
- Progressive Navigation

### Projection

- Static Projection
- Server Projection
- Client Projection
- Streaming Projection
- Islands of Interactivity

### Interaction

- Local Interaction State
- Immediate Feedback
- Pending State
- Optimistic Overlay

### Synchronization

- Invalidate and Reproject
- Pull Synchronization
- Push Synchronization
- Persistent Subscription
- Conflict-Free Merge
- Explicit Conflict

### Composition

- Presentation / Domain Separation
- Vertical Feature Slice
- Independent Feature Boundary
- Backend for Frontend

### Quality

- Progressive Enhancement
- Failure Boundary
- Accessible by Construction
- Performance Budget
- Observable Interaction

## 8. Validation architectures

The emerging language should be tested against at least these application types:

1. mostly-static publication,
2. e-commerce storefront,
3. administrative CRUD application,
4. high-interaction SaaS workspace,
5. real-time dashboard,
6. collaborative editor,
7. offline field application,
8. local-first personal tool,
9. large microfrontend estate,
10. mobile-web/PWA application.

A useful language should explain all ten without forcing them into one preferred architecture.

## 9. Agentic use cases

The infospace should eventually support prompts such as:

> Given this application description, identify the dominant forces and propose applicable patterns.

> Explain why the current architecture exhibits this failure mode.

> Which patterns are incompatible with our offline requirement?

> Decompose this framework architecture into technology-independent patterns.

> What pattern should be considered next after choosing server authority and streaming projection?

> Compare two architectures in terms of forces, not framework features.

This requires graph-friendly metadata and stable identifiers.

## 10. Initial milestones

### M0 — Scaffold

- repository structure,
- intent,
- responsibility model,
- force vocabulary,
- relation vocabulary,
- pattern schema,
- research method.

### M1 — Seed corpus

- source catalog,
- Carniato case analysis,
- historical GUI architecture review,
- local-first review,
- rendering architecture review.

### M2 — First canonical language

- 20–30 candidate patterns,
- reviewed force vocabulary,
- relation graph,
- first architecture decompositions.

### M3 — Generative sequences

- general web application,
- content site,
- transactional application,
- collaborative application,
- local-first application.

### M4 — Agentic reference surface

- normalized metadata,
- stable identifiers,
- pattern graph export,
- query examples,
- retrieval/evaluation fixtures.

### M5 — Empirical refinement

- test language against real repositories,
- collect pattern co-occurrence,
- identify missing forces,
- identify misleading or redundant patterns,
- revise maturity levels.

## 11. Open research questions

1. Is the current responsibility model minimal?
2. Should mutation be separate from intent?
3. Is reconciliation a responsibility or a synchronization subfamily?
4. Is addressability a frontend responsibility or a system-level concern?
5. Should rendering and projection remain distinct terms?
6. How should temporal behavior be represented?
7. How should pattern strength or evidence be measured?
8. Can pattern selection be meaningfully represented as constraint solving?
9. How should anti-patterns be modeled?
10. Can architecture health be described as unresolved or contradictory forces?

## 12. Definition of useful progress

The project is not advanced by adding pattern names alone.

Useful progress means improving one or more of:

- conceptual precision,
- pattern reuse,
- relation quality,
- generative power,
- evidence quality,
- applicability across architectures,
- retrieval quality for humans and agents.