Vue или React: почему заказчику это почти неважно
React или Vue: разница в смете между ними меньше погрешности оценки. Разбираю, что действительно двигает бюджет веб-приложения и о чём спрашивать подрядчика.
React или Vue - выбор, который почти не влияет на ваш счёт. Сроки на обоих стеках одинаковые, ставки специалистов сопоставимые, разница в смете веб-приложения на 250 000-900 000 ₽ между ними укладывается в погрешность оценки. Я работал в продакшене и с тем, и с другим: торговый терминал на 25 000 активных трейдеров собран на Vue, подсистема поиска в открытой платформе документации Яндекса - на React. Разница в скорости работы была нулевая.
На деньги влияют три других решения, и их подрядчик обычно не выносит на обсуждение, потому что они звучат менее эффектно. Про них дальше.
Разработка веб-приложений и сервисовот 250 000 до 900 000 ₽сроки: 6-16 недель
Почему фреймворк не двигает смету
Смету веб-приложения формируют не строчки кода, а количество состояний, которые надо описать и проверить.
Форма заказа - это не одна форма. Это пустое состояние, состояние загрузки, ошибка сети, ошибка валидации на сервере, частично заполненные данные, успешная отправка, повторная отправка по случайному двойному клику. Каждое состояние надо нарисовать, реализовать и протестировать. Таких мест в среднем сервисе десятки, и на любом фреймворке работа занимает одинаковое время.
Дальше идут интеграции с чужими API, роли и права доступа, платежи и всё, что связано с деньгами. Здесь фреймворк вообще ни при чём: это серверная логика.
Поэтому когда вам называют разные цены за React и за Vue, разница почти наверняка не в технологии, а в оценке объёма или в том, чем команда владеет уверенно. Второе, кстати, законная причина: человек на знакомом стеке работает быстрее, и вы за это платите меньше.
Что действительно двигает бюджет
Где рисуется страница. Приложение может рендериться целиком в браузере, а может собираться на сервере или заранее. От этого зависит, увидит ли вас поиск и как быстро откроется первый экран. Для публичной части сайта разница фатальная: одностраничное приложение без серверного рендеринга индексируется плохо, LCP на мобильном уезжает за 3-4 секунды, и никакая оптимизация текстов это не компенсирует. Для закрытого кабинета за логином это не имеет значения вообще, потому что поиск туда не заходит.
Есть ли дизайн-система. Это самая недооценённая статья. Если кнопки, поля, таблицы и модальные окна собраны в переиспользуемые компоненты, каждый следующий экран делается быстрее предыдущего. На торговом терминале двадцать с лишним общих компонентов сократили время сборки нового виджета на 40%. Если системы нет, десятый экран стоит столько же, сколько первый, и вы платите за одну и ту же кнопку десять раз.
Сколько людей смогут это подхватить. Проект живёт дольше, чем отношения с подрядчиком. Стоимость передачи следующей команде определяется не фреймворком, а тем, есть ли типизация, тесты, документация по запуску и понятная структура папок. Хорошо написанный Vue передаётся легче, чем плохо написанный React, и наоборот.
Где React объективно впереди
Рынок исполнителей. React-разработчиков заметно больше. Найти замену быстрее, выбор шире, конкуренция за вакансию выше. Если вы строите команду из нескольких человек и планируете её растить, это весомый аргумент, и я не буду делать вид, что его нет.
Готовые библиотеки. Под редкую задачу - сложная таблица, редактор, календарь, графики - в экосистеме React решение находится почти всегда. В экосистеме Vue иногда приходится брать библиотеку без привязки к фреймворку и оборачивать её самому. Это день-два работы, но это реальные день-два.
Мобильная разработка на том же языке. React Native позволяет переиспользовать часть знаний и людей. Для Vue такого прямого пути нет.
Где впереди Vue
Скорость входа нового человека. Компонент на Vue читается ближе к обычному HTML, и разработчик, впервые открывший проект, начинает приносить пользу быстрее. На передаче проекта это ощутимо.
Цельность из коробки. Роутер, управление состоянием и сборка идут от одной команды и рассчитаны друг на друга. В экосистеме React те же задачи решаются набором сторонних библиотек, и выбор набора остаётся на подрядчике. Разные подрядчики выберут разное, и через два года ваш проект будет собран из решений, которые вышли из моды.
Меньше способов сделать одно и то же. Звучит как мелочь, но именно это делает код предсказуемым спустя годы.
Сравнение
React против Vue по осям, которые касаются владельца
Оценка с точки зрения бюджета и рисков, а не удобства разработчика. Чем выше значение, тем лучше показатель.
А React Б Vue
Разработчиков на рынке
перевес А на 35 Замену найти проще
Готовые библиотеки под редкие задачи
перевес А на 25
Скорость входа нового человека
перевес Б на 25 Заметно при передаче проекта
Цельность экосистемы
перевес Б на 35 Роутер и состояние от одной команды
Риск при смене подрядчика
перевес А на 25
Влияние на смету
поровну Разницы нет, и это главный вывод
Когда выбор всё-таки имеет значение
Три ситуации, в которых я бы настаивал на конкретном варианте.
У вас уже есть команда. Тогда берите то, что она знает. Переучивание стоит месяцев, и никакая элегантность фреймворка их не отобьёт.
Проект будет расти до десятка разработчиков. Здесь я склоняюсь к React ради рынка найма: набирать людей вы будете чаще, чем менять архитектуру.
Проект делает один человек или маленькая команда, и главное - предсказуемость через три года. Здесь Vue удобнее из-за цельности: меньше решений, которые устареют по отдельности.
Во всех остальных случаях спор о фреймворке - это спор о вкусах, оплаченный вашими деньгами.
Что спросить у подрядчика вместо вопроса про фреймворк
Как будет рендериться публичная часть и почему. Вам нужен ответ, а не «сделаем современно». Если сервис должен приходить из поиска, ответ обязан включать серверный рендеринг или статику.
Будет ли дизайн-система и входит ли она в смету. Если ответ «сверстаем по макетам», приготовьтесь платить за каждый экран отдельно.
Что вы получаете при расставании. Репозиторий, доступы, инструкция по запуску, описание окружений. Проверяется просто: попросите передать это после первого этапа, а не после полной оплаты.
Есть ли типизация и тесты на критичных местах. Особенно там, где деньги. Это не про фреймворк, а про то, будете ли вы через год бояться каждого релиза.
Как я собираю сервисы, что входит в архитектуру и почему дизайн-система появляется в первом же этапе, описано на странице разработки веб-приложений. Стек я предлагаю под задачу и под вашу будущую команду, а не под то, что мне интереснее писать.
