Что такое веб-приложение: как устроено, виды и на чём делают

Открой сейчас почту или заметки в браузере. Ты уже внутри веб-приложения, просто никогда об этом не думал. Веб-приложение это программа, которая работает прямо в браузере, без скачивания и установки: открыл вкладку и сразу пользуешься полноценным софтом. Ты не просто читаешь готовый текст, как в газете, а действуешь. Пишешь письмо, двигаешь задачи в доске, собираешь заказ в корзине, редактируешь документ, который тут же сохраняется. Вот что такое веб-приложение, если объяснять простыми словами: софт, который живёт по ссылке, а не в папке на диске.

Меня зовут Евгений Волков, я fullstack-разработчик, и веб-приложения это ровно то, что я делаю руками каждый день. Поэтому дальше не сухое определение из учебника, а разбор от практика: чем веб-приложение честно отличается от обычного сайта, как оно устроено под капотом, какие бывают виды, на чём их собирают и как всё это выглядит на живых примерах. В конце отвечу на частые вопросы, которые люди реально гуглят перед тем, как заказать разработку.

Кратко: веб-приложение в двух абзацах

Если нужно понять суть за минуту, вот она. Сайт доставляет тебе контент, ты его читаешь. Веб-приложение это софт в браузере, ты в нём создаёшь и меняешь данные под своим аккаунтом. Между ними спектр, а не стена: чем больше ты действуешь, а не просто читаешь, тем это ближе к приложению.

Работает всё по клиент-серверной схеме: браузер отправляет запрос, сервер его обрабатывает, лезет в базу данных и возвращает ответ. Собирают приложение из слоёв: фронтенд (интерфейс), бэкенд (логика), база данных, API между ними и хостинг. Ниже раскрою каждый пункт по-человечески.

Чем веб-приложение отличается от сайта

Это главный вопрос, который люди задают, и по нему в выдаче гуляет много путаницы. Встречал объяснения вроде «сайт работает только на компьютере, а приложение везде» или «в приложении обязательно есть вход по логину». Это неправда. Сайт прекрасно открывается на телефоне, а половина сайтов вообще не требует регистрации. Дело совсем в другом.

Настоящая граница проходит по тому, что ты делаешь. Сайт это про доставку контента. Кто-то один раз написал текст, а сайт показывает его всем посетителям: ты пришёл, прочитал статью, посмотрел цены, ушёл. Ты потребитель готовой информации. Классический сайт это блог, лендинг, визитка компании, новостной портал.

Веб-приложение это про действие над данными. Ты не читаешь чужой готовый контент, ты создаёшь и меняешь свой. Написал письмо, оно ушло и сохранилось. Перетащил карточку задачи, состояние доски обновилось. Добавил товар в корзину, оформил, оплатил. Приложение приняло твои действия, что-то посчитало, записало в базу и показало результат. Ты соавтор, а не зритель.

Если убрать философию, вот технические маркеры, по которым инженер отличает одно от другого:

• Состояние и рендеринг на клиенте. У приложения есть живое состояние прямо в браузере: что открыто, что выбрано, что ты набрал но ещё не отправил. Интерфейс перерисовывается на лету, без перезагрузки страницы.
• Бизнес-логика и работа с данными. Внутри крутится логика: посчитать цену со скидкой, проверить остаток на складе, собрать отчёт. Это классический CRUD, четыре операции над данными: создать, прочитать, обновить, удалить.
• База данных. У приложения есть где хранить твои данные между визитами. Закрыл вкладку, вернулся завтра, всё на месте.
• Аккаунты и сессии как ядро. Приложение помнит, кто ты, и показывает именно твои данные, а не общие для всех. Это не украшение, а основа: у каждого пользователя своё пространство.
• API-слой. Интерфейс в браузере и логика на сервере общаются через API. Нажал кнопку, браузер тихо сходил на сервер, получил данные, обновил экран.
• Сборка и бандлинг при деплое. Код приложения перед выкладкой проходит сборку: собирается в оптимизированные файлы, режется на части, минифицируется. У простого сайта этого этапа может и не быть.

Теперь честно про размытость. Чёткой стены между сайтом и приложением нет, есть спектр. Блог, к которому прикрутили форму комментариев, это ещё сайт, но уже с щепоткой интерактива. Интернет-магазин с корзиной, аккаунтом и оплатой это уже полноценное веб-приложение, хотя по привычке его называют сайтом. Правило, которым пользуюсь я: если пользователь в основном читает, это сайт; если создаёт, меняет и обрабатывает данные, это веб-приложение.

