Как правильно выбрать фронтэнд framework или почему нельзя верить сравнению фреймверков

Published in

F.A.F.N.U.R

9 min readOct 8, 2019

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

Сравнение фреймверков

Стремительное развитие JavaScript привело к бурному развитию фронтенда. И за несколько лет появились несомненные лидеры в лице: React, Vue.js и Angular. Все это привело к огромному количеству статей, в которых идёт сравнение фреймворков и библиотек по следующему ряду критериев:

Количество звёзд на гитхабе
Количество открытых вопросов
Размер сборки приложения
Количество упоминаний в гугл*
Количество вакансий на тот или иной фреймверк*

Количество звёзд и количество открытых issue, говорят лишь о том насколько удобна та или иная технология и какое у неё комьюнити. Если завтра один из разработчиков React или Angular представит новый проект Lui, то проект наберёт более тысячи звёзд меньше чем за месяц.

Субъективно, лучше смотреть на политику релизов и обновлений. А то и у jQuery так то, очень много звёзд. И в своё время, там можно было делать такие штуки, эх… А потом началось — react, angularjs, bower, webpack’и и никто не помнит про Dojo, Ext JS, Prototype, не говоря про Backbone.js, Meteor, Ember …

Размер сборки приложения важен в web, но он определяется разработчиком, а не платформой. Если собранный проект на React занимает меньше 100 кб, то дефолтное приложение аля Hello World на Angular весит ~ 250 кб.

Если использовать “колдунство”, то размер angular application можно свести к ~ 12 кб, но об этом тсс…

При этом не до конца ясна политика с расчётом polyfill’ов. И все это приводит к тому, что размер сборки будет определять качества и умения разработчиков.

Количество упоминаний и количество вакансий отображает лишь спрос рынка, на качество той или иной технологии. Если рынку необходимо множество быстрых и дешёвых, но одноразовых решений — рынок их получит.

Похожая ситуация была в начале становления интернета, когда потребность в PHP разработчиках была настолько огромной, что даже таксисты бросали свои насиженные места и шли программировать. И тут действительно не знаешь, что лучше индус или таксист программист.И шутки шутками, а к нам действительно на должность ведущего разработчика приходил каменщик, и видимо в его голове было, что сначала ты ложишь камень, а потом “кладёшь” код.

Иногда можно увидеть сравнение на производительность и скорость загрузки и отрисовки веб элементов. Но так как в современных реалиях это вряд ли нужно, а скорее всего нужна работа с асинхронными данными и реактивностью, а также управлением состоянием, то интересно посмотреть на нагрузку браузера и количество требуемых действий для фреймворков, но пока таких исследований не было, и в этой статье их тоже не будет :) Будем ждать вместе.

Основные критерии выбора

На данный момент не существует объективных критериев, которые однозначно показали применимость той или иной технологии, но составим список параметров исходя из основ разработки.

К основным критериям по выбору фреймворка, должны быть отнесены следующие параметры:

Время разработки
Процесс разработки
Технологические возможности фреймворка

Время разработки — основной ресурс разработчика. Никому не нужен проект, который будет сделан более чем за “год/два/три”.

Даже не так, проект который вы разрабатываете должен приносить доход уже вчера. А как вы думали, зачем вас наняли?

Чем больше время разработки, тем выше стоимость, тем меньше привлекательность для инвесторов, тем меньше денег можно заработать. Это палка о двух концах. Но всегда нужно учитывать, если проект нужно делать в сжатые сроки (либо есть какие либо сроки), то скорость разработки очень важна, и нужно понимать, что скорость разработки обратно пропорционально качеству разработки.

Из баек компании, в которой я работал некоторое время назад, ребята писали аналог 1C, и было выбрано решение, которое за месяц позволило разработать 70% всего функционала, но начиная со второго месяца, скорость разработки почти остановилась, и за год было сделано не более 75%. И проект закрыли из-за отсутствия финансирования, хотя было потрачено более 12 млн. рублей, печалька.

Процесс разработки говорит о том, как зависит разработка от количества задач и разработчиков, на результат.

