Static vs dynamic website: list your features, then decide
A static website sends every visitor the same prepared files; a dynamic one builds pages on a server for each request, usually from a database. Most small business sites are static with one or two dynamic pieces, such as a form or a booking, handled by a service. Decide by listing your features and asking of each one: does this need to remember or check something on a server?
The difference in one request
Ask a static site for /about and the server hands back a file that already exists, the same bytes for everyone. Ask a dynamic site and code runs first: it may check who you are, read a database and assemble the page before sending it. The visitor sees HTML either way. The difference is whether anything is computed per request, and therefore whether there's a server-side program to host, update and secure. That is the whole static vs dynamic website distinction.
Two things blur the line. A static page can still contain JavaScript that changes what's on screen in the browser. And a static page can send a form to a separate service that does the dynamic work. So the useful question isn't "static or dynamic?" for the whole site, but which features need a server.
Feature by feature
| Feature | Needs a server? | Why |
|---|---|---|
| Pages of text, photos, prices, menus | No | The content is the same for every visitor. |
| Contact or enquiry form | Something must receive it | A form service or a small endpoint can do this for an otherwise static site. |
| Newsletter sign-up | Something must receive it | Usually your email tool's form endpoint or a connector. |
| Booking calendar | Yes | It must know which slots are taken and stop two people booking the same one. |
| Quote calculated from inputs | In the browser or on a server | Browser maths needs JavaScript; server maths works on a page with none. |
| Taking payment | The payment provider's | A payment link sends people to the provider's hosted checkout; no server of yours is needed. |
| Customer accounts, member areas | Yes | Sign-in, sessions and per-person data all live on a server. |
| Search across many items, stock levels, live data | Yes | The answer changes and must be looked up. |
| A blog edited weekly | Not necessarily | A content system can rebuild static pages when you publish. |
Decide in five steps
- List every feature the site must have at launch, and the ones you're sure of within a year.
- Mark each one using the table: no server, a hosted service will do, or a server of your own.
- If everything is "no" or "a hosted service", build static. You'll get the cheapest hosting, the smallest attack surface and the least to maintain.
- If one or two features need a server, check whether your builder or a service provides exactly that, before taking on a whole dynamic site.
- If accounts, per-person data or custom business logic are central, plan for a dynamic application and someone to run it.
Trade-offs
- Speed
- Static files are quick to serve and easy to cache close to visitors. Dynamic pages can be fast too, but take more work.
- Security
- No server-side code means no server-side code to exploit. A dynamic app has sign-in, a database and inputs to defend.
- Cost and upkeep
- Static hosting is often free or very cheap and needs no updates. A dynamic app needs a host, a database, backups and dependency updates.
- Flexibility
- Dynamic sites can personalise, remember and compute. Static sites need outside services for anything that changes per visitor.
Where Anticode sits
Pages from Anticode's design engine are static in the strictest sense: plain HTML and CSS with no scripts at all. The dynamic pieces most small sites need are handled by Anticode's own server: contact, booking and newsletter forms are received and stored there, the booking calendar refuses taken slots, and a custom form can trigger a site function that computes a result with a formula on numbers, or makes a signed call to your own HTTPS endpoint, and shows the outcome on the thank-you page. Nothing is calculated live as the visitor types, because the page runs no scripts. Payments go through a payment link to your provider's checkout.
App builds are the other way round: interactive JavaScript in the browser, in a sandbox with no network, so data stays in the visitor's own browser and anything that would need a server is simulated and labelled. When you need real accounts, a database and your own server code, the Next.js export gives you a dynamic application with Postgres, server routes and an admin area, which you then deploy and run yourself.
Common mistakes
- Choosing a full dynamic platform for a five-page brochure site, then maintaining plugins and updates for features nobody uses.
- Building a static site and bolting on five third-party widgets, each with its own scripts, privacy terms and failure modes.
- Assuming a form needs a dynamic site. It needs something to receive it, which isn't the same thing.
- Planning for features you might want in three years. Moving later is usually cheaper than running a server you don't need now.
Questions people ask
Can a static website have a contact form?
Yes. The page is static; the form posts to a service or endpoint that receives it. That's how Anticode's forms work.
Is a static website more secure?
It has much less to attack, because there's no server-side program or database behind the pages. Forms and any services you connect still need care.
Is a static site bad for SEO?
No. Search engines read HTML; prepared pages with clear content are often easier for them than pages assembled by scripts.