01 — Purpose

Architecture is not a logo

Framework choice does not automatically create good frontend systems — structure, ownership, and governance do.

React, Vue, Angular, and Svelte are delivery tools. Architecture is how you organise components, state, CSS, content, accessibility, performance, and review so the system survives the next framework fashion cycle.

02 — Scope

What frameworks solve — and do not

Frameworks help with rendering and composition; they do not replace standards or product quality.

A framework may improve rendering, state handling, and developer experience. It does not automatically deliver accessible markup, fast delivery, clear folder boundaries, or enforceable review — those come from deliberate architecture documented in places like frontend governance and folder structure.

03 — Reality

Weak architecture exists everywhere

Poor systems exist in every stack — the framework is rarely the root problem.

Teams blame the framework when the real issues are unowned shared components, missing progressive enhancement, global state sprawl, and standards nobody enforces. Strong systems pair a framework with progressive enhancement, state management strategy, and design system governance — regardless of vendor.

04 — Discipline

Frameworks can accelerate complexity

Popularity is not a substitute for boundaries.

Frameworks make it easy to over-abstract, duplicate patterns without owners, and ship JavaScript-first solutions for problems the platform already handles. Popularity does not excuse skipping semantic HTML, performance budgets, or accessibility review.

05 — Close

Your framework is a tool

Your framework is a tool. Your architecture is the system around it.

Choose frameworks for fit, not hype. Document boundaries, ownership, and delivery expectations so the stack can change without rewriting how the team thinks about quality.

See component architecture and principles.