Frontend paradigms: how to choose your web application's architecture

Before choosing a tool, choose a paradigm

When a team argues over "React or Angular?", it is often arguing over the wrong question. The decision that really costs years of maintenance is a different one: where and when the screen is assembled. In the user's browser? On a server, on every visit? Once, when the site is built? Or is it an application installed on a computer or a phone?

Each answer is a paradigm, with real advantages and costs that do not show up in the demo. This article is a map for a CTO or a digital director: what each one is, when it fits depending on the business, what it really costs and how to move out of one without rewriting everything. It is judgment, not a recipe.

1. Single-page application (SPA)

MDN defines it as a web application that loads a single document and updates its content with JavaScript whenever something else has to be shown. The advantage: users navigate without reloading whole pages, with a more dynamic experience. And MDN also names the cost: SEO, more effort to maintain state and navigation, and to measure performance in a meaningful way.

React's documentation adds another: SPAs are easy to start with, but they can have slower initial load times, and if every component requests its data after it is painted, "waterfalls" of requests form, where each step waits for the previous one.

Where it fits: internal systems and dashboards behind a login, and any product with very intensive interaction where arriving from a search engine is not the priority: there, interaction matters more than the first load.

2. Server-side rendering (SSR)

The server assembles the HTML on every request and sends it ready to use. Angular sums it up this way: the server responds with a rendered document, which gives faster loads than client-side rendering and complete HTML for crawlers. web.dev names the counterweight: the first byte may take longer, because the server has to work before it responds.

There is a nuance worth understanding: the page "looks" ready before it is interactive. web.dev describes it as hydration: until the JavaScript finishes, the page seems ready, but its interactive features do not respond yet.

Where it fits: public pages whose content changes per visit or per user and that matter for search engines.

3. Static site generation (SSG)

The HTML for each URL is generated once, when the site is built. According to web.dev, that gives consistently fast response times and allows it to be served from a content delivery network (CDN); according to Angular, the site can be deployed with only a CDN or a file server, without maintaining a server of your own. The limit is also in web.dev: it is unworkable when there are millions of unique pages, and it requires knowing the URLs in advance.

Where it fits: corporate sites, documentation, blogs, catalogs that rarely change.

4. Hybrids and islands

Real practice is rarely "one or the other". Angular describes hybrid rendering as the combination of server, static and client, route by route. Next.js expresses it with server and client components: by default, pages and layouts are assembled on the server, and only what needs state, events or browser APIs is marked as client, so less JavaScript is sent.

// Illustrative, from the Next.js documentation: the page is assembled on the server
// and only the button (marked with 'use client') is interactive in the browser.
<LikeButton likes={post.likes} />

Islands architecture takes the idea to the extreme. Astro's documentation describes it like this: most of the page is static HTML, and only small "islands" receive JavaScript, only where it is needed.

Where it fits: almost any public product with interactive areas: a static catalog with a quoting tool, a content site with a shopping cart.

5. Microfrontends

They split a large application into parts that different teams build and release separately. single-spa's documentation calls them "a microservice within the browser", each with its own repository and its own build; webpack's Module Federation allows separate builds to form a single application and share dependencies.

Now, what those pages do not say and we do: a microfrontend solves an organizational problem, not a technology problem (our judgment; the cited sources describe benefits and not costs). It makes sense when several teams, with different release rhythms, collide in the same codebase. With a small team it adds seams that someone has to maintain: shared library versions, visual consistency between parts and an experience that does not feel stitched together.

And there is a cost that reaches the user: if each team loads its own copies of the same libraries, the browser downloads the same thing several times. The sources themselves recommend sharing instances of the large libraries; whether that happens depends on the teams coordinating, and it is verified with the performance signals we mention below.

6. Cross-platform desktop and mobile applications

When the browser is not enough, there are three paths of a different nature:

• Installable web application (PWA). According to MDN and web.dev, it is an application built with web technologies that is installed, can work without a network, receive notifications and use the full screen, with a single codebase. MDN specifies that it still relies on a browser engine and must be designed with progressive enhancement, because advanced APIs are not in all browsers.
• Desktop. Electron packages Chromium and Node.js to build desktop applications with JavaScript, HTML and CSS on Windows, macOS and Linux; its documentation clarifies that the process that displays the interface has no direct access to Node.js, for security. Tauri takes another path: it uses the operating system's own web engine and a core in Rust, which its documentation points to as the reason its applications are very small. Each decision has its cost: bringing your own engine gives more uniform behavior across systems; depending on the one each system provides saves size, but the engine can differ from one system to another and the team must resolve visual and behavioral differences (our judgment; in both cases you must test on each operating system you support). When desktop really is the answer —printers, readers, scales, local files— we explain it in Is your web application no longer enough?.
• Cross-platform mobile. React Native creates, at runtime, the native Android and iOS views from React components; that is why, according to its documentation, the applications look and feel like any other. It is a third way between the mobile web and two separate native developments.

When none of this is needed

If what you need is a standard blog or store, an already-built content platform, rendered on the server in the classic way, can be a better business decision than putting together a custom architecture (our judgment). A paradigm is chosen when there is a problem that justifies it, not for novelty.

How to choose according to your business

The costs that don't show up in the demo

• Cost of operating. Static is served with a CDN; server-side rendering requires running code on every visit, on a server of your own or a provider's, with its usage-based cost, its scaling and its monitoring. That a provider manages the infrastructure changes who operates it, not that someone must watch over it.
• Cost of talent. Each paradigm asks for different skills. A well-built hybrid requires the team to understand what runs where; otherwise, errors appear that only happen "on the server". And volume counts: a tool with fewer people who master it can lower the infrastructure cost and raise the hiring cost (our judgment).
• Cost of measurement. Choosing a paradigm does not improve performance on its own. Google defines its three experience signals at the 75th percentile of page loads, segmented between mobile and desktop: they are measured with real users, before and after each decision.
• Cost of security. Moving logic to the server protects secrets, but an exposed server also has to be defended; moving logic to the client makes it public (we detail it in What a Professional Frontend Needs).
• Cost of exit. The most forgotten: how much it costs to change your mind. A paradigm that forces a rewrite in order to change is an expensive decision even if today it looks cheap.

Migrating without rewriting everything

Rewriting from scratch is the option that costs the most and the one that takes longest to deliver results. The alternative we recommend, as a judgment, is to migrate by routes, starting with the ones that weigh most for the business. The sources make it possible: Next.js states that an existing SPA can migrate without being fully rewritten, that it can start as a static site or even as a strict SPA and add server features progressively, and it offers incremental migration guides from other environments. React's documentation points out that a framework covers from the start what a client-only application solves by hand, such as avoiding request waterfalls.

Three questions put a migration in order:

1. Which screen costs you the most today? Slow loads on the one that generates revenue, or a public page that cannot be found. Start there, not with the easiest one.
2. What can be moved without touching the business logic? Presentation can usually be separated from logic; if not, that is the first finding.
3. How will you know it improved? Define the signal first (performance, conversion, errors) and measure it with real data.

What to answer before deciding

Five questions a committee can answer in an hour: who arrives from a search engine and who does not? What data cannot live on the device? How many teams touch the same product? Which channel does your most important customer use? And, above all, how much would it cost you to change architecture three years from now?

Closing

The right architecture is not the most modern one: it is the one your business can operate, measure and change. At Hábil we help you choose it with a shared judgment and build the migration path your team can sustain.