10 — Frontend Architecture — Paradigms, Frameworks, and Rendering

Frontend choices felt like one big intertwined decision until two axes appeared. The model that untangled the cluster: there are two independent axes — the paradigm the UI code is written in, and the rendering strategy that ships HTML to the browser — and most frontend confusion comes from conflating them [1]. A reactive component library can be rendered any of three ways; the choice of framework doesn't dictate the rendering strategy.

An architect working on user-facing products needs to understand these choices even when not writing the frontend code themselves [1].

Paradigms: reactive and functional

Two programming paradigms run underneath modern frontend code.

Reactive programming relies on asynchronous logic to handle real-time updates — automated data streams propagate changes through the UI whenever underlying data changes [2]. The way of thinking is _streams_ of values over time, and the UI reacts as new values arrive. This is the backbone of how modern frameworks keep the screen in sync with state without manual DOM manipulation.

Functional programming treats computation as the evaluation of pure functions, avoiding shared state and mutable data where possible [3]. Pure functions — same input always yields same output, no side effects — are easy to test and reason about. Concepts like immutability and pure functions increasingly appear even in languages that aren't purely functional [3]. In frontend code, functional style shows up as immutable state updates (never mutate, always return a new object) and pure render functions.

The two aren't rivals. A modern React codebase is reactive (state changes propagate to the UI) and functional-leaning (immutable state, pure components) at the same time.

Frameworks: React, Vue, Angular

React, Vue, and Angular are the popular tools for building interactive web UIs through reusable components [4]:

• React — a flexible component model with a large ecosystem. A library more than a framework; you assemble your own stack around it.
• Vue — emphasizes simplicity and gradual adoption. Easier to drop into an existing project.
• Angular — a complete, opinionated framework out of the box, with its own routing, forms, and state management built in.

An architect chooses based on team experience, project scale, and how much structure the framework should enforce [4]. React trades opinions for flexibility; Angular trades flexibility for opinions; Vue sits in between.

Rendering strategies: SPA, SSR, SSG

This is the axis I had to separate from the framework choice. The same React app can be rendered three ways, and the trade-offs are about performance and SEO, not about the framework:

• SPA (Single-Page Application) — loads once and updates content dynamically without full page reloads. Smooth UX, but slower initial load and weaker SEO because the initial HTML is mostly empty [5].
• SSR (Server-Side Rendering) — the server generates HTML on each request. Faster initial load and better SEO because the browser gets real content immediately [5].
• SSG (Static Site Generation) — pages are pre-built at build time. The fastest performance for content that doesn't change often [5].

The architect chooses between these based on performance needs, content type, and SEO requirements [5]. A marketing site wants SSG; a highly interactive dashboard behind a login (where SEO is irrelevant) is fine as an SPA; a content-heavy site that updates frequently wants SSR. Modern meta-frameworks (Next.js, Nuxt) blur the lines by letting you mix strategies per-page — but the underlying trade-offs are still these three.

Microfrontends

Microfrontends is an architectural style where independently deliverable frontend applications — built by different teams, possibly using different technologies — are composed into one whole [6]. A host/container page mounts one or more microfrontend fragments, each owning a portion of the page rather than the entire thing. It's the frontend analog of microservices: trading integrated simplicity for team and deployment independence, and paying for it with integration complexity. It earns its keep when multiple teams genuinely need to ship frontend independently; for a single team it's overhead.

Standards: W3C and WHATWG

Underneath all of this sit the W3C and WHATWG, the organizations responsible for defining and maintaining web standards like HTML and CSS [7]. The W3C historically focused on formal standardization, while WHATWG — formed by browser vendors — drives the living standard for HTML that modern browsers actually implement. Knowing these bodies matters less day-to-day than knowing where to find authoritative guidance: when a browser behavior is surprising, the WHATWG HTML standard or the relevant W3C spec is the source of truth, not a blog post [7].

How I use this

I keep the two axes separate in any frontend decision. First, pick the rendering strategy from the content and SEO needs (SSG for marketing, SSR for dynamic content with SEO, SPA for interactive tools behind auth). Then, within that strategy, pick the framework based on team experience and how much opinion the project wants. Reactive and functional style are defaults I apply inside whatever framework — immutability and pure components are cheap discipline that pays off in testability. Microfrontends I reach for only when the org chart actually forces independent frontend delivery.

References

[1] "Web and Mobile," roadmap.sh — Software Architect. [Online]. Available: https://roadmap.sh/software-architect/web-mobile

[2] TechTarget, "What is Reactive Programming?," [Online]. Available: https://www.techtarget.com/searchapparchitecture/definition/reactive-programming

[3] "Functional programming," Wikipedia. [Online]. Available: https://en.wikipedia.org/wiki/Functional_programming

[4] "React, Vue, Angular," roadmap.sh — Software Architect. [Online]. Available: https://roadmap.sh/software-architect/react-vue-angular

[5] "SPA vs SSG vs SSR," roadmap.sh — Software Architect. [Online]. Available: https://roadmap.sh/software-architect/spa-ssr-ssg

[6] "Micro Frontends," micro-frontends.org. [Online]. Available: https://micro-frontends.org/

[7] "W3C and WHATWG," roadmap.sh — Software Architect. [Online]. Available: https://roadmap.sh/software-architect/w3c-and-whatwg