Недавно работал над хобби-проектом, который описал в другой своей статье. В процессе его реализации у меня возникло желание чиркануть пару абзацев о том, почему React — отстой, но в итоге я не смог удержаться и решил высказаться по полной…
Так что вот она полноценная статья, ещё больше той, из которой она родилась. Здесь я подробно опишу все проблемы React и поясню, почему это может не быть виной разработчиков.
Древний Angular
Когда я был ещё джуном и только осваивал профессию, мне довелось работать с Angular, популярным «коммерческим» фреймворком JS. В те времена это была достаточно хорошая технология. Явно крупнейший фреймворк JavaScript на тот момент. Плюс в копилку его заслуг можно положить тот факт, что это, пожалуй, был первый фреймворк для разработки в веб-среде. До этого были только «библиотеки», так что Angular не только первым предоставил нам набор функций, но и стал реальным фреймворком, на котором можно было создать веб-приложение.
Но всё познаётся в сравнении, и Angular был хорош только потому, что значительно обходил прежние решения. В то время были и другие фреймворки для разработки одностраничников вроде Backbone и Knockout, но их след в истории оказался не столь значительным. Реальным же соперником, которого победил Angular, был jQuery.
Несмотря на то, что jQuery был лишь обёрткой для (тогда довольно паршивых) HTML DOM API, он всё равно стал эталонным решением для создания комплексных веб-приложений. Принцип его работы был довольно прост — вручную и императивно создаёте HTML-элементы на JS, затем изменяете их, перемещаете куда надо и делаете всё необходимое, чтобы сайт работал интерактивно так, будто это приложение.
И всё это прекрасно работает в случае простых приложений, но можете себе представить кошмар с обслуживанием, возникающий при создании крупных программ. И винить нужно не jQuery, а аппетиты современных пользователей, которым повсюду требовалась эта интерактивность. В итоге разработчики были вынуждены продолжать использовать jQuery, несмотря на то, что этот инструмент перестал быть удачным выбором для текущих задач.
Затем появился Angular и всё уладил. Теперь вы могли направить свои силы на написание UI и логики приложения вместо того, чтобы вручную собирать отдельные кусочки HTML. Эта библиотека фреймворк поистине стал революционным, так как у нас, наконец, появился инструмент для создания реально БОЛЬШИХ интерактивных приложений. Вот лишь часть из его магических свойств:
A) Компоненты. Если быть точнее, то назывались они «директивами», так как в нём использовалась странная система именования. Но как бы то ни было, вы могли написать с помощью HTML и JS простой файл, представляющий элемент UI, и использовать его в разных местах приложения.
Б) Двухсторонняя привязка (two-way binding). Суть в том, что после определения переменной впоследствии при её изменении обновлялись все связанные области в UI. Позднее люди начали жаловаться на такой всенаправленный поток данных, считая его неудачным. Тогда возникла тенденция к использованию односторонних привязок (сверху вниз), что с технической стороны звучит как более удачное решение, но на практике только всё усложнило и привело к дискуссии, которая кончилась тем, что сегодня мы используем Redux. Так что, спасибо.
На своей первой работе я как раз наблюдал эти тренды воочию, когда занимался переписыванием одного такого неуклюжего приложения jQuery на Angular. И сам этот процесс, и конечный результат меня порадовали.
Но были и неприятные моменты. Например, мне не понравилось переписывать те же самые экраны на Angular 2 через несколько лет, и я рад, что успел уйти из той компании до того, как они могли заставить меня переписывать всё это в третий раз — уже на React.
Знакомимся с React
Позднее у меня появилась возможность освоить React и даже использовать этот инструмент профессионально в паре проектов.
Я всё ещё помню, как свежо он выглядел на первый взгляд. Тогда React ярко контрастировал с актуальным на тот момент фреймворком Angular 2, который требовал полностью переписывать код своего предшественника, но теперь с удвоенным объёмом бойлерплейта, односторонней привязкой, использованием TypeScript и паттернов reactive/observable. Сами по себе все эти возможности прекрасны, но чёрт возьми, они так всё усложняли, замедляли работу, сборку и выполнение кода.
React же качнул маятник обратно в сторону простоты, и люди это оценили. Какое-то время простота действительно сохранялась. React набрал популярность и стал библиотекой #1 для создания одностраничников.
Да, теперь мы снова использовали термин «библиотека», демонстрирующий простоту этого инструмента. Но нельзя адекватно создать комплексное приложение с помощью одной библиотеки — для обработки всех его задач потребуется несколько, а также полноценная структура кода. Подход React в стиле «напитки приноси с собой» подразумевал, что вы создаёте фреймворк сами со всеми вытекающими недостатками.
В конечном итоге все приложения на React получались индивидуальными. В каждом из них создавался «фреймворк», состоящий из собранных по сети рандомных библиотек.
Все приложения, с которыми мне не повезло работать в то время, подводили меня к одному выводу — для этого бы лучше подошёл даже Angular 2. «Ядро» JSX всегда было твёрдым, но всё сопутствующее представляло полную неразбериху.
В итоге я бросил это гиблое дело и занялся написанием бэкенда на Java. Думаю, мой выбор говорит сам за себя.
Только я решил, что покончил с этим...
Говорят, что научиться — не значит понять. Очевидно, я так до конца и не понял, поэтому недавно снова окунулся в дебри React.
Хорошо, что это был хобби-проект, так что я получил не столь «полноценный» опыт, как было бы в случае серьёзного коммерческого приложения. Но даже этого скромного опыта оказалось достаточно, чтобы подтвердить и усилить мои негативные ожидания от этого инструмента. Работа с React — это какое-то безумие, и я не понимаю, почему об этом никто не говорит.
Архитектура, компоненты, состояние
Начнём с архитектуры, которую тебя вынуждает использовать React. Как я уже говорил, React — это просто библиотека, поэтому она ни к чему тебя не обязывает. Но всё же неявные ограничения, связанные с JSX, раскрывают некоторые паттерны. Давным-давно мы говорили об MVC (Model-View-Controller), MVVM (Model-View-ViewModel), MVP (Model-View-Presenter) — все из которых представляют лишь вариации на тему. И какой же из них подразумевает React? А никакой. Думаю, в нём заложена новейшая парадигма, которую можно назвать буквально «архитектура на основе компонентов».
На первый взгляд всё это логично. У вас есть компоненты, из этих компонентов вы строите нисходящее дерево, в результате чего получаете своё приложение. При этом React внутренне проделывает свою магическую работу, обеспечивая сохранение актуальности всех компонентов на основе предоставленных вами данных. Ничего сложного.
Но где-то в процессе своего развития эта библиотека начала мудрить. Для простой «библиотеки UI» в ней явно образовалось многовато сложной терминологии. А для библиотеки, никак не связанной с «функциональным программированием», в React присутствует уж очень много названий из этой сферы.
Начнём с состояния. Если вы создаёте нисходящее дерево компонентов, то наверняка решите и состояние тоже передавать сверху вниз. Но на практике в свете присутствия огромного числа мелких компонентов всё это создаёт путаницу, так как приходится тратить кучу времени и кода только на связывание элементов данных, направляя их туда, куда нужно.
Эта проблема была решена путём «подгрузки» (англ. sideloading) состояния в компоненты с помощью хуков. Не слышал, чтобы кто-то на это решение жаловался, но я вас умоляю, вы что, серьёзно? Вы говорите, что любой компонент может использовать любой элемент состояния приложения? Хуже того, любой компонент может вызывать изменение состояния, способное повлиять на состояние любого другого компонента.
Как это решение вообще прошло код-ревью? Вы, по сути, используете глобальную переменную, только при более изощрённых правилах изменения состояния. И это даже не правила, а просто условная церемония, так как ничто не мешает изменять состояние из любой части программы. Люди реально думают, если назвать что-то заумным именем типа «редьюсер», то это внезапно станет Good Architecture™?
Но если подходы с нисходящим построением и «подгрузкой» являются неудачными, то что станет решением? Честно, даже не знаю. Мне на ум приходит одна мысль: «Если мы не можем решить это изящно, то, может, вся «архитектура на основе компонентов» была ошибкой, и нам не следовало нарекать её образцом «удачного дизайна», прекращая поиск более грамотных решений. Быть может, на сей раз нам действительно нужен другой фреймворк JS, пробующий более удачные подходы.
Хуки React
Следующим в списке решений, которые странным образом прошли код-ревью, идут хуки React. Никто не спорит, что они полезны, но их существование вплоть до сегодняшних дней вызывает у меня вопросы.
Даже не буду углубляться в то, что люди называют компоненты «чистыми функциями», но в итоге засовывают в них крохотные чёрные ящики с состоянием. А с учётом их составной природы, это больше подобно наслоению крохотных чёрных ящиков.
Я же хочу заострить внимание конкретно на useEffect. Реализуемый с его помощью «побочный эффект» прост и понятен. Вы изменяете состояние, после чего требуется совершить некое внешнее действие, например, отправить результаты в API. Это разделение между «важной составляющей приложения» и «побочными эффектами» имеет смысл — в теории. Но сможете ли вы также чисто разделить их на практике?
Больше всего в useEffect меня раздражает то, что этот хук используется для задачи «выполнить что-то после монтирования компонента». Я понимаю, что после переезда React с классов на хуки это была ближайшая альтернатива componentDidMount, но вот скажите мне — разве это не огромный хак?
Вы используете хук, реализующий «побочные эффекты», для инициализации компонента? Хорошо, если вам нужно сделать из хука вызов, то я согласен, это будет побочный эффект. Но ведь вызов API… он устанавливает и состояние тоже. В итоге абсолютно безобидный хук для создания побочных эффектов по факту управляет состоянием компонента. Почему никто не указывает на это безумие?
Более того, если бы вы хотели установить зависимость от этого состояния и делать что-то после него, то вы бы…определили ещё один useEffect, зависящий от результата выполнения первого.
Этот код я взял из рабочего приложения в компании, которая недавно была куплена за несколько десятков миллионов долларов США. Я его чуть подредактировал, заменив реальные сущности на упрощённые House и Cat. Но вы просто взгляните и попытайтесь проследить, в какой последовательности этот код выполняется. Когда будете готовы, загляните под спойлер ниже, чтобы увидеть правильный ответ.
Ответ
И что мы здесь имеем? Серия изменений состояния, которая в противном случае была бы простым императивным кодом, теперь… разбросана по двум асинхронным функциям, и единственной подсказкой о порядке выполнения является «массив зависимостей» в нижней части каждой. В итоге читать этот код по факту надо снизу вверх.
Я помню, как промисы JS со своими then называли неповоротливыми, да и раньше у нас уже была проблема с «адом обратных вызовов» — но ничто не сравнится с этим.
Думаю, эти сложности можно устранить двумя путями: а) переместив всё это в отдельный файл, что лишь скроет проблему; или б) возможно, с помощью Redux или чего-то аналогичного, но здесь у меня недостаточно опыта для каких-то конкретных предложений.
«Паттерны»
Всё это воедино выглядит ужасно и никак не пахнет той простотой, которую разработчики React обещали в примере «Hello world». Но и здесь ещё не всё. Намедни я прочёл статью под названием «The Most Common React Design Patterns». Не знаю, чего я ожидал, но в итоге был шокирован сложностью описанных там паттернов и тем, сколько умственных усилий необходимо, просто чтобы разобраться в происходящем. Причём всё это лишь для того, чтобы отрисовать элементы на экране.
И самое странное в том, что автор статьи даже этого не признаёт. Вся эта сложность воспринимается им как должное. Похоже, люди действительно безропотно создают свои UI таким образом.
А ведь некоторым и этого мало, они идут ещё дальше и пишут «CSS вместе с JS», и даже получают за это деньги. Я согласен, JSX сразу продемонстрировала, что «разделение задач» не означает «разделение файлов», и что вполне нормально писать HTML- и JS-код в одном файле. Но засовывать туда ещё и CSS с использованием строгой типизации? Разве не перебор?
Почему?
Было бы слишком легко просто заявить, что React абсурден, и вернуться к своим делам. Но я верю, что мы разумные приматы и способны на большее. Мы можем попытаться понять причину.
Я вновь углубляюсь в чертоги памяти и вспоминаю свою первую работу и коллегу, который упомянул проект переезда на jQuery. Невероятно опытный бэкенд-инженер, архитектор, да и просто уважаемый парень в сфере ПО.
Мне же больше запомнились не его технические решения, а огромное количество критики, которую он выражал в отношении всего, что мы делали во фронтенде. Когда он видел какое-то решение на Angular, то звучал примерно такой комментарий: «Чем вы тут вообще занимаетесь? Неужели нельзя сделать всё как-то проще?»
И дело было не в нас — наша команда имела неплохой опыт в разработке. Просто в то время глазами бэкенд-инженера вся система Angular выглядела совершенно неадекватной.
Сегодня мне примерно столько же лет, сколько было тому парню тогда, и я пишу статью о том, что Angular React — отстой. Думаю, некоторые вещи неизбежны.
Но взглянем с более общего ракурса и попробуем понять, почему так случилось.
Думаю, все согласятся, что большинство веб-приложений просто не должны быть таковыми. Люди создают одностраничник сразу, даже если он им не нужен прямо сейчас, просто потому, что так дешевле.
Но здесь я поспорю, так как на деле подобный ход накладывает достаточно хлопот. Просто мы привыкли к модели использования одностраничников по умолчанию и забыли о более простых альтернативах. Запустить простецкую страничку с отрисовкой на сервере будет куда легче, чем даже подумать о React. В этом случае нет издержек на коммуникацию с API, фронтенд получается лёгким, код UI можно строго типизировать (если бэкенд тоже строго типизирован), можно делать рефакторинг по всему стеку, повысится скорость загрузки и удобство кэширования, так как некоторые компоненты будут статичны и одинаковыми для всех пользователей, то есть их можно будет загружать один раз. И это лишь часть списка.
Хотя тогда вы уже не сможете так же гибко реализовывать сложную интерактивную логику по требованию продакт-менеджера. Но и это не совсем так. Я уверен, что вы сможете довольно далеко продвинуться путём «постепенного расширения» JS-кода, пока управление состоянием не станет достаточно сложным, чтобы оправдать подключение к процессу React.
Хорошо, я говорю, что мы используем React просто потому, что использовали его раньше. Да и не удивительно, всегда сложно преодолеть инерцию. Но это всё равно не объясняет столь безумную сложность получаемого кода.
И мой ответ на вопрос «Почему?», как ни удивительно, отводит праведный гнев от React, защищая не только эту библиотеку, но также Angular, jQuery и всех их предшественников. Думаю, плохой код объясняется тем, что создание интерактивного UI, где любой компонент может обновлять любой другой компонент, просто является одним из сложнейших аспектов в разработке ПО.
Ради сравнения подумайте о любой другой системе, которую используете повседневно. У вашего кухонного крана есть два источника ввода — холодная и горячая вода, объединяемых в одном выводе. У кухонного миксера или строительной дрели может иметься пара кнопок, и что бы вы с ними ни делали, это будет влиять на действия вращающегося узла. У газовой плиты может быть до пяти регуляторов и такое же число выходов, что уже начинает немного пугать.
А вот у интерактивного UI, который мы реализуем в веб-среде, потенциально может быть бесконечное число входов и бесконечно много выходов. Как вообще можно ожидать реализации всего этого в виде чистого кода?
Так что насчёт всего моего наезда на React… По сути, это вовсе не вина библиотеки, как и не вина Angular или jQuery. Какую бы технологию вы ни выбрали, она неизбежно скрючится под гнётом невыносимой сложности реактивных UI.
Как?
Как это исправить? Боюсь, для решения этой проблемы мне не хватит знаний и опыта, но я могу высказать пару идей. Если мы усвоим эту ментальную модель «входов/выходов» на веб-странице как основу, то можно будет начать работать над сокращением числа этих входов и выходов.
В отношении входов я, например, предложу: «Сократите количество кнопок», что может не всегда оказаться осуществимым. Но здесь связь очевидна — чем меньше у вас функциональных возможностей, тем легче управлять кодом.
И вроде это достаточно понятно, чтобы лишний раз не напоминать — не так ли? Знают ли продакт-менеджеры, что добавление трёх кнопок вместо двух повышает количество багов на 5% и на 30% усложняет последующее проектирование и реализацию работы страницы? Эти значения никто даже не измеряет, но я считаю, что они вполне могут оказаться верны.
Почему, если я скажу вам, что нужно добавить в бэкенд Redis, вы возразите в духе: «Нет, нужно сдерживать техническую сложность», а если продакт-менеджер попросит добавить в приложение глобальный фильтр, который можно применить отовсюду и ко всему, вы просто опустите голову и напишите такого кодомонстра, от которого ещё с десяток лет придётся избавляться.
Если коротко, то я прошу вас, прекратите добавлять так много кнопок. Пусть это прозвучит безумно, но можете даже удалить некоторые из них.
А вот со стороны выходов ситуация несколько иная. Я пишу всё это и понимаю, что создание страницы с отрисовкой на сервере, по сути, сведёт эту страницу к одному выводу. С чем бы вы ни взаимодействовали, это будет приводить к повторной отрисовке всей страницы. То есть, как бы иронично это ни звучало, но удаление из замеса всего функционального кода React фактически сделает отрисовываемую сервером страницу чистой функцией состояния. Если вы можете позволить себе такую роскошь, то отсутствие состояния фронтенда обеспечит значительный выигрыш в простоте.
Если же вам в таком отрисовываемом на сервере «приложении» вдруг потребуется скриптовая логика, разумно будет добавить её только в самых важных местах. И чем меньше таких мест, тем лучше.
Сперва я подумал, что удачным названием для такой модели будет «островки интерактивности». Потом погуглил, и оказалось, что такое понятие уже есть. Тем не менее в этой статье всё равно упоминаются Preact, SSR, файлы манифеста, поэтому я не уверен, что мы говорим об одном и том же. Люди склонны всё излишне усложнять.
Но я верю, что сегодня у нас достаточно пропускной способности, чтобы загрузить небольшое приложение React, которое рендерит лишь островок интерактивности внутри классической страницы с отрисовкой на сервере. Не думаю, что это будет выглядеть как-то нелепо, но нужно ещё попробовать, чем я, возможно, займусь в своём следующем проекте.
Итак, мой непроверенный подход к получению чистого и обслуживаемого кода во фронтенде звучит как «Отрисовывай всё на сервере и подключай React только там, где это реально необходимо».
Хуже точно не станет.
Комментарии (57)
oliva80
13.07.2025 09:14создание интерактивного UI, где любой компонент может обновлять любой другой компонент, просто является одним из сложнейших аспектов в разработке
возможно, с помощью Redux или чего-то аналогичного, но здесь у меня недостаточно опыта
React+Redux для этого и существуют. на смену redux пришёл react context api, и неплохо с этим справляется.
Простота и польза React особенно видна в React Native, который упрощает и удешевляет мобильную разработку.
Эта штука прекрасна для своего класса задач!
от авторской критики веет безумием.. :)
tuxi
13.07.2025 09:14Просто в то время глазами бэкенд-инженера вся система Angular выглядела совершенно неадекватной.
Я думал, я один такой - несовременный и немодный и "молчал в тряпочку". Там где ssr "просто пушка", пихали одностраничники, и пока они были на стадии mvp все было прекрасно, стильно и модно. Но как только проходил год два три развития, этот одностраничник становился кошмаром.
PrinceKorwin
13.07.2025 09:14Вот мы имеем React, Vue, Angular и прочее. По каким критериям какой фреймфорк когда лучше применять?
Пример 1 - одностраничник на десяток кнопок и с пяток модальных окон
Пример 2 - приложение на десяток страниц + "динамические" страницы/репорты
Пример 3 - приложение на 50 страниц и дохренилион кнопок и компонент
kvd264
13.07.2025 09:14Я не настоящий фронтендер, но интуитивно Vue ощущается намного удобнее, проще и изящнее в любой из этих задач. Это ведь была эволюция. Сначала был JQuery. Парни из Google посмотрели на это безобразие и сделали Angular. Потом парни из Facebook посмотрели на безобразие под названием Angular и сделали React. Потом один чел из гугла снова посмотрел на всё это переусложненное безобразие и сделал Vue. Ещё Svelte развивался судя по всему примерно из тех же соображений. Судя по количеству головняка, в который необходимо вникнуть для работы с этими фреймворками, и все возрастающему удобству и красоте кода по хронологии их появления, на Ангуляре и Реакте люди пишут просто по инерции, т.к. они очень хорошо его изучили и на них создано много разных проектов. Если бы все эти фреймворки появились в один день, я думаю что подавляющее количество людей отдали бы предпочтение Vue.
А ещё на Vue можно просто сразу взять и писать, подключив его одной строчкой на страницу. Без монструозного и запутанного инструментария, тормознутой помойки под названием npm, кучи препроцессоров, системы/пайплайна сборки (конфиги которых передают по наследству, даже не пытаясь в них разобраться) и кучи доп. библиотек для совершенно базовых вещей.
Sadler
13.07.2025 09:14Исторически это немножко не бьётся, они появились примерно в одно время, но Vue тогда был сильно другим фреймворком по стилю. Vue 3, да, был рефлексией в т.ч. на сложности с React. После React я воспринимаю Vue как такой неплохой набор best practices в одном месте: как вы правильно отметили, можно сразу садиться и писать.
В React же я вынужден использовать собственный конструктор из пакетов и конфигов, который я наработал за годы. Но я его уже наработал, так что особых трудностей у меня это не вызывает. Сейчас поглядываю на какой-нибудь SolidJS: синтаксис реакт-подобный, много всего встроено, весьма быстрый. В теории выглядит хорошо, но ничего большого я на нём пока не писал, да и слишком молодой он, чтобы полагаться на него в больших проектах.
DmitryKazakov8
13.07.2025 09:14Solid вполне можно использовать, для простоты можно взять универсальную архитектуру, пример которой приводил здесь. Пока от него только приятные впечатления, если не нужна большая экосистема готовых компонентов. Но не стоит забывать, что на js до фреймворков было написано огромное количество библиотек (да и для Web Components сейчас), и если стереть с них пыль и обернуть в простой компонент - то Solid даже для средних по размеру проектов подойдет.
alexey_ym
13.07.2025 09:14Solid это Vue в фантике React'а минус virtual dom. Видимо, чтобы работягам на React проще было пересаживаться на что-то кошерное )
novaboreckii
13.07.2025 09:14Не от простой жизни на фронте существует тот же Angular. Фреймворк задает структуру и правила, при соблюдении которых в крупном проекте получается довольно неплохо бороться со сложностью и видеть все взаимосвязи. Плюсом также является наличие Typescript и наличие в компиляторе строгой проверки шаблонов. Таким образом весь код обложен всеми возможными видами поверок и уже на этапе компиляции можно отловить большинство багов. Также можно провести изменение на сотню или две файлов и быть уверенным что ничего не изменится. Конечно платим мы за это жутко костыльным механизмом change detection, но вроде с сигналами стало чуть полегече. Ну и справедливо это все для действительно сложных интерфейсов, например каким нибудь редактором дашбордов, тогда есть смысл платить эту цену, потому что в long-term это окупится.
Однако же замечу, что часть коллег из фронтенда пренебрегают жесткими настройками компилятора в угоду скорости. И тогда поддержка проекта после таких «разработчиков» превращается в серьезное испытание.
MadeByFather
13.07.2025 09:14Без монструозного и запутанного инструментария
Как раз у Vue инструментарий более монструозный, как минимум в силу того, что это фреймворк. Можете даже банально сравнить кол-во страниц в документации реакта и вью. Если из реакта "выкинуть" "легаси" про классы, SSR и хуки, которые опционально используются раз в сто лет, то это несколько страниц
тормознутой помойки под названием npm
...которая никак с реактом или вью не связана - и при этом вью точно так же его использует. Хотите меньше тормозов - yarn или pnpm
кучи препроцессоров
Которые настраиваются один раз или не настраиваются вообще, потому что есть готовые коробочные решения. Или вы думаете, что вью ничего не препроцессит?
системы/пайплайна сборки (конфиги которых передают по наследству, даже не пытаясь в них разобраться)
Сами написали рандомные конфиги, а виноват реакт
кучи доп. библиотек для совершенно базовых вещей
То есть буквально никакой разницы со вью нет, вы что там ставите внешние стейт менеджеры, клиенты для апи, валидации, дат, тестинга и т. п., что там
SergeyEgorov
13.07.2025 09:14React восхитителен! Он позволяет мне обходиться без ООП. Хуки исчерпывающий и потрясающе удобный инструмент обработки изменений состояний.
Alexufo
13.07.2025 09:14Мне кажется, вы троллите
SergeyEgorov
13.07.2025 09:14Я не троллю. Я искренне считаю React самым сбалансированным конструктивом для разработки фронтендов.
Surr1os
13.07.2025 09:14React никогда в жизни не подойдёт для крупного приложения, оно будет неподдерживаемым. И да, че то реакт отстал от angular в виде производительности и функционала)))))))))))
SergeyEgorov
13.07.2025 09:14React и Express два восхитительных в своей простоте инструмента, которые позволяют мне обходиться в остальном чистым Javascript без использования ООП.
Garutiunov
13.07.2025 09:14Это норма что под каждым постом или обсуждением реакта, есть человек который бесконечно спамит про свою библиотеку?
По теме: Реакт очень хорошая и удобная библиотека, просто многие люди заходя во фронт почему-то пропускают изучение JS, если к тебя хороший уровень JS в реакте ничего сложно не будет, хуки очень наглядные
Alexufo
13.07.2025 09:14Библиотека на самом деле хорошая, но Дима в силу каких-то особенностей не считывает как воспринимается его поведение и закапывает этим ее. Он от этого и по жизни страдает (как я это вижу, наблюдал со стороны).
vitaliy2
13.07.2025 09:14Теоретически иногда бывает примерно такая ситуация:
Ты сделал хорошую программу.
Выложил на GitHub.
Прошёл год, а эту страницу на GitHub'е никто даже не посетил, кроме тебя.
Наверное, автор попал в подобную ситуацию.
kotan-11
13.07.2025 09:14Да такое бывает, ты придумал и сделал пироженку, угостил окружающих, но все стройными рядами проходят мимо и идут есть кактус. И что тогда делать?
dv0ich
13.07.2025 09:14Задаться вопросом, правильно ли у тебя с восприятием мира, действительно ли это пироженка и кактус :)
Alexufo
13.07.2025 09:14Перестать бегать по кругу, сообщая всем, что более развитый инженерный подход это единственное, что им нужно.
Ты не мега корпорация, которая прикрывает собой поддержку фреймворка, который ты обязательно выбрал по ошибке, потому что вот сосед как-то всегда круче.
Весь твой ресурс - это твой интерес к твоему детищу. Единственная возможность популярности - набрать комьюнити, которое примет тебя.
У нас есть пример более менее международного и популярного Yii который подхватили у нас в РФ и который мейнтейнил и пиарил Александр Макаров после того как проект покинул основатель (охладел к php). К Саше как к лицу фреймворка вопросов нет вообще, очень грамотно работает с токсичными вопросами (моими) и аудиторией. Пусть они так медленно шли что фронтенд в целом две революции совершил, но они ведут себя правильно.
У нас есть VUE, который вышел тоже из одних рук и который обрек популярность, за Эваном я не следил, но, как я понимаю, он успешно себя подает как успешного (семья, дети, vue) самодостаточного, цельного, уверенного и гениального разработчика.
Он посветил Vue фуллтайм (вроде), вроде живет на поддержку $ того комьюнити, которое сформировал своим жизненным путем.
И у нас есть б*ть $мол. Яндекс не осилил,а Карловский осилил, но который "ты просто не компетентный, открой глаза, сколько можно есть кактус, да реакт выбирают только д*ебы, даже vue лучше"
Это какая-то не проработанная травма чтоли.. или это наше желание быть услышанными, любимыми, признанными. Или желание сломать и начать строить заново и вот теперь то уж точно правильно... просто надо дуракам объяснить что они дураки.. я не знаю, ну это точно не рабочий вариант. Здесь только строить секту в хорошем смысле как Эван сделал и Макаров (ушел отец-мейнтейнер? Ну и что? Вы же прекрасно видите, что это пример того что прекрасные продукты продолжают жить на поддержке самостоятельно).
cmyser
13.07.2025 09:14Это фреймворк, не библиотека, очень стоит почитать, очень много здравых идей и решений которые кучу проблем решают
nin-jin
13.07.2025 09:14Так как @moderator поудалял все мои комментарии, внесу ясность по поводу "спама". Комментариев было 5:
Про Объектное Реактивное Программирование, которое один из комментаторов не пробовал, а потому нагородил чуши. $mol, разумеется, основан на идеях ОРП, но акцент тут был вообще не на нём.
Объективный ответ на вопрос что лучше для каких кейсов, c аргументацией и ссылками на пруфы. Только тут было про $mol.
3 шортса опровергающие тейки местных фанбоев реакта про его неимоверное удобство и простоту. Про $mol тут не было ни слова.
Ну а так как Хабр - торт, а не место для дискуссий, то перечисления пунктов правил, которые я нарушил своими вопиющими комментариями, конечно же не будет.
nin-jin
13.07.2025 09:14
Вот это репрессии! А потом они ещё обижаются, когда их идиотами называешь...
trinxery
13.07.2025 09:14/me гадает, забанят ли Дмитрия за виртуаловодство.
Hidden text
Можно заметить, что ссылка ведёт на Geektimes. Почему? Потому что при простой ссылке на профиль текст ссылки ("виртуаловодство") игнорируется и ставится текст "@vintage". Если ставить на habrahabr.ru, то то же самое. А вот про Geektimes разработчики забыли.
TrueRomanus
13.07.2025 09:14И всё это прекрасно работает в случае простых приложений, но можете себе представить кошмар с обслуживанием, возникающий при создании крупных программ. И винить нужно не jQuery, а аппетиты современных пользователей, которым повсюду требовалась эта интерактивность. В итоге разработчики были вынуждены продолжать использовать jQuery, несмотря на то, что этот инструмент перестал быть удачным выбором для текущих задач.
Могу сказать как человек который начал участвовать в проектах с очень толстым фронтом даже еще до появления jQuery (когда он вышел он прям таки нехило помог нашему тогдашнему проекту монстру с которым мы работали стать кроссбраузерным и слезть с иглы ie6) что реализовать проекты любой сложности можно на чем угодно, главное это прямые руки и склонность команды к борьбе с техническим долгом. А тем более сейчас когда технологий навалили в фронтэнд так много что можно выбирать и это не выбор только из большой тройки, библиотек/фреймворков/встроенный решений полно.
Format-X22
13.07.2025 09:14так что Angular не только первым предоставил нам набор функций, но и стал реальным фреймворком, на котором можно было создать веб-приложение.
Вообще-то был уже ExtJS. Он стал фреймворком ещё до того как в JS классы появились. Там из коробки было столько всего, сколько ещё потом десять лет в другие завозили. А умер он потому что 5к баксов за лицензию на человека в год и отсутствие перехода на ES6 классы в своё время.
Автор либо слишком молод, либо тогда не интересовался всем этим.
olku
13.07.2025 09:14Умер? До сих пор то там то сям его встречаю. С популярностью Реакта не сравнить, но версии релизят.
Unnemed112
13.07.2025 09:14Большинство людей которые пишут на реакте не понимают что это именно библиотека для отображения UI. Из за того что у них нет технического бекграунда(в большинстве своем это именно так и есть, реакт выбирают вкатуны из за низкого порога входа). Если вы хотите реализовать MV* паттерн, то нужно понять что реакт это именно V, т.е. в компоненты должны прилетать уже готовые данные. И многие не понимают как все собрать в кучу и делают все что предлагает npm. следовательно проект превращается в кладбище пакетов и жирнущую реализацию flux архитектуры, поверх которой накрутили уже всяких FSD, Atomic design и т.п.
Что бы избежать всего этого ужаса, достаточно чуть чуть пораскинуть мозгами и почитать умных книжек. К примеру, для реализации mvvm паттерна, можно взять сигналы или rxjs, написать хук биндер, который свяжет стейт jsx и данные модели и будет вам счастье. вы сможете писать отдельно бизнеслогику не перегружая реакт. Добившись того что большая часть проблем описанных в статье просто пропадетnicknamenull
13.07.2025 09:14rxjs
А это точно удобно и просто?
сигналы
Это те самые, которые во вью уже много лет имеются, причём более жирные по функциональности, но в остальных экосистемах выдаются за инновацию?
Altear
13.07.2025 09:14Честно говоря, доводы у автора какие-то сомнительные.
Автор упоминает Redux, но говорит, что в него не углублялся. Далее продолжает осуждать передачу состояния через контекст. При этом, тот самый менеджер состояния (Redux, Mobx и другие) забирает на себя большую часть бизнес логики. Запросы, синхронизации и т.д. Оставляя самим компонентам только переменные ВИЗУАЛЬНОГО состояния. Которые либо вообще не пробрасывются в детей, либо опускаются только на один уровень. Вот тебе и разделение на View и Model.
Проектируюя фронтовое приложение (а не страничку) не получится ограничится только лишь одним реактом. Либо тебе придется писать компоненты высокого уровня, следиться за провайдерами и перусложнаять код.
Но автор опускает эту тему, пытаясь вилкой съесть гороховый суп.
Но в конце статьи, автора задаёт вопрос: " а зачем нам вообще нужен гороховый суп, если можно уменьшить количество ингредиентов и будет вкусный свежий горох без бульона"
Согласен с автором, что если у тебя простейший одностраничник - можно вынести всю логику на бек. Но современные интерактивные web приложения в таком подходе проиграют, потому что пользователь зажрался. Пользователю нужна интерактивность, попапы, UI как на мобиле и чтобы все светилось. Но. Пользователь платит деньги. И он будет платить тем, у кого удобнее и красивее.
Вот и получается, что менеджеры ничего не понимают, им нужно больше кнопок, но приложение, которое делает всё понимающий разработчик с одной кнопкой - никто не покупает.
Фронт и правда переусложнен. НО React это не весь фронт. Это библиотека которая хорошо делает свое дело в создании реактивности.
А вот пихать в него бизнес логику, это уже пытаться есть гороховый суп вилкой.
Могу быть где-то не прав, но это лично мой взгляд на ситуацию с позиции React разработчика.
nicknamenull
13.07.2025 09:14А хорошо ли? JSX - это неудобно, давайте будем честны. Он нужен в одном компоненте из тысячи, когда требуется действительно сложный процедурный рендеринг, в остальных случаях приходится жить со стрёмным синтаксисом и кривыми идиомами. Только условный рендеринг на JSX чего стоит.
Про экосистему отдельный разговор вообще. Наличие обширной экосистемы, когда приходится каждый раз заново выбирать из пятёрки одних только стейт менеджеров, не говоря уже об остальных библиотеках, без которых приложение не получится собрать - это, скорее, минус, чем плюс.
Ну и реактивность, которая отваливается по поводу и без, тоже удобства не добавляет.
artptr86
13.07.2025 09:14В SolidJS, например, переосмыслили JSX. Там и для условного рендеринга, и для итерирования предлагаются специкомпоненты как раз для изкоробочной поддержки реактивности. То есть фактически не JSX неудобен сам по себе, а его реализация в React, хоть они его и придумали.
Cere8ellum
13.07.2025 09:14Я наоборот, люблю React. Прост, удобен, понятен, гибок. Причём я не супер крутой спец и много ещё не (идеально) понимаю. Вот Ваш пример с useEffect. Одно вызывает другое, потом третье, потом четвертое. Ну и что в этом плохого? Можно вызвать хоть 100 раз в одном компоненте и они всегда будут ожидаемо вести себя и влиять на состояние и.т.п. Резюмируя, есть простота использования при некотором хаосе под капотом. Главное с пониманием использовать те или иные решение, как и везде впрочем.
PrinceKorwin
13.07.2025 09:14Со своей стороны могу сказать, что мне, как новичку в UI больше зашел Vue чем React.
Причины простые - тут простой шаблон на базе привычного HTML, привычный CSS, привычный JavaScript. Из коробки есть все нужные кубики и не нужно заморачиваться ни с какими либами/зависимостями.
Кривая входа в React выше и пока не понятно какой профит в итоге от этого будет.
Sadler
13.07.2025 09:14Профит только в том, что эти кубики заменяемы по усмотрению, т.е. гибче. Но это же и недостаток: сторонние либы регулярно устаревают: либо всё через адаптеры, либо регулярно будешь бегать и чинить несовместимости. Особенно весело, когда какой-нибудь react-router в очередной раз решает поменять форму записи своих роутов, и ты как дурак носишься по всей иерархии маршрутов и переписываешь, потому что чувство прекрасного у автора либы взыграло, и он решил всё переназвать.
Cere8ellum
13.07.2025 09:14Не понял про "бегаешь и переписываешь все маршруты". Их же можно хранить в отдельном файле/классе и править лишь в нём. Ну и с кастомными либами просто чуть избирательнее быть. Зачастую можно (лучше) обойтись своими решениями, чтобы не зависеть от чего-то шаткого. Вопрос архитектуры. Просто мнение, не спорю...
Sadler
13.07.2025 09:14Это у Вас Nested Routes не было. Не всегда проект настолько мал, что он хранится в одном репозитории, не всегда настолько статичен, что все роуты можно прописать в одном файле. Более того, разными модулями занимаются разные люди.
Cere8ellum
13.07.2025 09:14И всех этих людей нужно организовать так, чтобы работали в едином ключе. С одним единственным репозиторием роутов. Вот просто, как предложение. Можно же так сделать?
Sadler
13.07.2025 09:14Не знаю, в одном из моих проектов это не так. Я такой же программист, а не их начальник, организовывать их -- не моя работа :)
nicknamenull
13.07.2025 09:14Ого, спустя десять лет об этом наконец можно говорить и не бояться получить ушат помоев только за то, что мнение отличается от мейнстримного нарратива от евангелистов и смузихлёбов, мол, реакт - это для beautiful complex awesome projects, а вот всё остальное - это плохо.
Если уж говорить о фреймворках, то Vue, начиная со второй версии, в любой момент своей жизни был на голову выше, чем конкурирующие фреймворки. О чём говорит хотя бы тот факт, что ангуляр и реакт пережили по три смены парадигмы и паттернов, в то время как Vue пережил одну, и то с сохранением обратной совместимости. При этом по удобству использования ни реакт, ни ангуляр не приблизились к вью.
nin-jin
13.07.2025 09:14К слову, фреймворк, который тут нельзя называть, но у которого есть свой отдельный хаб, за 10 лет не потребовал ни одной смены парадигмы, но до сих пор является более прогрессивным. У меня даже есть сравнительная табличка кто у кого когда что потырил из фичей, а что до сих пор не осилил. Но пруфов не будет, за них банят.
acsent1
Я вот одного не понял: почему отказались от классов? Не уж то классы в js так тормозят, что что использование всяких мемо для функций и переменных выходит дешевле
Sadler
Нет, производительностью самой системы классов на данном этапе для большинства нормально написанных проектов можно пренебречь. Я думаю, что основной причиной послужило желание избавиться от наследования и иерархии классов, которые в ООП создают самый большой объём сложности. За это мы заплатили отсутствием встроенного стейта и необходимостью использовать хуки, соблюдать правила хуков, иметь ту самую неочевидную последовательность исполнения.
Лично я не знаю одного идеального способа разработки, я писал свои проекты очень по-разному, и везде есть плюсы и минусы. Большинство программ стремится либо к "морю акторов" (много мелких блоков/функций/компонентов, взаимосвязи которых сложно проследить), либо в "монолит" (одно большое неделимое ядро со сложным, почти неопределённым состоянием и его обвязка). Всегда выбор сводится к тому, предпочитаем мы терпеть объёмную или концептуальную сложность кода. Всегда приходится прикладывать чудовищные усилия, чтобы проект представлял собой прозрачные взаимодействия фиксированного количества акторов, и в процессе роста он всё равно будет стремиться в одно из вышеописанных состояний, какой бы парадигма ни была.
gsaw
Мне лично нравится простота функциональных компонент. Как то понятнее, что-ли. Вот есть функция, которая возвращает компонент и все. Все на виду, в определенной последовательности. С классами весь код получается размазанным, там дефолтные параметры, там Стейт, там загрузка данных, в углу функция отрисовки опять же. Прочесть код класса сложнее кмк.
js2me
Вот есть функция Component, которая вызывает ещё функции use*, которые вызывают ещё функции useHook, внутри которых вызываются ещё другие функции useHookN…
gsaw
Я лет 15 назад был в проекте. Сервер, на Си. Там функции были на несколько страниц, в функциях были запросы к базе и ветвистая логика. Да и сами файлы были на 15к и больше строк. Там черт ногу сломишь. Проект был запущен, большая текучка. Я и сам сбежал от туда. Так вот я к чему.
Ведь такие огромные методы, не значит же, что Си плохой и с С++, с классами получилось бы лучше. Я думаю имели бы громадные классы на 15к строк и методами на три страницы.
Если писать по фэншую, придерживаться clean code. Не писать компоненты на десять страниц и на все случаи жизни, то вполне себе можно обойтись минимумом хуков.
ant1free2e
перерисовки реакта т.е. повторный вызов кода скорее всего приводят к дрочеву памяти(а если есть утечки к быстрому ее исчерпанию) и логики, которая может быть написана в конструкторах
js2me
Смею предположить, что основная причина отказа от классов было нежелание изучать и/или внедрять ООП подход