Surf 
Тендеры и лиды
Информация
«Сайт» и «веб-приложение» в брифах часто идут как синонимы, а это два разных продукта с разной архитектурой, стеком и командой. Разбираем технически: где проходит граница, как выбрать способ рендеринга, что в стеке 2026 года и какие инженерные боли ждут на практике.
Половина недопониманий в веб-разработке начинается с того, что заказчик говорит «сайт», имея в виду веб-приложение, или наоборот. Разница не в словах: это развилка, из которой механически вытекают архитектура, технологии, состав команды и сроки. Сайт можно собрать на готовой CMS силами верстальщика. Веб-приложение — это софт, который пишут фронтенд- и бэкенд-инженеры, и подходы там другие.
Мы в Surf делаем веб-сервисы и приложения, и здесь разберём именно техническую сторону: чем веб-приложение отличается от сайта и какие решения из этого следуют. Проектирование интерфейса — отдельная тема, её мы разбирали в материале про дизайн; тут про инженерию. Общие этапы разработки тоже опустим — они одинаковы для любого ПО, а интересна как раз веб-специфика.
Граница проходит по одному признаку: что человек делает с продуктом. Сайт — это контент, который читают: лендинг, блог, корпоративный сайт, каталог. Пользователь потребляет информацию, а состояние между страницами почти не меняется. Веб-приложение — это инструмент, с которым работают: Gmail, Figma, Notion, Trello, дашборды, личные кабинеты, CRM. Здесь есть состояние, бизнес-логика, аккаунты и сессии, и интерфейс реагирует на действия как настольная программа.
Из этого различия тянется всё остальное. Сайту достаточно отдать готовый HTML и хорошо проиндексироваться. Веб-приложению нужно управлять состоянием на клиенте, гонять данные через API, держать авторизацию, не тормозить при сотнях интерактивных элементов и масштабироваться под нагрузку. Это другая архитектура, другой стек и другая команда. Поэтому первый честный вопрос на старте — а вам точно нужно приложение, или задача решается сайтом? Цена ошибки в обе стороны высокая: приложение, собранное как сайт, не вытянет логику, а сайт, переусложнённый до приложения, — это выброшенный бюджет.
Если продукт всё-таки приложение, центральное архитектурное решение — где собирается HTML. От него зависят скорость, SEO, сложность и стоимость инфраструктуры. Вариантов несколько, и это не «или-или», а спектр:
CSR (клиентский рендеринг, классический SPA) — сервер отдаёт почти пустую страницу и бандл JavaScript, всё рисуется в браузере. Даёт богатую интерактивность после загрузки, но первая отрисовка медленная, а с SEO исторически проблемы — поисковику нечего читать сразу.
SSR (серверный рендеринг) — HTML собирается на сервере на каждый запрос. Быстрее показывает контент и дружелюбнее к поисковикам, но нагружает сервер и усложняет инфраструктуру.
SSG (статическая генерация) — HTML генерируется заранее, на этапе сборки. Максимально быстро и дёшево, но контент статичен до следующей пересборки — подходит для редко меняющихся страниц.
ISR (инкрементальная регенерация) — гибрид: статика, которая точечно перегенерируется по таймеру или триггеру. Компромисс между скоростью SSG и свежестью SSR.
На практике эти режимы комбинируют в рамках одного продукта, и реализуют их метафреймворки: Next.js для React, Nuxt для Vue, SvelteKit для Svelte. Отдельная боль, о которой стоит знать, — гидратация: серверный HTML нужно «оживить» клиентским JavaScript, и это источник проблем (рассинхрон разметки, отложенная интерактивность). Индустрия отвечает на это частичной гидратацией и «островами» (подход Astro) и серверными компонентами React — но последние ещё дозревают, и закладывать их стоит с осторожностью.
Стек веб-приложения — это связка фронтенда, бэкенда, API и базы данных. Списки технологий есть в любой статье, поэтому интереснее не перечень, а доли и логика выбора.
На фронтенде по-прежнему доминирует React: по опросу Stack Overflow Developer Survey 2024 им пользуются около 40% разработчиков, и в State of JS 2024 он с большим отрывом лидирует по использованию. За ним идут Vue и Angular, а Svelte берёт не охватом, а лояльностью — он стабильно первый по желанию продолжать с ним работать. Среди метафреймворков самый используемый — Next.js, хотя восторгов к нему поубавилось, и растёт интерес к Remix, SvelteKit и Astro. Практический вывод простой: React — безопасный дефолт по найму и экосистеме, остальное берут под конкретные требования к скорости и команде.
На бэкенде выбор шире и зависит от задачи: Node.js удобен realtime-сценариями и единым языком с фронтом, Python хорош для API и интеграций с ML (Django с «батарейками» или асинхронный FastAPI), а под высокую нагрузку идут Go и Java. Главное помнить, где живёт бизнес-логика: в веб-приложении она на бэкенде, а клиент отвечает за состояние интерфейса и оркестрацию запросов. В базах данных мировой выбор по умолчанию — PostgreSQL (около 49% по Stack Overflow, первое место). Эти цифры — глобальный бенчмарк (выборки опросов смещены к энтузиастам), но порядок они показывают верно.
Отдельно — как клиент общается с сервером. REST остаётся дефолтом за простоту и кэшируемость; GraphQL берут, когда нужно бороться с избыточными или недостаточными запросами на сложных клиентских данных, и платят за это усложнением сервера.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13590 тендеров
проведено за восемь лет работы нашего сайта.
Прогрессивное веб-приложение (PWA) — это способ дать вебу повадки нативного приложения: установку на устройство без магазина, работу офлайн через service worker и push-уведомления. Для многих задач это позволяет обойтись одним веб-продуктом вместо отдельной мобильной разработки.
Важная оговорка про iOS, потому что именно здесь чаще всего спотыкаются. Push в PWA на iPhone поддерживается с iOS 16.4 (2023), но только если пользователь добавил приложение на домашний экран и дал разрешение. Плюс остаются ограничения по фоновой работе: надёжной фоновой синхронизации и периодических задач на iOS у веба нет. Поэтому трезвая формулировка такая: PWA отлично закрывает офлайн, установку и базовые уведомления, но если критичны стабильные пуши и фоновые процессы, для iOS нужна запасная стратегия или натив. Эти ограничения стоит проверять под актуальную версию iOS — поведение меняется от релиза к релизу.
Из PWA вытекает и более общий выбор. Веб берут, когда важны мгновенный доступ без установки, единая кодовая база на все платформы, быстрые обновления без модерации сторов и работа в первую очередь за десктопом или в смешанном сценарии. Нативное мобильное приложение оправдано, когда нужны тяжёлая работа с железом, стабильный фон и пуши, максимальная производительность графики или присутствие в App Store и Google Play как канал. Для значительной части B2B-продуктов, админок и SaaS веба достаточно, и кроссплатформенность через браузер экономит и бюджет, и команду.
Самое ценное на практике — то, что отличает зрелое веб-приложение от прототипа:
Управление состоянием. В большом SPA состояние быстро становится отдельной дисциплиной. Серверное состояние (данные с бэкенда) держат через TanStack Query или SWR, клиентское (состояние интерфейса) — через Redux, Zustand или Pinia. Смешивать их в одном хранилище — частая и дорогая ошибка.
Производительность по метрикам, а не на глаз. Google измеряет качество через Core Web Vitals: LCP (скорость показа основного контента) должен быть до 2,5 с, INP (отзывчивость на действия) — до 200 мс, CLS (стабильность вёрстки) — до 0,1. С марта 2024 года INP официально заменил прежнюю метрику FID. Эти пороги — рабочий ориентир, а не теория.
Безопасность веба. У веб-приложений своя поверхность атаки: XSS и CSRF — классика из списка OWASP. Аутентификацию строят на сессиях в httpOnly-cookie или на JWT (помня, что хранение токена в localStorage открывает его для XSS), а делегированный доступ — на OAuth 2.0 и OIDC.
Масштабирование. Когда пользователей становится много, всплывают кэширование, балансировка, вынос тяжёлых операций в фон и разделение на сервисы. Это закладывают в архитектуру заранее, а не чинят постфактум.
Сайт и веб-приложение — разные продукты: первый читают, со вторым работают; из этого вытекают архитектура, стек и команда.
Главный технический выбор — рендеринг: CSR, SSR, SSG, ISR; их комбинируют метафреймворками (Next.js, Nuxt, SvelteKit), а гидратация остаётся отдельной болью.
В стеке 2026 на фронте доминирует React, бэкенд выбирают под задачу (Node.js, Python), база по умолчанию — PostgreSQL.
PWA даёт вебу установку, офлайн и пуши, но на iOS есть ограничения по фону и уведомлениям.
Веба часто достаточно для B2B, SaaS и админок; натив берут ради железа, фона и сторов.
Зрелость приложения определяют управление состоянием, Core Web Vitals, безопасность и масштабирование, а не набор экранов.
Разработка веб-приложения начинается не с выбора фреймворка, а с честного ответа на вопрос, приложение ли это вообще. Дальше всё логично: тип продукта диктует способ рендеринга, рендеринг — стек, а стек — команду и инфраструктуру. Кто проходит эту цепочку осознанно, получает быстрый и поддерживаемый продукт. Кто берёт модный фреймворк и надеется, что архитектура сложится сама, платит за это переписыванием через год.
Владимир Макеев, генеральный директор Surf — компании по разработке цифровых продуктов и веб-сервисов для крупного и среднего бизнеса.
