Rankings do not narrow a stack choice — four questions do: what the product does, who will maintain it, where it will run and what the team already has. A content site often needs only static generation without a framework, a web app — React with Next.js or Vue, and the backend is written in Node.js, Java with Spring Boot or Python depending on the team and the task; the default database is PostgreSQL, the default API style is REST and the default architecture is a modular monolith. Below are summary “when to use what” tables with links to the detailed breakdowns.
After this you will be able to
- narrow the choice of frontend, backend and mobile stack and database for your project type to 1–2 options using the “when to use what” tables
- explain when a site does not need a framework and which Next.js features are lost with
output: 'export' - read technology popularity survey data with the sample and question wording in mind
Contents
- How to use the tables: criteria
- Website and web app: no framework, React with Next.js, or Vue
- Backend: Node.js, Java with Spring Boot, or Python
- Mobile: native, React Native, Flutter or PWA
- Databases: PostgreSQL, MySQL, NoSQL and Redis
- API and architecture: REST or GraphQL, monolith or microservices
- Hosting and deployment
- Popularity: what surveys say and how to read them
How to use the tables: criteria
This is a reference for an engineering decision: every table pairs a criterion with a “when to use what” conclusion. Detailed breakdowns with code and checks live in separate materials, linked from each section. The business side of the choice — the talent market, cost of ownership, freedom to change vendors — is covered in “Choosing a Tech Stack: A Business Perspective” (vybor-tehnologij-dlya-produkta).
- Scenario: what the product does — shows content, takes requests and payments, works offline, keeps persistent connections.
- Team: which language it already writes and who will maintain the code two years from now.
- Operations: where the app will run — static hosting, PaaS, your own server — and who is responsible for it.
- Data and integrations: what already exists — a CMS, 1C, a CRM, a live database.
- Reversibility: how much it costs to change your mind. Switching a database or architecture costs more than switching a component library.
Website and web app: no framework, React with Next.js, or Vue
The first question is whether you need a framework at all. MDN’s course on client-side frameworks warns plainly: for a portfolio of a few pages with little interactivity, a framework and all of its JavaScript may not be necessary. It also lists the alternatives: static site generators (Astro, Eleventy, Hugo), a CMS such as WordPress, and server-side rendering.
Typical tasks
- No framework or a static site generator
- Business card site, landing page, documentation, a blog without user accounts
- React + Next.js
- Web apps, dashboards, content sites with server logic
- Vue (+ Nuxt)
- The same tasks: from a widget on an existing page to an SPA and SSR
What you get as output
- No framework or a static site generator
- Ready HTML files served by any web server or CDN
- React + Next.js
- A static export (
output: 'export') or a Node.js server with SSR, Server Actions and cookies - Vue (+ Nuxt)
- A script on the page with no build step, an SPA, or SSR/SSG via Nuxt
HTML for search engines
- No framework or a static site generator
- The content is already in HTML
- React + Next.js
- SSR and SSG return ready HTML; a purely client-side SPA does not
- Vue (+ Nuxt)
- The same: SSR or SSG give HTML, a client-side SPA does not
Code on the server
- No framework or a static site generator
- None: fewer attack vectors
- React + Next.js
- Depends on the mode: with SSR your code runs on the server
- Vue (+ Nuxt)
- Depends on the mode, as with Next.js
What the team needs to know
- No framework or a static site generator
- HTML, CSS, some JavaScript and a build tool
- React + Next.js
- React, TypeScript, Next.js conventions: folder routes, server and client components
- Vue (+ Nuxt)
- Vue templates,
refandcomputed, Nuxt conventions for SSR
React itself recommends starting a new app with a framework — Next.js, React Router, or Expo for native apps; building “from scratch” with Vite is for special constraints or for learning the basics. Vue calls itself a progressive framework: you can drop it into an existing HTML page without a build step and grow it into an SPA or server rendering. Next.js can also be a static site: with output: 'export' it builds HTML during next build but loses everything that needs a server — cookies, Server Actions, rewrites and redirects, ISR.
Business card site, landing page, documentation; a developer edits the content
- Choice
- Static HTML or a static site generator
- Why
- No server code, hosting on any static server or CDN
Marketers edit the content regularly
- Choice
- A CMS (WordPress) or a headless CMS with Next.js or Nuxt
- Why
- Per MDN, a CMS suits content written by people without coding skills; the price is less control over the output
User accounts, admin panel, an app with forms and roles
- Choice
- React + Next.js or Vue + Nuxt — whichever the team knows
- Why
- Components, routing and the server side in one project
A React Native mobile app is planned
- Choice
- React + Next.js
- Why
- Shared TypeScript and component model; the UI code itself still differs
Part of an existing page needs interactivity: a calculator, a filter
- Choice
- Vue without a build step or a small script
- Why
- No need to rewrite the site for one widget
Backend: Node.js, Java with Spring Boot, or Python
All three ecosystems cover typical backend tasks: HTTP APIs, database access, authorization, background jobs. They differ in language, in how much is built in, and in how much structure the framework imposes on its own.
Language
- Node.js: Express / NestJS
- JavaScript or TypeScript — the same as on the frontend
- Java: Spring Boot
- Java (or Kotlin), static typing
- Python: FastAPI / Django
- Python; FastAPI uses type hints for validation
How much structure the framework sets
- Node.js: Express / NestJS
- Express is minimal and unopinionated; NestJS brings modules, controllers, services and dependency injection
- Java: Spring Boot
- A lot: starters, auto-configuration, controller — service — repository layers
- Python: FastAPI / Django
- FastAPI: routes, validation and
Depends, the rest is your choice; Django: the most out of the box
What is included
- Node.js: Express / NestJS
- Express: routing and middleware; an ORM, validation and API docs are added separately
- Java: Spring Boot
- Embedded server, metrics and health checks, externalized configuration; data via Spring Data
- Python: FastAPI / Django
- FastAPI: OpenAPI and docs at
/docs, no ORM or admin; Django: ORM, migrations, admin, authentication, CSRF protection
Strength
- Node.js: Express / NestJS
- One language across the stack, types shared with the frontend
- Java: Spring Boot
- Predictable structure for large, long-lived systems, ready operational tooling
- Python: FastAPI / Django
- FastAPI: a quick API start with a contract from types; Django: sites and internal systems with an admin
Cost
- Node.js: Express / NestJS
- In Express the team holds the architecture; NestJS requires learning decorators and DI
- Java: Spring Boot
- For a small service — more concepts and configuration up front than needed
- Python: FastAPI / Django
- FastAPI makes you assemble the stack, Django makes you follow its conventions
The team writes the frontend in TypeScript and needs an API for its own web and mobile clients
- Choice
- Node.js: NestJS for structure, Express for a small service
- Why
- One language and shared types across the stack
A large, long-lived system; the company has Java expertise
- Choice
- Spring Boot
- Why
- Strict structure and production-ready features out of the box
An internal system with many reference tables and data editors
- Choice
- Django
- Why
- Admin, ORM and migrations are ready from day one
An API next to Python code: data analysis, ML, scripts
- Choice
- FastAPI
- Why
- One language with the rest of the code, API docs from types
A small service, a webhook, an integration adapter
- Choice
- Express or FastAPI
- Why
- Minimal code and dependencies
Lessons for each stack: “What backend is” (chto-takoe-backend), “REST API on Express” (express-rest-api), “NestJS: modules, controllers, services and DTOs” (nestjs-vvedenie), “Spring Boot: a REST API from scratch” (spring-boot-rest-api), “FastAPI: a Python API” (python-fastapi), “Django: models, admin and views” (django-vvedenie).
Mobile: native, React Native, Flutter or PWA
A detailed comparison with examples and a decision tree is in “Mobile development: native, React Native or Flutter” (mobilnaya-razrabotka-osnovy). Here is the summary for a first filter.
PWA
- When to choose
- The scenario fits within browser capabilities, store distribution is not required
- What to consider
- One codebase with the website; access to device APIs and background work depends on browser support on each platform
Native: Kotlin + Compose, Swift + SwiftUI
- When to choose
- You need new system APIs right after release and UI that strictly follows platform rules
- What to consider
- Two apps and two languages: every feature is built twice
React Native + Expo
- When to choose
- The team knows React and TypeScript, one codebase for Android and iOS is needed
- What to consider
- No DOM and no CSS cascade; native knowledge is still needed for builds and signing
Flutter
- When to choose
- You need the same branded UI on every platform and the team is ready for Dart
- What to consider
- Its own rendering: native behavior of controls has to be reproduced
Databases: PostgreSQL, MySQL, NoSQL and Redis
PostgreSQL
- When to use what
- The default for a new product: strict types, transactional migrations,
jsonb, PostGIS and pgvector extensions - Details
postgresql-ili-mysql
MySQL
- When to use what
- The platform requires it (for example, WordPress) or the team and hosting already run it with experience and monitoring
- Details
postgresql-ili-mysql
jsonb in PostgreSQL
- When to use what
- Almost everything is relational and only part must be flexible — for example, product attributes
- Details
nosql-kogda-nuzhen
Document database (MongoDB)
- When to use what
- An object is read and changed as a whole, few relations: content, questionnaires, settings
- Details
nosql-kogda-nuzhen
Redis
- When to use what
- Next to the main database: cache, sessions, counters, rate limits
- Details
redis-keshirovanie
Wide-column and graph (Cassandra, Neo4j)
- When to use what
- A very large write stream across many servers, or traversing relations of arbitrary depth
- Details
nosql-kogda-nuzhen
API and architecture: REST or GraphQL, monolith or microservices
Public API, webhooks, exchange with 1C and CRMs, files
- API style
- REST
- Why
- Understood by any HTTP client, cached by URL, errors visible in status codes
Several clients with different screens over related data
- API style
- GraphQL
- Why
- Each client takes its own fields in one request; the price is depth and cost limits on the server
Communication between internal services, streams, low latency
- API style
- gRPC
- Why
- Binary format, code generation, streaming calls
Full-stack TypeScript, one team, one repository
- API style
- tRPC
- Why
- Client types are inferred from the server without a schema
A new product whose domain boundaries are still shifting
- Architecture
- Modular monolith
- Why
- One deployment, transactions across modules, boundaries checked automatically
Several teams get in each other’s way at release time
- Architecture
- Strict module boundaries, then extracting one service at a time
- Why
- First make sure it is deployment that hurts, not code coupling
Part of the system needs different load, availability or security
- Architecture
- Extract that part into a service
- Why
- Splitting by characteristics is a technical argument for a service
No automated deployment, monitoring or tracing
- Architecture
- Do not start with microservices
- Why
- The cost of distribution will exceed the benefit
API styles with caching, errors and security are compared in “REST or GraphQL” (rest-ili-graphql), with practice in “GraphQL: schema, queries and mutations” (graphql-osnovy). The reasoning and a modular monolith in code are in “Modular monolith or microservices” (modulnyj-monolit-ili-mikroservisy).
Hosting and deployment
Static hosting or a CDN
- When it fits
- A site without server code: a static site generator or a Next.js static export
- What stays with the team
- Build, domain, caching rules
PaaS: Vercel, Render, Fly.io
- When it fits
- A small team, a standard stack, preview environments per branch are needed
- What stays with the team
- Code, environment variables, migrations, fitting into platform limits
VPS
- When it fits
- Full control, non-standard software, long-running processes, or data that must stay in a specific country
- What stays with the team
- OS and updates, firewall, Nginx and HTTPS, backups, monitoring, a rollout script
Containers and Kubernetes
- When it fits
- Many services and instances, and an engineer who owns the platform
- What stays with the team
- A cluster or a managed service, manifests, networking, observability
Popularity: what surveys say and how to read them
How widespread a technology is says something about the talent market, not about quality. The only source of numbers in this reference is the Stack Overflow Developer Survey 2026: 30,903 responses from 169 countries. The question is “which technologies have you done extensive development work in over the past year”; several options can be selected, so the shares add up to more than 100%.
Node.js
- Share of respondents
- 46.4%
- Survey section
- Web frameworks and technologies (n = 10,281)
React
- Share of respondents
- 41.5%
- Survey section
- Web frameworks and technologies (n = 10,281)
Next.js
- Share of respondents
- 20.6%
- Survey section
- Web frameworks and technologies (n = 10,281)
FastAPI
- Share of respondents
- 18.5%
- Survey section
- Web frameworks and technologies (n = 10,281)
Vue.js
- Share of respondents
- 17.2%
- Survey section
- Web frameworks and technologies (n = 10,281)
Express
- Share of respondents
- 15.6%
- Survey section
- Web frameworks and technologies (n = 10,281)
Spring Boot
- Share of respondents
- 12.8%
- Survey section
- Web frameworks and technologies (n = 10,281)
Django
- Share of respondents
- 11.3%
- Survey section
- Web frameworks and technologies (n = 10,281)
NestJS
- Share of respondents
- 5.8%
- Survey section
- Web frameworks and technologies (n = 10,281)
PostgreSQL
- Share of respondents
- 57.9%
- Survey section
- Databases (n = 12,061)
MySQL
- Share of respondents
- 35.1%
- Survey section
- Databases (n = 12,061)
Redis
- Share of respondents
- 28.3%
- Survey section
- Databases (n = 12,061)
MongoDB
- Share of respondents
- 19.0%
- Survey section
- Databases (n = 12,061)
- The sample is the Stack Overflow audience that took the survey, not all developers and not the market of a particular city.
- The survey measures usage, not fitness: a technology with a smaller share can be the better choice for your scenario.
- React Native and Flutter are not among the options of these questions — for mobile, rely on the criteria in the section above.
- For hiring, look at job postings and resumes in your region — the business article on choosing technologies advises the same.
