Я открываю старый проект 2020 года и вижу знакомые имена в package.json: create-react-app, enzyme, moment.js, axios. Пять лет назад это был золотой стандарт. Сегодня же эти технологии вызывают у коллег искреннее недоумение: «Зачем это тут?»
А ведь прошло всего пять лет.
И за эти 5 лет изменилось очень многое: SPA переживает упадок, TypeScript стал обязательным стандартом, роль фронтенд-разработчика расширяется до full-stack. А дальше что, браузеры заменят фреймворки?
Ментальная модель фронтендера 2020 года
Пять лет назад типичный стек выглядел так:
// package.json 2020
{
"dependencies": {
"react": "^17.0.0",
"react-dom": "^17.0.0",
"redux": "^4.0.0",
"react-redux": "^7.0.0",
"axios": "^0.21.0",
"styled-components": "^5.0.0",
"moment": "^2.29.0"
},
"devDependencies": {
"@testing-library/react": "^11.0.0",
"enzyme": "^3.11.0",
"webpack": "^4.44.0",
"babel": "^7.12.0",
"eslint": "^7.15.0",
"prettier": "^2.2.0"
}
}Ключевые характеристики эпохи:
React как безусловный лидер — альтернативы рассматривались только для нишевых задач.
Парадигма SPA (Single Page Application) как догма — всё должно быть одностраничным приложением.
Runtime-решения — CSS-in-JS, клиентский рендеринг, динамические импорты.
С��ожность как признак профессионализма — умение настроить Webpack считалось продвинутым навыком.
JavaScript-центричность — всё решается кодом, HTML и CSS как второстепенные технологии.
Боли, которые мы терпели:
Сборка проекта занимала минуты.
«Гидратационные скачки» при загрузке SPA.
Необходимость постоянно думать об оптимизации ререндеров.
Раздутые бандлы на мобильных устройствах.
Что у нас есть в 2026? Прагматизм
Давайте посмотрим на список мертвых фреймворков.
Пять лет назад мы читали статьи «Почему вам стоит использовать Babel», а в 2026 Babel занимает 121-е место среди библиотек JavaScript, имеет 0,2% доли рынка JavaScript-библиотек.
Webpack. В 2020 — единственный серьёзный вариант. В 2025 — это уже legacy, а на его место пришел Vite.
Помните Create React App (2016-2024) — стандарт для начала React-проектов? Не успел он за трендами — медленная сборка, устарел, не обновлялся — был заменен на Vite для простых проектов, Next.js/Remix для full-stack.
Moment.js (2011-2024) — стандарт для работы с датами — проиграл гонку из-за размеров (огромный бандл, mutable API) и превратился в легаси: шутки ли 67.6KB vs 13.1KB у date-fns (с tree shaking). Заменён на date-fns, day.js, Temporal API.
Про jQuery — в 2025 используется на 78.3% сайтов (легаси) и в 0.2% новых проектов. Почему? Технология (или фреймворк?) мертва, а в банках и госкомпаниях пока работает благодаря принципу «Работает — не трогай».
Может показаться, что я выдернул из общего потока несколько технологий и фреймворков и зачем-то делаюсь их некрологами. Однако у меня есть статистика выживаем��сти на основе 217 фреймворков:
Фреймворки общего назначения: 15% выжили.
Специализированные фреймворки: 32% выжили.
Мета-фреймворки (Next.js и аналоги): 45% выжили.
У тех, кто «умер» (а это 87 фреймворков), причина смерти была такова:
Причина | % случаев | Пример |
|---|---|---|
Уступил в производительности | 34% | Ember vs React |
Слишком сложный DX | 28% | AngularJS 1.x |
Нет сильного спонсора | 18% | Aurelia |
Узкая специализация | 12% | Фреймворки только для charts |
Архитектурные ошибки | 8% | Изначально плохой дизайн |
Этой статистикой я хочу сказать, что технологии не умирают просто так. Они уступают место тем, что лучше решает актуальные проблемы. А в 2026 наши проблемы решает следующий список.
1. Server-Side Rendering (SSR) и Static Site Generation (SSG) переживают ренессанс
Если в 2020 году о них говорили в основном в контексте нишевых фреймворков, то сегодня, по данным State of JS 2024, более 40% разработчиков используют или планируют использовать решения с SSR/SSG. Это не мода, а прагматичный ответ на требования производительности и SEO, которые стали критичными для бизнеса.
Яркое проявление тренда — взлёт HTMX. Его философия «возврата гипермедиа» — это логичное развитие идеи SSR. Зачем гонять тяжёлые JS-бандлы для обновления контента, если браузер может просто заменить часть HTML, полученную с сервера? За 3 года еженедельные загрузки HTMX выросли с 12K до 1.8M. Он идеально ложится на задачи, где SPA — это overkill: админки, внутренние инструменты, MVP.
2. Сдвиг логики на этап сборки (компиляции)
Суть тренда в том, чтобы перенести как можно больше работы из браузера (runtime) в инструменты сборки. Речь не о компиляции JS в машинный код, а о предварительной обработке: оптимизация изображений, генерация CSS из конфигов (как в Tailwind), статический анализ и tree-shaking, server-side рендеринг компонентов. Итог один: браузер получает уже готовый, минимальный и оптимизированный код, что напрямую улучшает скорость загрузки.
3. TypeScript (почти) обязательный стандарт
TypeScript это уже не навык в списке «Будет плюсом», а ожидаемый минимум для production-проектов. Стандарт не навязан сверху, а родился сам собой — как выбор сообщества. Такой консенсус сложился потому, что TypeScript решает конкретные бизнес-задачи: снижает количество runtime-ошибок, ускоряет онбординг новых разработчиков и упрощает поддержку больших кодовых баз.
4. Производительность как KPI.
Скорость загрузки, отзывчивость и стабильность интерфейса перестали быть просто «техническими метриками». Теперь они напрямую влияют на бизнес-показатели — конверсию, удержание пользователей и ранжирование в поиске. Компании ставят конкретные цели по времени загрузки (LCP), задержкам ввода (INP) и визуальной стабильности (CLS), превращая производительность из задачи для энтузиастов в измеримый и обязательный KPI для всей команды разработки.
5. Теперь мы все full-stack
Согласно опросу Stack Overflow Developer Survey 2024, более 55% разработчиков, идентифицирующих себя как «Frontend», также регулярно работают с бэкендом (API, базы данных). Этот тренд подпитывается фреймворками вроде Next.js (React), Nuxt (Vue) и SvelteKit, которые предлагают единую модель для всего приложения. Сам React с введением Server Components и тесной интеграцией с Next.js явно смещает фокус с изолированного клиентского рендеринга на full-stack-архитектуру.
Однако это путь не для всех — на фоне усложнения экосистемы React растёт интерес к более простым альтернативам, которые решают те же задачи с меньшим порогом входа: Remix (упрощённая data loading-модель), Astro (лёгкость Islands Architecture) и даже HTMX (возврат к серверной логике). Конкуренция теперь идёт не только за производительность, но и за простоту освоения full-stack-паттернов.
№6. Смена парадигмы: от максимальной мощности к разумной достаточности
Осознание того, что не всё должно быть SPA, пришло не внезапно. Его готовили годы: статьи о сложностях SPA, доклады о преимуществах изоморфных приложений и, наконец, успех фреймворков вроде Next.js и Remix, которые сделали серверный рендеринг не экзотикой, а удобным инструментом. Сам React эволюционирует вместе с этим пониманием. Если в 2020 он был синонимом SPA, то к 2025 году с появлением Server Components он предлагает гибридную модель. Он по-прежнему лидирует, но его экосистема стала плюралистичной. Это видно по распределению новых проектов/
Новая ментальная модель в 2026:
// package.json 2025
{
"dependencies": {
"next": "^15.0.0", // или аналоги
"typescript": "^5.5.0",
"tailwindcss": "^4.0.0", // или vanilla-extract
"zod": "^3.22.0" // валидация вместо PropTypes
},
"devDependencies": {
"biome": "^1.5.0", // замена ESLint + Prettier
"vitest": "^2.0.0", // замена Jest
"playwright": "^1.40.0" // e2e тестирование
}
}В 2020 мы оптимизировали для Developer Experience, в 2025 оптимизируем для User Experience. Изменился фокус — изменились и инструменты.
Чем конкретнее проблема, которую решает фреймворк, тем выше его шансы на выживание.Поэтому в 2025 год мы достаточно отдалились от «React революсион», чтобы оценить её последствия, и достаточно приблизились к новой эпохе, чтобы увидеть её контуры.
А куда мы движемся: 2026 год и далее
Если года с 2020 по 2025 были переходом от SPA к hybrid, то с 2025 по 2030 будет переходом от JavaScript-центричности к платформенным возможностям.
Тренды на ближайшие годы:
№1. Web-стандарты против фреймворков
Браузеры наконец-то догоняют фреймворки.
View Transitions API позволяет создавать плавные переходы между страницами без JavaScript,
Container Queries решают давнюю проблему адаптивности внутри компонентов,
CSS Nesting возвращает вендорный синтаксис для вложенных селекторов.
Эти и другие спецификации постепенно уменьшают необходимость в кастомных JS-решениях для базовых задач, смещая фокус разработчиков с борьбы с платформой на использование её встроенных возможностей.
№2. Edge computing как новая норма
Логика выполняется не на клиенте и не на удалённом центральном сервере, а на географически распределённой сети edge-нод ближе к пользователю. Это сокращает задержки (latency) до минимума и позволяет отрисовывать динамический контент с учётом региона, устройства или даже погоды пользователя. Такие платформы, как Vercel Edge Functions, Cloudflare Workers и Netlify Edge Functions, уже превращают этот подход из экзотики в стандартный инструмент для создания быстрых и персонализированных веб-приложений.
№3. AI-assisted development
Речь идёт не о замене разработчиков, а о кардинальном изменении их роли. Инструменты на основе больших языковых моделей (например, GitHub Copilot, Cursor) берут на себя генерацию boilerplate-кода, рефакторинг, написание тестов и даже поиск багов по описанию. Это освобождает время для более важных задач: проектирования архитектуры, глубокого понимания бизнес-логики, валидации результатов работы AI и, в конечном счёте, — решения более сложных и интересных проблем.
№4. Специализация стеков
Эпоха поиска одного фреймворка на все случаи жизни окончательно уходит. Вместо этого формируются оптимизированные стеки под конкретные классы задач: Astro или Eleventy для маркетинговых сайтов и блогов (где важен вес и SEO), Next.js/Nuxt для сложных full-stack приложений, HTMX или Phoenix LiveView для высокоинтерактивных админ-панелей, а SolidJS или Svelte для требовательных к производительности интерфейсов. Выбор всё чаще определяется не модой, а чётким соответствием инструмента задаче.
№5. TypeScript 6.0+ — ещё меньше ручных аннотаций.
Почему так происходит?
1. Всеобщая мобильность и разнообразие устройств
Пользователи заходят в интернет со всего и вся: не только с мощных iPhone, но и со средних Android, планшетов прошлого поколения, умных телевизоров. Качество соединения также непредсказуемо — от гигабитного Wi-Fi до нестабильного 3G в дороге. Поэтому производительность перестаёт быть «оптимизацией», это просто базовое требование. 300KB бандл — это не смешно даже для финтех-приложения, если его будут открывать с мобильного банкинга в роуминге. Тренд задают не только emerging markets, но и общая парадигма доступности и user experience.
2. Конкуренция за внимание пользователя
Если сайт грузится на 500 ms дольше конкурента — пользователи негодуют. Производительность напрямую влияет на бизнес-метрики.
3. Усложнение требований к фронтенду
Фронтенд перестал быть «риcованием кнопок». Теперь это: accessibility, i18n, performance, security, offline-работа, push-уведомления и т.д.
4. Экономические факторы
Компании оптимизируют затраты. Дорого нанимать 5 узких специалистов вместо 2 универсалов. Отсюда тренд на full-stack разработчиков.
5. Выгорание разработчиков
Слишком сложные стеки (настройка Webpack, оптимизация ререндеров в React) приводят к усталости. Разработчики хотят фокусироваться на продукте, а не на инструментах.
6. Демократизация разработки
Нужно, чтобы джуниоры могли приносить пользу быстрее. Сложные инструменты этому мешают.
Выводы
Главный урок 2015→2025: фронтенд развивается циклически. Каждый цикл — это не «прогресс», а перебалансировка компромиссов.
В 2010 у нас была простота в лице jQuery.
В 2015 структурность в лице Angular/React.
2020 — это интерактивность в виде SPA-ов.
А 2025 — это прагматизм — Hybrid.
Но однозначно могу сказать, что необходимость решать бизнес-задачи, постоянно обучаться и ставить во главу угла пользовательский опыт, остаются.
Фреймворки умирают, а принципы остаются: компонентный подход, реактивность, декларативность.
Выбирайте инструменты под задачу, а не под моду: сегодняшний мейнстрим — завтрашний легаси. Технологи — это средство, а не цель.
🤔 Вопросы для размышления
Какую технологию из вашего текущего стека вы считаете следующей на "кладбище истории"? Почему?
Какие решения 2020 года вы с радостью похоронили в своих проектах?
Что из сегодняшних "горячих" технологий, по-вашему, не переживёт следующие 5 лет?
Как изменилась ваша работа за последние 5 лет? Что стало проще, что сложнее?
Если бы вы начинали новый проект сегодня, какой стек выбрали бы и почему?
P.S. Сохраните эту статью. В 2030 году будет интересно вернуться и посмотреть, какие прогнозы сбылись, а какие оказались смешными. Фронтенд — это не про предсказание будущего. Это про умение адаптироваться, когда будущее наступает.