Сведу разницу в таблицу, так нагляднее.

Как веб-приложение работает под капотом

Тут пугаться нечего, схема простая, и её стоит понять, чтобы дальше говорить с разработчиком на одном языке. В основе лежит клиент-серверная архитектура. Звучит сложно, а по сути это диалог двух сторон.

Клиент это твой браузер. Он показывает интерфейс и принимает твои действия. Сервер это чужой компьютер где-то в дата-центре, который хранит данные и знает всю логику. Между ними бегают запросы и ответы. Разберём на живом сценарии.

Ты открыл онлайн-магазин и нажал «добавить в корзину». Дальше происходит вот что. Браузер (клиент) формирует запрос и через API отправляет его на сервер: мол, пользователь такой-то хочет положить в корзину товар номер такой-то. Сервер принимает запрос, проверяет, что товар есть на складе, обращается к базе данных, записывает туда изменение корзины и отправляет обратно ответ: готово, в корзине теперь три позиции на такую-то сумму. Браузер получает ответ и обновляет циферку корзины у тебя на экране. Всё это занимает доли секунды, и ты видишь только результат.

Ключевая идея: логика и данные разложены по двум сторонам, и делят их не случайно.

Клиентская сторона (то, что в браузере) отвечает за интерфейс и за то, что ты видишь и трогаешь: кнопки, формы, анимации, мгновенная реакция на клик, временное состояние страницы. Запрос «клиентская сторона веб-приложения» люди ищут не просто так: именно тут живёт весь видимый интерактив. Но клиенту нельзя доверять важное. Браузер у пользователя, и теоретически туда можно залезть и подменить данные.

Серверная сторона отвечает за то, что должно быть надёжным и защищённым: основную бизнес-логику, проверку прав, работу с базой, оплату, всё, что нельзя отдавать на откуп браузеру. Цену заказа считает сервер, а не клиент, иначе любой хитрец поставил бы себе скидку 99%. Проверку «а можно ли этому пользователю удалять чужие записи» тоже делает сервер.

Вот это разделение и есть скелет любого веб-приложения. Интерфейс отдельно, логика и данные отдельно, между ними API как посредник. Понимаешь эту схему, понимаешь, почему приложение это не «просто красивый сайт», а система из нескольких частей.

Виды веб-приложений

Дальше самое интересное и то, что почти все обходят стороной. Веб-приложения бывают разными по тому, как они собирают и отдают страницы. От этого зависит скорость, удобство разработки и то, насколько дружелюбно приложение к поисковикам. Разберу основные виды по-человечески, с плюсами, минусами и с примерами, когда что брать. Имена фреймворков назову честно, а не спрячу за общими словами.

MPA (многостраничное приложение)

Классика, с которой начинался веб. MPA (multi-page application) это когда каждая страница отдельная, и на любой переход браузер идёт на сервер за новой страницей. Кликнул ссылку, страница перезагрузилась целиком, пришёл свежий HTML. Так работает большинство обычных сайтов и старых интернет-магазинов.

Когда брать: контентные сайты, блоги, каталоги, лендинги, всё, где главное это тексты и картинки, а не сложные действия.

SPA (одностраничное приложение)

Противоположность MPA. SPA (single-page application) грузит один HTML-каркас один раз, а дальше живёт целиком в браузере. Переходы между «страницами» рисует JavaScript на лету, без перезагрузок. Ощущается как настоящее приложение: кликаешь, и всё меняется мгновенно, без белого экрана. На SPA сделаны почтовые клиенты, таск-трекеры, дашборды, редакторы. Пишут их обычно на React, Vue или Angular.

Когда брать: приложения за логином, где SEO не важно, а важен богатый интерактив. Внутренние системы, админки, кабинеты.

SSR (серверный рендеринг)

Золотая середина между MPA и SPA. SSR (server-side rendering) это когда сервер сам собирает готовую HTML-страницу с контентом и отдаёт браузеру, а уже потом JavaScript «оживляет» её и превращает в живое приложение без перезагрузок. Пользователь и поисковик видят контент сразу, а дальше получают всю плавность SPA. Так работают современные фреймворки Nuxt (для Vue) и Next.js (для React). Мой основной рабочий инструмент это как раз Nuxt.

Когда брать: почти всё, где нужны и скорость с SEO, и живой интерфейс. Магазины, маркетплейсы, публичные части сервисов.

SSG и ISR (статика и её обновление)

