--- title: "10 — Frontend Architecture — Paradigms, Frameworks, and Rendering" uid: frontend-architecture tags: ["functional-programming", "react", "ssg", "roadmap:software-architect", "angular", "vue", "reactive", "ssr", "microfrontends", "spa", "frontend"] excerpt: "Two independent axes — the paradigm the UI is written in and the rendering strategy that ships it — and most frontend confusion comes from conflating them." date: 2026-08-13T03:27:40+0000 source: https://www.aveshina.my.id/en/blog/frontend-architecture --- 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]. ```figure SPA load once, update client-side initial HTML: mostly empty JS fills content at runtime smooth UX slow first paint weak SEO SSR server renders HTML per request browser gets real content immediately on each load fast first paint good SEO SSG pre-built at build time served as static files no per-request render cost fastest performance best for rarely-changing content ``` 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](https://roadmap.sh/software-architect/web-mobile) [2] TechTarget, "What is Reactive Programming?," [Online]. Available: [https://www.techtarget.com/searchapparchitecture/definition/reactive-programming](https://www.techtarget.com/searchapparchitecture/definition/reactive-programming) [3] "Functional programming," Wikipedia. [Online]. Available: [https://en.wikipedia.org/wiki/Functional_programming](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](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](https://roadmap.sh/software-architect/spa-ssr-ssg) [6] "Micro Frontends," micro-frontends.org. [Online]. Available: [https://micro-frontends.org/](https://micro-frontends.org/) [7] "W3C and WHATWG," roadmap.sh — Software Architect. [Online]. Available: [https://roadmap.sh/software-architect/w3c-and-whatwg](https://roadmap.sh/software-architect/w3c-and-whatwg) ```quiz Q: An architect is choosing a rendering strategy for a marketing site that rarely changes and needs strong SEO and fast load. Best fit? - SPA - SSR - SSG correct: 2 explain: SSG pre-builds pages at build time, giving the fastest performance and good SEO for content that changes rarely — exactly a marketing site's profile. Q: What's the key difference between React and Angular as frameworks? - React is server-only; Angular is client-only - React is a flexible library with a large ecosystem; Angular is a complete opinionated framework out of the box correct: 1 explain: React trades opinions for flexibility (you assemble your stack), while Angular ships routing, forms, and state management built in. Vue sits between them. Q: Reactive programming in modern frontend is best described as… - using automated data streams to propagate changes to the UI as underlying data changes - writing all logic in assembly language correct: 0 explain: Reactive programming models state as streams; when values change, the UI updates automatically. That propagation is how frameworks avoid manual DOM manipulation. Q: When do microfrontends earn their complexity? - Whenever a project uses React - When multiple teams genuinely need to ship frontend independently, like the frontend analog of microservices correct: 1 explain: Microfrontends trade integrated simplicity for team and deployment independence. For a single team it's overhead; it earns its keep when independent delivery is a real organizational need. Q: Why separate the "paradigm" axis from the "rendering strategy" axis? - Because the same component framework can be rendered as SPA, SSR, or SSG — the choices are independent - Because rendering strategy determines which programming language you must use correct: 0 explain: A React (component-reactive) app can be shipped any of three ways. Conflating paradigm with rendering is where most frontend confusion comes from; they're independent decisions. ```