React почему не фреймворк

Обновлено: 06.07.2024

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

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

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

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

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

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

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

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 не так уж и плох, то я полностью соглашусь!

От автора: пару недель назад я начала работать над своим первым приложением React. Это было не только мое первое приложение React, но и мое первое приложение React Native, поэтому многое для меня было в новинку.

В сравнении с миром Angular (и Ionic), я чувствовал, что все мои предвзятые представления и идеи переворачиваются с ног на голову. Мне удалось собрать (как я думаю) довольно приличное приложение, но у меня было много препятствий на этом пути. Это отчасти потому, что я предпочитаю учиться, просто погружаясь. Таким образом, многие из этих сложностей могли быть решены просто с помощью документации.

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

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

В чем разница между библиотекой и фреймворком?

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

React JS. Основы

Изучите основы ReactJS на практическом примере по созданию учебного веб-приложения

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

Что это на самом деле означает?

Итак, я пересмотрела свои ожидания относительно того, что React сделает для меня. Когда мне нужно решить проблему, я знаю, что сначала нужно использовать Javascript, а не React.

Библиотеки компонентов React всегда предназначены для пользовательского интерфейса

Это то, что действительно не имело смысла для меня, когда я впервые столкнулась с этим. Взять, к примеру, библиотеку apollo-react. В этой библиотеке вы можете использовать элемент <Query>, который будет выполнять запрос GraphQL и возвращать результат прямо в разметке компонента.

React-разработчики создают приложения на React, используя дополнительные инструменты: например, Redux, TypeScript или Jest. Это востребованная работа: на React.JS написаны Яндекс, Netflix, Facebook и другие известные сервисы. Фронтенд-разработчик в Яндекс.Практикуме Давид Роганов рассказал, что такое React, и составил гид для его изучения.

Что такое React

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

Вскоре после появления React и подобные ему решения (Vue.js, Svelte) практически захватили мир фронтенда: потому что они помогают решать проблемы, основываясь на идее декларативного программирования, а не на императивном подходе.

Декларативный подход состоит в описании конечного результата (что мы хотим получить).
При императивном подходе описываются конкретные шаги для достижения конечного результата (как мы хотим что-то получить).

Оказалось, что декларативный подход отлично подходит для создания интерфейсов, и он прижился в сообществе. Этот подход работает не только в вебе: сравнительно недавно компания Apple представила фреймворк SwiftUI, основанный на тех же принципах.

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

Приложение на чистом HTML и JS

В рамках императивного подхода пошаговые инструкции для создания программы выглядят так:

объявляем начальные значения программы: присвоили константам ссылки на DOM-элементы, устанавливаем начальное значение счётчика;
пишем обработчик increment, в котором мы увеличиваем текущее значение, и устанавливаем его в соответствующий элемент;
устанавливаем начальное значение счётчика (0);
устанавливаем обработчик для кнопки.

Обратите внимание, что HTML-разметка и JS-логика хранятся отдельно друг от друга.

Приложение на React

Из-за специфики библиотеки код на React может выглядеть непривычно для того, кто пишет на JavaScript: потому что в тэге <body> практически нет вёрстки. Но сосредоточимся непосредственно на приложении-счётчике: его основная логика находится на строках 25-40.

Вот, что в нём происходит:

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

Сравнение двух вариантов приложения

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

Во втором, используя JSX-разметку и вспомогательные функции React, мы сразу описали результат, который хотим видеть. В этом и заключается отличие декларативного подхода от императивного.

Если сравнивать эти два приложения, то при использовании React можно выделить такие особенности:

Разметка и относящаяся к ней логика находятся рядом и связаны друг с другом. Это упрощает дальнейшую работу с кодом.
Выделен счётчик с кнопкой в компонент. Это значит, что мы можем очень легко его переиспользовать: достаточно на 44 строке написать ещё один тег <App />, и на странице появятся уже два независимых друг от друга счётчика.
Больше не нужно использовать идентификаторы для обращения к DOM-элементам, что также делает код более легко поддерживаемым.
Состояние компонента изолировано: нет никакой возможности модифицировать значение извне, если мы явно такое не задумывали. Благодаря этому поток данных в приложении становится более предсказуемым, что упрощает разработку и отладку.

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

Раньше в различных статьях часто можно было встретить заблуждение, что благодаря виртуальному DOM React быстрый. Следует понимать, что при прочих равных React-приложение не может быть быстрее того, что написано на чистом JS хотя бы потому, что сам React написан и выполняется на JS.

Особенности React

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

Эта библиотека действительно может упростить жизнь разработчикам:

Однако при использовании React есть особенности, которые важно учитывать:

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

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

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

Для каких проектов подойдёт React

Резюмируя все особенности, можно выделить несколько типов проектов, которым подойдет React.

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

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

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

Как изучить React

Один из наиболее полных и удачных ресурсов для первого знакомства и изучения React — это официальный сайт библиотеки. Он переведён сообществом на русский язык и поддерживается в актуальном состоянии. Если вы знаете английский, то стоит смотреть англоязычную версию. Тут логика такая же, как и с другими областями программирования — в англоязычном интернете гораздо больше информации, и она ближе к первоисточникам.

План изучения React может выглядеть так:

— способы подключения React к проекту;

— знакомство с JSX;

— знакомство с компонентами: стейт, пропсы, жизненный цикл;

— виды компонентов: классы и функциональные компоненты, их отличия;

— работа с формами;

— разработка простого приложения на React.

— React хуки, кастомные хуки, рефы.

— Популярные шаблоны: HOCs, render props, глупые/умные компоненты, controlled/uncontrolled components.

— сторонние библиотеки (redux, mobx и другие).

Диагностика проблем с производительностью, использование профайлера и оптимизация приложений на React.