Ещё быстрее. SSG (static site generation) это когда все страницы собираются заранее, один раз при сборке, в готовые HTML-файлы. Дальше их раздаёт хоть простой файловый сервер, хоть CDN, и это самое быстрое, что бывает: рендерить на лету нечего, ломаться нечему. Сам evolkov.tech собран именно так, через nuxt generate, поэтому грузится мгновенно.

Минус статики в том, что при изменении контента надо пересобирать. На тысяче страниц это долго. Тут выручает ISR (incremental static regeneration): страницы статические, но сервер умеет пересобирать отдельные из них по расписанию или по запросу, не трогая остальные. Свежесть почти как у SSR, скорость почти как у SSG.

Когда брать: блоги, документация, лендинги, витрины, контентные проекты. ISR: большие каталоги, где нужна и скорость, и относительная свежесть.

PWA (устанавливаемое приложение)

Особняком стоит PWA (progressive web app). Это не столько отдельный способ рендеринга, сколько надстройка, которая превращает веб-приложение почти в нативное. PWA можно установить на телефон или компьютер прямо из браузера, без магазина приложений, у него появляется своя иконка на экране. За счёт технологии service worker оно частично работает офлайн, кеширует данные и умеет присылать push-уведомления.

Когда брать: когда нативное приложение делать дорого, а веб хочется сделать удобнее, ближе к телефону и с офлайном.

Важная оговорка про честность. В реальной разработке эти виды давно не чистые. Современный Nuxt или Next.js смешивает режимы прямо по страницам: главная и каталог статикой или через SSR ради скорости и SEO, а личный кабинет как SPA ради интерактива. Это называется гибридный рендеринг, и на практике так и делают. Не «выбираем одно на всё приложение», а подбираем режим под каждую часть.

И вот тут прямая связь со скоростью. Выбор вида напрямую бьёт по тому, как быстро появляется первый экран, а значит и по Core Web Vitals, и по позициям в поиске. Ниже собрал виды в таблицу по этим параметрам. А как именно чинить скорость, я подробно разобрал в отдельной статье, как ускорить сайт: там про DevTools, бандл и архитектуру рендеринга по шагам. Тут я не переучиваю оптимизацию, тут про то, что это за виды и когда какой брать.

На чём делают веб-приложения

Ещё один вопрос, который почти везде замазан парой баззвордов вроде «HTML, CSS, JavaScript и всё». На деле веб-приложение это не один язык, а несколько слоёв, у каждого своя задача и свои инструменты. Разберу стек по-честному, как fullstack-разработчик, который работает со всеми слоями сразу.

Фронтенд: интерфейс в браузере

Фронтенд это всё, что пользователь видит и трогает. Основа тут это три вещи: HTML (структура), CSS (внешний вид), JavaScript (поведение). Но на голом JavaScript большое приложение писать больно, поэтому берут фреймворки. Три главных это React (от Meta, самый популярный), Vue (гибкий и приятный, мой любимый) и Angular (тяжёлый, чаще в корпоративных системах).

Поверх фреймворков ставят мета-фреймворки, которые добавляют серверный рендеринг, маршрутизацию и сборку из коробки: Nuxt для Vue и Next.js для React. Именно они дают тот самый SSR и гибридный рендеринг, о которых шла речь выше. Мой основной стек это Nuxt/Vue, а под проекты на React я беру Next.js.

Бэкенд: логика на сервере

Бэкенд это мозг приложения, невидимая часть на сервере. Он обрабатывает запросы, крутит бизнес-логику, ходит в базу, проверяет права, считает и решает. Языков и платформ тут много. Node.js позволяет писать бэкенд на том же JavaScript, что и фронт, и это удобно fullstack-разработчику: один язык на весь стек. Python любят за читаемость и за силу в данных и в ML. PHP до сих пор держит огромную долю веба (на нём, например, WordPress). Есть ещё Go, Java, C#, у каждого своя ниша.

База данных: где живут данные

База данных это память приложения. Тут хранятся пользователи, заказы, тексты, всё, что должно пережить перезагрузку. Условно делятся на два лагеря. Реляционные (SQL) хранят данные строгими таблицами со связями: PostgreSQL (мощная, моя основная) и MySQL (проверенная классика). Нереляционные (NoSQL) вроде MongoDB гибче по структуре. Отдельно стоит упомянуть Supabase: это готовая обвязка вокруг PostgreSQL, которая сразу даёт базу, авторизацию и API, и здорово ускоряет старт проекта.

API: связь между фронтом и бэком