Есть ошибочное утверждение, что если разработчик может сделать задачу за 2 дня, то если добавить ещё одного такого же разработчика (который не является его братом близнецом), то задачу можно выполнить за 1 день, но это чаще всего не так, если разработчики не братья близнецы.

И логичный вопрос, как это относиться к фреймворку, причём для UI?

Есть множество компаний, которые переписали свои легаси проекты на React и получили легаси с React! Пам-пам.

Если в React у вас полная свобода, то Angular иногда бьёт по рукам и говорит — “Так нельзя”, “И так нельзя”, “Ты что совсем, иди читай доки”.

И тут проблема не в React, а в том, что не был выстроен процесс разработки — приняты стандарты разработки (style guide), настроено тестирование и т.д. И каждый фреймворк, обладает своими особенностями, и требованиями к разработке, что будет определять процесс разработки.

Например, если вы возьмёте в качестве фреймворка Angular и решите использовать mono repo, то вы должны понимать, что процесс разработки новых фич (абстрактно работы на 1 день) будет не меньше 1 недели (тестирование, тестирование в моно репо, и куча всего ещё) на 1 разработчика, и считать что разработчик за 1 день сможет делать недельный объем работы, то это станет фатальной ошибкой для проекта и приведёт к его закрытию.

Технологические возможности фреймворка стоят на 3 месте из-за того, что только после понимания сроков и процесса разработки, можно рассматривать преимущества фреймворка.

Нет смысла выбирать фреймворк с быстрой разработкой для качественной разработки, так как это одна из утопических идей, погубившей не один Uber.

Все это можно свести к следующему банальному выводу:

Проект определяет потребности
Исходя из потребностей проекта и навыков команды выбираем то, что максимально близко.
Смотрим, что можно сделать из того, что выбрали.

Выбор фреймверка

На момент написания статьи, популярны 3 решения:

React
Vue
Angular

Есть и другие решения, но представленная тройка в основном отображает основные тенденции и развитие современного JavaScript.

И перенесём диаграмму Колин Хармана на front-end разработку:

Как можно видеть из диаграммы, основная цель для React и Vue — Создавать быстрые, легко разрабатываемые компоненты.

Angular же пошёл другим путём, поставив в приоритет качество разработки с упором на максимально возможную эффективность (скорость работы приложения, масштабируемость и т.д.).

Для проверки данного утверждения, надо всего лишь поиграться с данными фреймворками и библиотеками.
Даже на простых примерах, если для React и Vue достаточно 1–7 дней, то для Angular нужна как минимум одна неделя, а чтобы поднять весь стек c redux + ssr + graphql + nativescript не хватит и месяца, не говоря про оптимизацию, полное покрытие тестами, поддержке разных платформ и т.д.

Преимущества фреймверков

Если три года назад, существовали различия между технологиями, то в данный момент, каждая из технологий обзавелось своим cli, добавили поддержку TypeScript или Dart, предоставили решения для роутинга, SSR, graphql, различные имплементации Redux и т.д., с одним лишь замечанием,что у Angular и Vue, почти все идет из коробки, а в React приодеться немного покопаться.

Ярким показателем является реализация моно репозиториев (Lerna и Nx), в которых можно строить гибридные приложения с разными фреймворками, где считается нормальной практикой, часть интерфейсов реализовать на React, а часть на Angular.

Такими темпами и до виртуальных машин дойдём, где будет не докер — Noker, который позволяет создать приложение на Angular, внутри которого будет React. Хотя страшно подумать, что это уже есть и кто-то этим пользуется.

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

React как лучшее решение для UI

React из-за своей простоты и особым видением front-end делает его одним из лучших решений.

Возможно если Цукерберг, был бы на столько же эмоционален как Джобс, он бы непременно провёл конференцию, и рассказал, какой же великолепный React, и почему его любят миллионы разработчиков.

Опишем основные преимущества:

Скорость разработки
Размер приложения
Обратная совместимость
Нативная поддержка Redux

Когда стоит выбирать React:

Небольшое приложение
Нужно быстрое решение
Нужно эффективное приложение
Вы любите facebook

Когда не стоит выбирать React:

Реализовывать enterprise решение
Масштабируемое или часто меняющееся приложение