Более продвинутые концепции:

— принципы интеграции с другими js-библиотеками;

— lazy loading компонентов;

Изучение работы под капотом:

— виртуальное дерево и алгоритм reconciliation;

— понимание концепций и устройства reconciler и renderer;

— написание своего рендерера.

Почти все эти темы можно изучить на официальном сайте React.

Для тех, кто уже хорошо знаком с React, есть отличная статья «Build your own React» — она поможет глубже разобраться, как работает React изнутри. Ещё можно посмотреть записи выступлений с конференции React Conf.

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

Почему сейчас стоит изучать React

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

Во-вторых, это целый дивный новый мир со своим огромным сообществом. React помогает взглянуть на разработку интерфейсов совершенно по-другому — через призму декларативного программирования. Это полезно для общего развития и расширения кругозора, а полученные знания упростят изучение других подобных библиотек и технологий (Vue.js, Svelte или даже SwiftUI). Кроме этого, многие принятые в сообществе соглашения, шаблоны и подходы сами по себе помогают писать более хороший и поддерживаемый код.

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

Еще не успев начать, я уже слышу, как клацают ваши клавиатуры под пальцами, набирающими гневные комментарии. Но я попрошу вас сперва прочесть мое объяснение и уже потом подумать над комментариями. Хочу отдельно подчеркнуть, что я ни в коей мере не выражаю критики в отношении тех, кто использует React или ценит этот инструмент. Однако я хочу показать, что эта библиотека во многом оставляет желать лучшего. Сегодня я проведу небольшое исследование с определением основных болевых точек, подтверждающих неполноценность React.

В первую очередь это хайп

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

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

Говоря коротко, позвольте разработчикам самим выбирать нужные инструменты. Если это будет React — хорошо, если же нет, то нужно просто довериться нанятым вами людям. Я же в этой статье буду говорить в основном о том, что React, на мой взгляд, является плохим выбором для средних и крупных команд, а также комплексных приложений.

Эффективнее работать в React одному

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

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

Вторая расплата за широкие возможности — это недостаток защитных средств. Я считаю, что грань между использованием защитных средств и недоверием к умственным способностям разработчиков очень тонка. Вам нужно, чтобы специалисты качественно справлялись со своими задачами, и при этом нужно им не мешать, а, наоборот, по возможности помогать. По своей сути философия React такова: делай все, что хочешь. Это дает абсолютную свободу, но практически лишает безопасности. В результате вы можете совершать действительно страшные ошибки на ранних этапах, не осознавая этого до момента, когда станет слишком поздно и придется рефакторить огромное количество кода. А что вы обычно делаете, когда такое происходит? Правильно, допиливаете его до работоспособного состояния и больше никогда не трогаете.

React поедает ОЗУ на завтрак

Многие думают, что React уникальна, потому что для отрисовки использует виртуальную DOM. Но при этом вы можете не осознавать, что React и виртуальная DOM — это два полностью раздельных концепта. Вам может быть интересно узнать, что Vue, а также кучка небольших библиотек тоже задействуют виртуальную DOM. Немало людей восхваляют виртуальную DOM как быструю и буквально революционную технологию. Хотя на деле оказывается, что она является ничем иным, как поглотителем памяти.

Если вы не знакомы с функционированием виртуальной DOM, то позвольте вас просветить. По сути, она сохраняет копию дерева DOM в памяти клиента. Затем, когда происходит изменение, создается новое виртуальное дерево DOM, которое сравнивается со старым. Далее React применяет обнаруженные изменения к браузеру, делая их видимыми для пользователя.

Вот небольшая схема, отражающая принцип работы виртуальной DOM

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

Сейчас вы можете подумать: “Так есть же много приложений React, которые отлично работают на смартфонах”. Здесь стоит понимать, что если приложение и работает, то это еще не значит, что работает оно отлично. Если в вашем компьютере, планшете или телефоне оказывается достаточно памяти для выполнения всех этих операций, разве это значит, что они нам реально нужны? Хочу также отметить, что данный факт потребления памяти не ставит приговор быстродействию приложения, но говорит о необходимости проделывания большого количества внимательной работы, чтобы оно реально заработало четко.

У виртуальной DOM есть и еще один недостаток — она объемная и для нее не применима операция перетряхивания дерева. Что такое перетряхивание дерева? По сути, это процесс удаления из финальной сборки ненужных или неиспользуемых элементов. Виртуальная DOM не поддается такому перетряхиванию, потому что вы никогда не узнаете, что вам окончательно нужно, пока не перейдете в среду выполнения. Это означает, что вам необходимо отправлять весь набор компонентов вместо облегченной версии.

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

Все упирается в сложность

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

В предыдущем разделе я упомянул, что React в некотором смысле воплощает в себе идею “делай, что хочется”. Я также отметил, что когда вы подключаете к проекту новых разработчиков, то в некоторых случаях недостача стандартов и встроенных в React средств защиты может вести к тому, что разработчики моментально устроят в приложении бардак.

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

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

Нужные компоненты отдельно

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

По факту React нельзя задействовать нигде, кроме как в приложении React. Вы можете использовать JQuery в приложении React или Angular, потому что это библиотека, а значит и применять ее можно везде.

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

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

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

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

В противоположность этому такие фреймворки, как Angular, изначально несут в себе весь нужный набор инструментов. При использовании Angular вам не придется скачивать сторонние библиотеки, например, для обработки форм или тестирования.

Обновления

Обновление версий происходят в жизни каждого разработчика. В один момент мы используем версию 1.0.0, как вдруг выходит новая 2.0.0, и мы уже стремимся поскорей ее попробовать. Но вот в React обновление версий никак нельзя назвать удобным.

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

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

Итоги

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

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

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