API это язык, на котором интерфейс договаривается с сервером. Фронт не лезет в базу напрямую, он вежливо спрашивает у бэкенда через API: дай мне заказы этого пользователя, сохрани вот это. Два главных стиля: REST (простой, на обычных HTTP-запросах, самый распространённый) и GraphQL (клиент сам описывает, какие именно поля ему нужны, удобно для сложных данных). Без API-слоя фронт и бэк это две несвязанные половины.

Хостинг и деплой: где всё это живёт

Готовое приложение должно где-то работать и быть доступным по адресу. Хостинг это сервер, на котором приложение крутится: обычная VPS, облако вроде Vercel или Cloudflare, свой физический сервер. Деплой это процесс выкладки кода на этот сервер: собрали проект, отправили на хостинг, он стал доступен пользователям. Сюда же относятся домен, HTTPS-сертификат и автоматизация через CI/CD, чтобы каждое обновление выкатывалось без ручной возни.

Соберу всё в таблицу, чтобы стек читался одним взглядом.

Честно про мой стек, чтобы не звучало как реклама всего сразу. Я работаю на связке Nuxt/Vue и React/Next на фронте, Node.js на бэке, PostgreSQL или Supabase под данные. Это не единственно верный набор, у Python и PHP свои сильные стороны. Но именно этот стек даёт быстрый SSR, единый язык на весь проект и понятный путь от прототипа до нагруженного продакшена. Подробнее про то, как я собираю такие проекты под ключ, есть на странице разработки веб-приложений.

Примеры веб-приложений

Теория укладывается в голове, когда видишь её на знакомых продуктах. Ты пользуешься веб-приложениями каждый день, просто не вешал на них ярлык. Пройдусь по категориям.

• Почта. Gmail, Яндекс.Почта. Открыл в браузере, пишешь, отправляешь, всё хранится в твоём аккаунте. Чистое веб-приложение.
• Документы и таблицы. Google Docs, онлайн-редакторы. Несколько человек правят один документ в реальном времени, и это работает прямо во вкладке.
• Мессенджеры. Telegram Web, WhatsApp Web. Тот же чат, что в мобильном приложении, но в браузере.
• Таск-трекеры и доски. Trello, канбан-доски, где карточки перетаскиваешь мышкой, а состояние сохраняется.
• CRM и ERP. Системы для бизнеса: клиенты, сделки, склад, аналитика. Внутренний софт компаний, почти всегда веб-приложение за логином.
• Интернет-магазины. Каталог, корзина, аккаунт, оплата, история заказов. По сути это тоже веб-приложение, просто с публичной витриной.
• Онлайн-банки и кабинеты. Личный кабинет банка, оператора связи, госуслуг. Работа с твоими данными и деньгами прямо в браузере.
• Конфигураторы товаров. Настраиваешь продукт под себя прямо на странице: цвет, комплектацию, надпись, и видишь результат сразу.

На последней категории остановлюсь, потому что тут у меня есть живой собственный пример, а не абстрактный Netflix, которым иллюстрируют все подряд. Я делал STAN это интерактивный 3D-конфигуратор мерча для бренда одежды. Прямо в браузере менеджер или клиент выбирает изделие (кепку, футболку, худи), перекрашивает детали в любой цвет, накладывает логотип и текст, крутит 3D-модель на 360°, а потом сохраняет конфигурацию, делится ссылкой на согласование и выгружает производственное задание в PDF для цеха.

Это стопроцентное веб-приложение по всем маркерам из начала статьи: живое состояние в браузере, реальная логика, работа с данными, действие вместо чтения. Технически 3D рендерит Three.js поверх WebGL, сцена описана через React Three Fiber, состояние держит Zustand, а PDF собирает jsPDF на лету из текущей конфигурации. Главная инженерная боль таких проектов это вес 3D-моделей: тяжёлый файл убивает загрузку на телефоне. Я прогонял модели через glTF-transform и meshoptimizer, чтобы сцена стартовала быстро даже на мобильном. Полный разбор с деталями стека и функционала есть в кейсе 3D-конфигуратора. Это к тому, что веб-приложение это не обязательно скучная таблица, в браузере сегодня живёт и полноценная 3D-графика.

Веб-приложение, мобильное или PWA: что выбрать

Частый развилочный вопрос перед стартом проекта: делать веб, нативное мобильное приложение или PWA. Короткий честный разбор без фанатизма, потому что серебряной пули тут нет.

Веб-приложение открывается по ссылке в любом браузере, ставить ничего не надо, обновляется мгновенно у всех сразу, и оно одно на все платформы. Дешевле и быстрее в запуске. Слабее в доступе к железу телефона и в тяжёлой графике.