Из всего выше сказанного, можно сказать, что если вы пишите монстра аля — Facebook, то возможно выбор React будет не лучшим решением, но никто не мешает это попробовать.

Vue.js как лучшее решение для UI

Vue — решение появившееся в ходе соединения первых версий react и angular.js. Решение больше напоминает React, хотя и развивается в своём направлении.

Vue стоит выбирать тогда, когда вы не очень любите Facebook, а также не питаете любви к Google, и вообще за то, что один разработчик может все сделать сам, без всей этой корпоративной волокиты.
Но помните, что если Эвана собьёт автобус, это может немного осложнить поддержку Vue.

Опишем основные преимущества Vue — все те же, что и у React.

Когда стоит выбирать Vue — тогда же, когда и React.

Когда не стоит выбирать Vue — если не верите в Эвана или в Single person developer (SPD).

Единственный упрёк, который автор видит в Vue — это слишком мало требований к разработке и отсутствия явного style guide. За последние три года встречались 3 проекта на Vue, и каждый был на столько уникален, что трудно сказать, что их объединяет.

Angular как лучшее решение для создания UI через муки и боль

Хоть автор и является Angular евангелистом, но он все равно считает, что для выбора Angular нужны два требования (как собственно и у Google, которая его разрабатывает):

Огромное количество времени на разработку
Огромное количество денег на разработку

Можно сказать, что Angular подходит для — Огромных проектов, а маленькие проекты он может только разорить (либо разорить компанию, либо разработчика, который сказал что все сделает за несколько дней, а в итоге сделает за год).

Про Angular можно говорить много, но это все про качество, принципы, подходы, которые помогут сделать из JS разработчика — JS разработчика с angular’ом головного мозга.

Только в Angular можно увидеть нечто, где все запрятано в интерфейсы и завернуто в DI:

/**
 * Comment http service
 */
 export abstract class CommentHttp {  ...   /**
   * Save comment
   * @param comment Comment
   * @param queryParams Query params
   */
  abstract save(comment: Comment, queryParams?: object): ApiResponse<void>;
}...@Injectable()
export class BaseCommentHttp extends ApiHttp implements CommentHttp {
  constructor(
    private httpClient: HttpClient,
    @Inject(COMMENT_API_ROUTES) private apiRoutes: CommentApiRoutes
  ) {
    super(); 
  }  ...   save(comment: Comment, queryParams: object = {}): ApiResponse<void> {
    this.httpClient.post<void>(this.apiRoutes.save, JSON.stringify(comment), this.getOptions(queryParams))
      .pipe(catchError(error => throwError(error)));
  }
}

Типичный “веб-компонент” (не путать с компонентами ангуляра) содержит:

— feature
— — +state (redux state фичи)
— — components (общие angular component’ы)
— — containers (лейауты или страницы которые являются angular component’ами)
— — interfaces (папка с интрерфесами и типами)
— — services (папка с сервисами, хендлерами, и всем, что можно задиаить)

К этому, надо учесть, что фича может быть lazy. Также она может быть переиспользована, а также если используется SSR или пишется приложение c NativeScript, то есть разделение на серверную, мобильную реализации, которые начинает дублировать и переопределять файлы, которые вызывают: Страдание, боль и уважение.

Опишем основные преимущества Angular:

Функциональность (есть много готовых решений, разрабатываемых разработчиками или приближенными к ним людьми (бывшие члены команды angular))
Качество кода* (если у тимлида или архитектора есть понимание принципов программирования, то есть шанс высококачественного кода)
Покрытие тестами — много тестов, очень много тестов, если используется mono repo, то более триллиона тестов, которые нужно писать :(

Когда стоит выбирать Angular:

Enterprise решение
Хотите разорить компанию, которая вам не нравиться, но вы в ней работаете

Когда не стоит выбирать Angular :

Всегда, когда это возможно.
Если вы не планируете работать в компании больше года (так как через год все устареет и превратится в легаси, то пора менять работу и поэтому можно не париться и фигачить на всем, что увидите)

Заключение

Обобщив все выше сказанное, можно прийти к следующим утверждениям:

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

Спасибо за внимание!