New format
Web application: how it differs from a site and why business needs it
A web application is a program in the browser: the user doesn’t only read pages — they act: search, fill forms, buy, work in an account. Data lives on the server; the UI opens by URL.
Below: how it differs from a simple site, static vs dynamic, interface types, and typical business scenarios. This isn’t a framework-picking guide or a substitute for a development brief.
What makes a web application
Logic is split between server and browser: the server stores and calculates; the client shows the UI and takes input. The user works through a browser — without installing a thick client in most cases.
A static page is served almost the same to everyone. A dynamic one is built for the request, session, cart, or role: after login a person sees their data, not a shared showcase.
App signals:
- actions with a result (order, save, calculate)
- user state (session, cart, permissions)
- talk with the server and often external APIs
- UI reacts to input, not only shows text
The technical side without framework dogma
Browser and server can run on different OSes and languages — a web plus. What matters isn’t which framework is trendy, but contracts: API, security, response speed, clear errors.
Partial UI updates (once often called Ajax) cut needless reloads. On SPAs watch analytics and reachable URLs: otherwise counters/goals and SEO break on client-side navigation.
Types by business job
Roughly: storefronts with catalog and cart, accounts (client/staff), editors and builders, collaboration tools, embedded widgets. Boundaries blur: one product can mix several roles.
Examples:
- online store with payment and order statuses
- service personal account or B2B portal
- CRM/accounting in the browser
- online booking, calculators, estimate builders
- site admin as a separate application
When to plan an app, not “just a site”
If value is in the process (order, status, documents, roles), budget and timeline as a product: scenarios, data, integrations, rights, tests. Marketing landings stay — their structure and SEO are designed separately from a closed account.
For the public part, speed and clear URLs matter; for the account — security, action audit, and daily usability.
FAQ
Are a site and a web app the same thing?
They overlap. A brochure site is almost static. A store, browser CRM, or personal account is already an app: state, roles, operations.
Do you need desktop software?
Usually no: a browser is enough. Install a native app when you need offline, push, or deep device integration.
What is an SPA?
Single Page Application: the UI updates without a full reload. Useful for accounts; for SEO and analytics you still need correct URLs and hits.
Is Ajax required?
Not as a 2010s brand, but as an idea: load data without redrawing the whole page. Today the same is done with fetch/API and modern frameworks.
When is a landing page enough?
When the job is to explain an offer and collect a lead. If you need orders, roles, calculations, integrations — design it as an application.
Does this affect SEO?
Yes: indexable URLs, speed, SSR/prerender when needed matter. A pretty account with no public landings doesn’t deliver page-one visibility by itself.
Where should I start when buying development?
With user scenarios and roles — not the stack. Then data, integrations, access rights, and acceptance criteria.
Brief says “just a site” — but you need roles, cart, and status?
We’ll separate public landings from the product scenarios — stack after data, integrations, and acceptance criteria.
Discuss the task
