Почему React негативно повлиял на веб-разработку

Недавно я представлял нашу компанию на конференции разработчиков .debug. Целью моего посещения было привлечение специалистов к обмену мнениями. Идея состояла в том, чтобы создать своего рода дискуссионную площадку, где мы представляем радикальную идею и приглашаем к ее обсуждению профессионалов. 

Концепция React стала первой темой обсуждения.

Моим первым оппонентом стал молодой человек (справа), создающий приложения на нативном React

Если говорить серьезно, React  —  отличная библиотека. Она очень нужна для веб-разработки, потому что в ней представлены декларативные и реактивные шаблоны  —  сдвиг парадигмы, который был необходим в то время. React довольно хорошо решил появившиеся ранее (6-7 лет назад) проблемы механизмов рендеринга и реактивности.

Стоит заметить, что Ember решил эти проблемы еще раньше. Однако в этом фреймворке реализация получилась не столь эффективной, как в React.

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

Возьмем, к примеру, «управление состоянием» (state management). Поскольку в React отсутствует традиционная система внедрения зависимостей (она достигается за счет композиции компонентов), программистам пришлось решать эту проблему самостоятельно. И это происходило неоднократно. Каждый новый год появлялся новый набор стандартов.

Девиз React State Management : «Новый год — новый я!»

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

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

Одной из появившихся тенденций стала «одержимость сравнением фреймворков JS». Их постоянно сравнивали по таким свойствам, как скорость рендеринга и объем памяти. Но в большинстве случаев это не существенно, потому что не фреймворк, а плохой код является причиной медленной работы приложения.

Желающих принять участие в обсуждении становилось все больше

Как и в случае с любым захватывающим мир трендом, это увлечение зашло слишком далеко и негативно отразилось на формировании нового поколения веб-разработчиков. Удивительно, как библиотека может считаться самым важным навыком в резюме веб-разработчика среднего уровня? И даже более того, это не библиотека, а модуль внутри библиотеки. Хуки React сегодня упоминаются в качестве «навыка» чаще, чем такие реальные навыки, как рефакторинг или анализ кода.

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

Как создавать простой и легко читаемый код

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

Как управлять состоянием

Без упоминания популярных библиотек (преимущественно оканчивающихся на “X”), лучше опишите паттерн «Data Down, Actions Up» (данные вниз, события вверх). Или укажите, почему состояние должно быть изменено на уровне его создания, а не глубже в иерархии компонентов.

Как тестировать созданный код

Не стоит рассказывать о том, что знаете Jest или QUnit. Лучше объясните, почему трудно автоматизировать сквозные (end-to-end) тесты и почему минимально значимые тесты рендеринга  —  это 10% усилий и 90% пользы.

Как выпустить новую версию кода

Сегодня в любом крупном проекте используется методология непрерывной интеграции и развертывания (CI/CD) программного продукта. При этом следует понимать, что первичное развертывание и выпуск новой версии  —  это разные вещи. Поэтому необходимо обеспечивать максимальную совместимость новых версий с прошлыми.

Как создавать легко анализируемый код

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

Как соблюдать технические условия проекта

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

Как анализировать чужой код

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

Как выбрать фреймворк JS

Естественно, речь идет не об учете количества звезд на GitHub, а об общих принципах, которыми обладают большинство современных фреймворков JS. Узнав о плюсах и минусах разных фреймворков, можно сделать осознанный выбор.

Как компоновать минимально жизнеспособный продукт (MVP)

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

Как выбрать время для начала оптимизации

Часто оптимизация не требуется вовсе.

Как организовать парное программирование

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

Как постоянно проводить рефакторинг

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

С учетом всего вышесказанного, я считаю, что React разрушает процесс веб-разработки. Присутствующие на импровизированной конференции были заинтригованы этим заявлением и охотно присоединились к дискуссии. Я плодотворно пообщался с рядом опытных разработчиков на React. Никто из них не одобрил название этой статьи, а утверждение “разрушает” они посчитали несколько преувеличенным. Но с обозначенными в статье проблемами большинство было согласно.

Если и вы будете убеждать меня, что React не так уж и плох, то я полностью соглашусь!

Читайте также:

Читайте нас в TelegramVK и Яндекс.Дзен


Перевод статьи Ivan Lučin: React Ruined Web Development

Предыдущая статьяНаследование и полиморфизм в Python
Следующая статьяОрганизация таблиц стилей: самые свежие рекомендации