Нативное мобильное приложение ты скачиваешь из App Store или Google Play. Оно лучше всех работает с камерой, датчиками, фоновыми уведомлениями, даёт максимум производительности. Плата: под каждую платформу часто отдельная разработка, обновления идут через модерацию магазина, и пользователя ещё надо уговорить установить.

PWA это компромисс между ними. Тот же веб, но с иконкой на экране, офлайном и push. Не даёт всей мощи нативного, зато одно на всё и без магазина.

Как я это решаю на практике. Если продукт про контент, работу с данными и охват максимума людей без барьеров, начинаю с веб-приложения, при желании усиливаю до PWA. Если ядро продукта это камера, карты, офлайн-навигация или тяжёлая графика в фоне, тогда нативное оправдано. Очень часто разумный путь такой: сначала веб или PWA, чтобы быстро проверить идею и собрать аудиторию, а нативное приложение уже потом, когда понятно, что оно реально нужно.

Ограничения веб-приложений, о которых честно стоит знать

Раз статья от практика, будет нечестно рисовать только плюсы. У веб-приложений есть слабые места, и понимать их полезно до старта, а не после.

Зависимость от сети. Веб-приложение по природе живёт в связке с сервером. Пропал интернет, и без специальных ухищрений вроде PWA-кеша большая часть функций отваливается. Нативное приложение переживёт офлайн легче.

Безопасность на клиенте. Помнишь тезис про то, что браузеру нельзя доверять важное. Это ограничение по дизайну. Весь клиентский код виден пользователю, его можно изучить и попытаться обмануть. Поэтому любую проверку, которая что-то решает (цена, права, доступ), обязательно дублируют на сервере. Инженер, который выносит критичную логику на клиент, закладывает дыру.

SEO у чистого SPA. Одностраничное приложение отдаёт поисковику пустой каркас, а контент дорисовывает скриптом. Робот это не всегда переваривает, и страница может не попасть в индекс как надо. Решается через SSR или пререндер, но это отдельная работа, а не бесплатный бонус. Тему индексации и скорости я подробнее раскрывал в разборе про ускорение сайта.

Производительность на слабых устройствах. Чем больше логики в браузере, тем тяжелее приложению на дешёвом телефоне. То, что летает на твоём ноутбуке, может подтормаживать у реального пользователя с бюджетным Android. Это не повод отказываться от веба, это повод не забывать про оптимизацию.

Теперь про сильные стороны, которые вытекают из той же архитектуры и часто перевешивают минусы. Обновляемость: выкатил новую версию на сервер, и она мгновенно у всех, без установки и модерации магазина. Кроссплатформенность: одно приложение открывается на любом устройстве с браузером. Масштабируемость: серверную часть можно наращивать под нагрузку отдельно от клиента. Интеграции: через API веб-приложение легко сшивается с CRM, оплатой, доставкой, внешними сервисами. Именно за этот набор веб и стал стандартом для большинства бизнес-задач.

Сколько стоит и как заказать веб-приложение

Про цену коротко и честно, без выдуманных цифр. Универсального прайса на веб-приложение нет и быть не может, потому что под этим словом прячется и простой личный кабинет на пару экранов, и целая CRM с ролями, интеграциями и аналитикой. Это как спросить «сколько стоит машина»: смотря какая.

От чего реально зависит стоимость:

• Объём логики и число сценариев. Один поток «зашёл, заполнил, отправил» или десяток ролей со своими правами и путями.
• Виды и сложность интерфейса. Простая форма или насыщенный дашборд с графиками и 3D.
• Интеграции. Оплата, доставка, 1С, CRM, внешние API. Каждая связка это работа.
• Данные и нагрузка. Сотня записей или миллионы, десять пользователей или десять тысяч разом.
• Модель рендеринга. SPA, SSR или гибрид под задачу, о чём говорили выше.

У меня разработка веб-приложения стартует от 100 000 ₽, а точную вилку я называю после короткого брифа, когда становится ясно, что именно надо строить. Я не считаю правильным пугать заказчика с порога большой цифрой или, наоборот, обещать «приложение за 20 тысяч», зная, что за эти деньги выйдет пустышка. Сначала разберёмся, что за задача, потом честная оценка.

Если думаешь о своём проекте и хочешь понять, реально ли его собрать и во что примерно обойдётся, напиши мне про задачу. Расскажу прямо, что твоя идея это отдельное приложение или достаточно доработать существующий сайт, и с чего дешевле начать.