Web development guides
How modern websites are built
This article explains what runs in the browser, what runs on a server, and where the boundary sits, without assuming a computer science background.
Nuxt 7.3% share
among tracked Singapore sites, 2026
The client and the server
Two halves, one conversation
Confusion usually starts when someone calls the frontend "the whole site". It is one half of a conversation.
The two halves of a website
Every website has a client side and a server side. The client is what the visitor's browser runs: HTML for structure, CSS for presentation, JavaScript for behaviour. The server delivers files, queries databases, and decides what each visitor is allowed to see.
It helps to picture the split as a conversation rather than a hierarchy. The browser asks; the server answers with the exact pieces that visitor is allowed to receive. When a page feels slow or wrong, the question is usually which half is doing the work, not which half is more important.
A practical consequence: anything a visitor should not see, such as a private key or a database query, has to stay on the server side. Anything the visitor should feel instantly, such as a button responding to a tap, is better handled in the browser.
Framework choice is easier to reverse early than late. Most teams change a framework once, at the start, and live with the decision for years.
What a frontend framework actually does
A frontend framework gives you a structured way to build the client side. It decides how you describe an interface, how that description turns into HTML, and how the page updates when data changes underneath it.
React, created by Meta, lets you compose interfaces out of components and manage state as data changes. Angular, backed by Google, takes a more opinionated approach with conventions for large applications. Svelte compiles your components ahead of time into smaller JavaScript, so less work happens in the browser at runtime.
The differences matter most as a project grows. A small site can be built with any of them and rewritten later without much pain. A large application with many contributors tends to feel its framework's opinions every day, which is why the choice is easier to reverse early than late.
Framework notes
Three common starting points
-
React
Component-driven, with a wide ecosystem of libraries for routing, forms and data fetching.
-
Angular
Convention-first, with tooling aimed at large teams that want one agreed way to structure a project.
-
Svelte
Compiled ahead of time, so the shipped JavaScript tends to be smaller for the same feature set.
Server-side rendering and why it returns
Server-side rendering means the server builds the HTML before sending it, so the visitor sees content sooner and search engines have something concrete to read. Meta-frameworks handle this without you writing the plumbing yourself.
Nuxt does this for Vue-based projects and holds a reported 7.3% share among tracked Singapore sites in 2026. Next.js plays a similar role for React projects, and other meta-frameworks follow the same idea with different defaults.
For content-heavy sites, rendering on the server often beats shipping an empty page and filling it in with JavaScript afterwards. The visitor gets text and layout immediately; the browser can then take over for the interactive parts.
The trade-off is that the server does more work per request, and the team has to think about caching. That is usually a reasonable exchange for a site whose first job is to be read.
Nuxt 7.3%
Reported share among tracked Singapore sites, 2026.
Meta-frameworks and project structure
A meta-framework is a framework's framework. It adds routing, data loading, build tooling and rendering strategies on top of a base library, so the common problems already have an agreed answer.
Routing and file layout
Pages become folders; a new screen means a new file in an agreed place rather than a new decision.
convention
Data loading
Each route can declare what it needs before it renders, so the page does not arrive half-built.
per route
Rendering strategy
Static, server-rendered and browser-rendered pages can sit in one project, chosen page by page.
per page
Build tooling
Bundling, code splitting and asset handling arrive configured, so the team argues less about setup.
included
The benefit is that common problems already have an answer. The cost is that you are adopting someone else's opinions about how a project should be laid out. Teams that fight those opinions tend to have a worse time than teams that pick a meta-framework whose defaults they can live with.
Component libraries and the design system layer
Most production sites assemble interfaces from a component library: buttons, form fields, modals, and navigation blocks that already handle accessibility and state. Instead of rebuilding a dropdown for the fourth time, the team reuses one that has already been tested with a keyboard and a screen reader.
A design system goes further and documents when to use each component. It records which button is primary, how much space sits between form fields, and what a warning message should look like. That documentation is what keeps a site coherent when ten people build ten screens.
GovTech Singapore's SGDS is a public-sector example built to give government sites a common visual language. Even without a formal system, any project with more than one developer benefits from agreeing on components before building them twice.
Components arrive tested
Keyboard focus, disabled states and error messages are handled once, in the library, rather than per screen.
A system records the rules
Naming, spacing and colour decisions live in one place, so a new screen looks like it belongs to the same site.
Governance keeps it honest
Someone has to own the library, review additions, and retire components that no longer fit the product.
Lightweight alternatives to a full app
Not every site needs a single-page application. A marketing page, a documentation site or a content-heavy portal can be rendered by a server and made interactive with a small script, which usually means less code to maintain and a faster first paint.
Alpine.js, reported at 2.7% share among tracked Singapore sites in 2026, adds interactivity to HTML that a server already rendered, which suits CMS builds and marketing pages. Svelte, at 0.8%, appeals to teams that want concise components and a smaller client bundle.
Choosing one of these over a larger stack is a legitimate engineering decision, not a shortcut. The deciding question is how much of the interface genuinely needs to change without a page reload.
Reported shares, 2026
2.7%
Alpine.js among tracked Singapore sites
0.8%
Svelte among tracked Singapore sites
Where the database and API fit
Behind the rendering layer sits data: a database, an API, or a third-party service. How the frontend talks to it shapes the whole build, and the decision is usually made page by page rather than once for the entire site.
Fetching on the server
A site that fetches data on the server avoids exposing credentials and can cache responses. The browser receives finished content, which suits pages where the same answer serves many visitors.
Fetching in the browser
A site that fetches in the browser can update without a page reload, but it has to handle loading states, empty results and failed requests that the server would never have shown.
Most real projects use both patterns. Product listings, dashboards and anything that filters as you type often load in the browser; marketing copy, help articles and anything search engines must read are usually rendered on the server. The interesting decisions are about which pages get which, and that decision is easier to revisit than the framework underneath it.
Deployment and what happens after launch
Once built, a site is deployed to hosting, often behind a content delivery network that serves files from locations near the visitor. That matters in a region like Southeast Asia, where round-trip times vary noticeably by country, and where a visitor in one city may be much further from the server than a visitor in another.
Dependency updates
Frameworks and libraries release fixes and breaking changes. Someone has to read the release notes and plan the upgrade before it becomes urgent.
Monitoring
Uptime checks, error reports and slow-page alerts tell the team what visitors experience, rather than what the team assumes they experience.
Fixes and small changes
Copy edits, new form fields and layout corrections continue after launch. A website is closer to a maintained service than a finished document.
That is why the delivery and handoff stage matters as much as the build itself. Documentation, access to the hosting account, and a clear list of who owns which part of the system determine how smoothly the next year goes.
Questions readers ask
Short answers to the parts of a website build that come up most often in conversation.
Do I need a framework for a small website?
Not always. A small site with a few pages can be built with plain HTML and a little JavaScript, and that is often the cheaper option. A framework starts to pay for itself when the interface has repeated components, several people editing it, or state that changes while the visitor is on the page.
Is server-side rendering always faster?
It usually helps the first view of a page, because the browser receives finished HTML instead of an empty shell. After that, the browser still runs JavaScript for anything interactive. Whether it feels faster overall depends on how much of the page needs to change after it loads, and on how close the server is to the visitor.
Can we change framework later?
Yes, but the cost grows with the size of the project. Rewriting a handful of pages is a short job; rewriting a large application usually means rebuilding screens, tests and integrations. If a framework change is likely, it is worth planning it before the codebase grows.
Does a component library replace a designer?
No. A library provides the pieces; someone still decides which piece fits the problem and how the page should read. A component library without design decisions tends to produce a site that works but does not communicate anything in particular.
Where to go next
This page covers structure and delivery in general terms. Two companion pages go deeper: one compares frameworks and platforms side by side, and one records what happens at the end of a build, when the code changes hands and the site starts being maintained.
Ask a structural question
If a specific decision is unclear, the contact page is the right place to describe the project and ask. Questions about scope, platform choice or an existing build are all reasonable to send.
ViewNeural Digital, Avenida Nueva Providencia 1800, 7500000 Providencia, Región Metropolitana, Chile. Monday to Friday, 9:00 AM – 6:00 PM.
Go to the contact page