Недавно работал над хобби-проектом, который описал в другой своей статье. В процессе его реализации у меня возникло желание чиркануть пару абзацев о том, почему 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 только там, где это реально необходимо».
Хуже точно не станет.
Комментарии (142)
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 все было прекрасно, стильно и модно. Но как только проходил год два три развития, этот одностраничник становился кошмаром.
mayorovp
13.07.2025 09:14Это всё потому, что клиентские компоненты к чисто серверному рендеру подключаются просто ужасно, а без них уже и сайт не сайт.
Вот если бы что-то вроде https://stimulus.hotwired.dev/ появилось не сейчас, а одновременно с первым поколением клиентских фреймворков...
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
кучи препроцессоров
Которые настраиваются один раз или не настраиваются вообще, потому что есть готовые коробочные решения. Или вы думаете, что вью ничего не препроцессит?
системы/пайплайна сборки (конфиги которых передают по наследству, даже не пытаясь в них разобраться)
Сами написали рандомные конфиги, а виноват реакт
кучи доп. библиотек для совершенно базовых вещей
То есть буквально никакой разницы со вью нет, вы что там ставите внешние стейт менеджеры, клиенты для апи, валидации, дат, тестинга и т. п., что там
RulenBagdasis
13.07.2025 09:14Или вы думаете, что вью ничего не препроцессит?
Vue прекрасно работает вообще без сборки, npm и т.д. Особенно, когда речь про небольшие приложения на несколько страниц.
вы что там ставите внешние стейт менеджеры
vue reactive state доступен из коробки, ничего ставить не надо. Для небольших приложений на несколько страниц этого более чем достаточно.
kvd264
13.07.2025 09:14Я не спорю, при желании или необходимости на Vue также можно навесить что угодно. И повсевместно навешивают. И я не утверждаю, что это всегда плохо.
Я пишу о том, что очень ценю лаконичность, а именно - возможность написать в <head>:
<script src="https://unpkg.com/vue@3/dist/vuпe.global.js"></script>И полноценно использовать возможности Vue на странице. Есть способы сделать так и для React, но выглядит и ощущается это как грязный хак, а не нормальный сценарий его использования для небольших проектов.
И мне при таком сценарии использования не нужно, чтобы написанный мной код транспилировался/препроцессился каким либо внешним инструментом. Я просто нажимаю "сохранить" - и оно работает.
Там, где 95% разрабов на реакте будут использовать какой-нибудь Axios (хотя вроде бы никто не заставляет, но это почему-то распространено повсеместно), я просто возьму ванильный fetch.
И мне не нужно при этом тащить аналог Redux для нормального и удобного управления состоянием. Я понимаю, что React по своей философии в первую очередь о компонентах, а не о маршрутизации событий и управлением состоянием приложения. Но где компоненты - там рядом всегда логика их взаимодействия. У React эта важная и неотъемлемая часть прикручена будто бы сбоку.
MadeByFather
13.07.2025 09:14Если у вас приложение, где вы вместо сборки вставляете standalone скрипт в хедер, то вообще не вижу смысла это обсуждать, это даже не пет-проект, а страница с двумя кнопками, там вы можете хоть на чистом HTML и JS в одном файле написать и вам вообще ничего не нужно
Там, где 95% разрабов на реакте будут использовать какой-нибудь Axios (хотя вроде бы никто не заставляет, но это почему-то распространено повсеместно), я просто возьму ванильный fetch
Каким образом связан react и axios? Почему на реакте нельзя написать ванильный fetch?
И мне не нужно при этом тащить аналог Redux для нормального и удобного управления состоянием
И мне не нужно при этом тащить аналог Pinia для нормального и удобного управления состоянием
markelov69
13.07.2025 09:14Пример 1 - одностраничник на десяток кнопок и с пяток модальных окон
React + MobX
Пример 2 - приложение на десяток страниц + "динамические" страницы/репорты
React + MobX
Пример 3 - приложение на 50 страниц и дохренилион кнопок и компонент
React + MobX
nin-jin
13.07.2025 09:14Вы с этим поосторожней, молодой человек, а то и вам личку заблокируют.
Или её блокируют только если ты подкрепляешь свои слова аргументами?
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 в виде производительности и функционала)))))))))))
Sorcer
13.07.2025 09:14Ну да ну да... завтро скажу команде на работе, а то 5 лет разработки ентерпрайс апсы с 128 сервисами надо сварачивать, поддерживать нельзя... react + class component+ mobx, новые разделы функции+хуки, часть старых так и останется, часть переписывается аишкой за короткое время.
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 лучше"
Это какая-то не проработанная травма чтоли.. или это наше желание быть услышанными, любимыми, признанными. Или желание сломать и начать строить заново и вот теперь то уж точно правильно... просто надо дуракам объяснить что они дураки.. я не знаю, ну это точно не рабочий вариант. Здесь только строить секту в хорошем смысле как Эван сделал и Макаров (ушел отец-мейнтейнер? Ну и что? Вы же прекрасно видите, что это пример того что прекрасные продукты продолжают жить на поддержке самостоятельно).
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 разработчики забыли.
green_fenix
13.07.2025 09:14Только реакта? :D
Мистер nin-jin занимается этим уже очень давно, мною воспринимается уже как традиционная часть хабра. В каком-то смысле его подход даже работает - про $mol я теперь отлично помню. Использовать правда я его конечно не буду. Но про его существование помню!
TrueRomanus
13.07.2025 09:14И всё это прекрасно работает в случае простых приложений, но можете себе представить кошмар с обслуживанием, возникающий при создании крупных программ. И винить нужно не jQuery, а аппетиты современных пользователей, которым повсюду требовалась эта интерактивность. В итоге разработчики были вынуждены продолжать использовать jQuery, несмотря на то, что этот инструмент перестал быть удачным выбором для текущих задач.
Могу сказать как человек который начал участвовать в проектах с очень толстым фронтом даже еще до появления jQuery (когда он вышел он прям таки нехило помог нашему тогдашнему проекту монстру с которым мы работали стать кроссбраузерным и слезть с иглы ie6) что реализовать проекты любой сложности можно на чем угодно, главное это прямые руки и склонность команды к борьбе с техническим долгом. А тем более сейчас когда технологий навалили в фронтэнд так много что можно выбирать и это не выбор только из большой тройки, библиотек/фреймворков/встроенный решений полно.
novaboreckii
13.07.2025 09:14Согласен по первой части. Работал на проекте с angular 7, который мне достался в наследство от другой команды. Компоненты по 3к строк, 5000 any в проекте, неявные изменения состояний через мутации - настоящий ад. Хотя сам angular изначально бьет по рукам, задает структуру и по дефолту включена тонна проверок. Но вот кривые руки решили все это отключить, потому что им было лень писать типы и разбираться в ошибках компиляции. Был и обратный пример - проект на angular Js без typescript. Был написан в 2014 году где-то, попал ко мне на поддержку в 2022. Хоть и ts нет, es5 во всей красе - но все было понятно, потому что были нормально выделены домены, все аккуратно разложено по сервисам и компонентам. И с этим проектом было на порядок легче, чем с первым.
Со второй частью не совсем соглашусь - чем специфичней технология, тем больше рисков. Не найти разработчиков, кто бы согласился с этим работать. Какие-то баги, которые всплывают в самые неподходящие моменты, а создатель библиотеки уже давно забил на свое детище. Отсутствие или неполная документация. Все это сильно влияет на стоимость решения и его поддержки.
TrueRomanus
13.07.2025 09:14Со второй частью не совсем соглашусь - чем специфичней технология, тем больше рисков. Не найти разработчиков, кто бы согласился с этим работать. Какие-то баги, которые всплывают в самые неподходящие моменты, а создатель библиотеки уже давно забил на свое детище. Отсутствие или неполная документация. Все это сильно влияет на стоимость решения и его поддержки.
Этими симптомами страдают все технологии даже те которые сегодня на хайпе завтра могут пасть в забвение, такое происходит постоянно. К тому же как именно пользуются библиотеками и фреймворками это тоже лютая специфика на конкретном проекте. Например я работал на трех проектах с Vue и казалось бы одна библиотека и все должно быть одинаково но нет каждый проект сделан по своему со своими приколами и своими фишками а текущий проект в котором я участвую вообще на Vue3 где все очень сильно поменялось в самом фреймворке.
Format-X22
13.07.2025 09:14так что Angular не только первым предоставил нам набор функций, но и стал реальным фреймворком, на котором можно было создать веб-приложение.
Вообще-то был уже ExtJS. Он стал фреймворком ещё до того как в JS классы появились. Там из коробки было столько всего, сколько ещё потом десять лет в другие завозили. А умер он потому что 5к баксов за лицензию на человека в год и отсутствие перехода на ES6 классы в своё время.
Автор либо слишком молод, либо тогда не интересовался всем этим.
olku
13.07.2025 09:14Умер? До сих пор то там то сям его встречаю. С популярностью Реакта не сравнить, но версии релизят.
via-site
13.07.2025 09:14Тоже помню этого "монстра". Хотя я в 2014 только начинал, когда заглянул в генерируемый им код, то сразу понял что страдать поддерживая это безумие лично я не буду. У простой кнопки вложенность как у настоящей мартешки. Вот именно тогда я познакомился с понятием "ООП головного мозга".
Format-X22
13.07.2025 09:14А чем это хуже вложенности компонентов? Просто вместо функций классы. Можно сказать что стейта нет расшаренного, но вот статья говорит что всё тоже самое.
Там вложенность была потому что каждый уровень что-то давал и при создании своего компонента можно было выбрать на сколько низкоуровнево или высокоуровнево ты хотел иметь в базе. Самый низкий уровень - обертка над хтмл с шаблонизатором, почти JSX. Выше обычно уже уровень UI с конфигурацией, так называемые компоненты. Далее докидываешь миксины типа эвент-эммитерра и прочего, но если нужно. Дальше были всякие контейнеры или кнопки. Но были и ещё более составные - панель, которая имела контейнер в середине и бары по краям с кнопками. Ну и всякие там ресайзы, тоглы и всё чего надо. Только вместо JSX объекты-конфиги JS. Не так красиво, но и отдельный язык не нужен, ни какой транспиляции и прочего. До появления ES6 было неплохо.
По факту концептуальная идея та же. Кстати, там была возможность выбирать тип биндинга - MVC, MVVM. Можно было по олдскулу на эвентах. Также можно было пропсы прокидывать.
Но уровень входа был резко сложным, это одна из причин смерти. Хотелось брать и просто писать UI, с ходу. А ExtJS надо было изучать сидеть долго. Так ещё и скачать бесплатную версию сложновато было, ну и вырезание платных функций из бесплатной документации это прикол. Фреймворк убил менеджмент. Сейчас оно живое, но это зомби.
Unnemed112
13.07.2025 09:14Большинство людей которые пишут на реакте не понимают что это именно библиотека для отображения UI. Из за того что у них нет технического бекграунда(в большинстве своем это именно так и есть, реакт выбирают вкатуны из за низкого порога входа). Если вы хотите реализовать MV* паттерн, то нужно понять что реакт это именно V, т.е. в компоненты должны прилетать уже готовые данные. И многие не понимают как все собрать в кучу и делают все что предлагает npm. следовательно проект превращается в кладбище пакетов и жирнущую реализацию flux архитектуры, поверх которой накрутили уже всяких FSD, Atomic design и т.п.
Что бы избежать всего этого ужаса, достаточно чуть чуть пораскинуть мозгами и почитать умных книжек. К примеру, для реализации mvvm паттерна, можно взять сигналы или rxjs, написать хук биндер, который свяжет стейт jsx и данные модели и будет вам счастье. вы сможете писать отдельно бизнеслогику не перегружая реакт. Добившись того что большая часть проблем описанных в статье просто пропадетnicknamenull
13.07.2025 09:14rxjs
А это точно удобно и просто?
сигналы
Это те самые, которые во вью уже много лет имеются, причём более жирные по функциональности, но в остальных экосистемах выдаются за инновацию?
acsent1
Я вот одного не понял: почему отказались от классов? Не уж то классы в js так тормозят, что что использование всяких мемо для функций и переменных выходит дешевле
Sadler
Нет, производительностью самой системы классов на данном этапе для большинства нормально написанных проектов можно пренебречь. Я думаю, что основной причиной послужило желание избавиться от наследования и иерархии классов, которые в ООП создают самый большой объём сложности. За это мы заплатили отсутствием встроенного стейта и необходимостью использовать хуки, соблюдать правила хуков, иметь ту самую неочевидную последовательность исполнения.
Лично я не знаю одного идеального способа разработки, я писал свои проекты очень по-разному, и везде есть плюсы и минусы. Большинство программ стремится либо к "морю акторов" (много мелких блоков/функций/компонентов, взаимосвязи которых сложно проследить), либо в "монолит" (одно большое неделимое ядро со сложным, почти неопределённым состоянием и его обвязка). Всегда выбор сводится к тому, предпочитаем мы терпеть объёмную или концептуальную сложность кода. Всегда приходится прикладывать чудовищные усилия, чтобы проект представлял собой прозрачные взаимодействия фиксированного количества акторов, и в процессе роста он всё равно будет стремиться в одно из вышеописанных состояний, какой бы парадигма ни была.
powerman
Интересно, что никто, похоже, не задумывается, почему всех этих проблем нет на бэке. Отговорка с "много входов/выходов" тут не очень работает, потому что практически на все ваши фронтовые входы есть соответствующие им входы в API бэка. Этот API нередко очень объёмный, и, как и на фронте, в конечном итоге влияет на некое очень большое состояние (БД), иногда разделённое между компонентами (микросервисами), иногда монолитное. В общем, параллели довольно очевидные, а вот такой боли (и заодно непрерывного мелькания инструментов/библиотек/фреймворков) как на фронте - нет. Причём этого нет вне зависимости от используемого ЯП бэка (может, за исключением ноды, там теоретически должно мелькать примерно то же, что и на фронте, но это результат того, что вы в каком-то смысле "взяли фронт и запустили его на бэке" как раз для того, чтобы не использовать штатные технологии и ЯП бэка - так что это особый кейс и его в текущем контексте обсуждения можно игнорировать).
Идея автора статьи рендерить часть UI на бэке выглядит рабочей, но он тоже не задаётся вопросом "а почему выполнить ровно эту же самую работу на бэке не является настолько же сложным, как на фронте - ведь работа-то в конечном итоге одна и та же".
Лично я предполагаю, что ключевой частью ответа на этот вопрос может быть "дисциплина". На бэке принято соблюдать длинный список ограничений, к которым мы настолько привыкли, что для многих "так было всегда" и они их даже не воспринимают как что-то особенное. Например, на бэке никто не делает свои БД. В смысле, чтобы вот у каждого проекта была своя уникальная БД - такого нет. А ведь когда-то такое было нормой, и я даже эти времена ещё немного застал. Но уже нет. Есть SQL, есть NoSQL, есть message brokers, есть K/V кеши - все они накладывают свои ограничения, но мы всё-равно берём кого-то из них а не пишем своё хранилище состояния приложения. Любые глобальные переменные вызывают нервный тик, даже если это "просто" конфигурация или логгер. Чуть менее очевидные/однозначные примеры включают в себя чистую/гексагональную архитектуру (100% изоляцию бизнес-логики от внешнего мира для простой тестируемости), модульную/микросервисную архитектуру (тут фишка в том, чтобы адекватно спроектировать архитектуру, чтобы размер этих модулей был и не очень мелким и не очень крупным плюс удачно соответствовал границам транзакций и UX-ожиданиям консистентности - для этого придумали стратегические паттерны DDD). Чуть более очевидный пример - на бэке в принципе считается нормальным сначала сделать архитектуру и уделять ей много внимания, даже если это блокирует новые фичи. А ещё - на бэке считается нормальным говорить "НЕТ" в ответ на пожелания бизнеса (это примерно то же, что рекомендует автор статьи в контексте "делайте меньше кнопок"): "нет, это работать не будет", "нет, это слишком сложно реализовать и мы в этом утонем", "нет, это будет архитектурная дыра в безопасности", … много разных "нет". И хотя за некоторыми из них может скрываться "нет, мне лень это делать", сам факт что бэк умеет говорить "нет" имеет значение!
nin-jin
Ну я вот пилю своё хранилище, где не нужны ни SQL, ни message brokers, ни K/V кеши, но я вам его не покажу, а то ещё больше забанят личку.
Sadler
На бэке просто уже есть наработанный набор инструментов, в т.ч. БД, которые уже отлично решают задачу хранения больших массивов данных. Теоретически, на фронт тоже можно затащить чисто клиентскую БД вместо ручной обработки и фильтрации данных, и завязать реактивность на неё, и даже можно бинарные блобы выгружать куда-нибудь в localStorage, но всё это настолько редкие и нишевые решения, что ими можно пренебречь. Да и задачи разные, не будут те же инструменты так удобны на фронте. Собственно, все стейт-менеджеры, в какой-то мере и являются простым аналогом базы данных для хранения данных и обновления UI.
Особенно весело, что из дисциплинированности бэка вытекает, что я, нажав Alt+Tab, становлюсь мгновенно более дисциплинированным, и наоборот.
powerman
Есть вероятность, что задачи просто кажутся разными. Иначе почему перенос рендеринга на бэк обычно всё заметно упрощает? Я допускаю, что ключевое различие между задачами, из-за которого они и воспринимаются "разными", заключается как раз в дисциплине: на фронте задача "сделать что сказал продакт", а на бэке задача "сказать продакту что мы можем и чего не можем сделать".
Собственно, на бэке вполне долго и упорно пытались писать без оной дисциплины, послушно делая всё, что просил бизнес. Как правило, всегда получали в результате "большой комок грязи" и необходимость переписывать проект с нуля. Этот подход просто не работает, особенно если проект изначально сложный или его нужно много лет развивать.
Ну, я говорю о дисциплине "в среднем по индустрии". Отдельные разработчики могут значительно от этого среднего отличаться. Но и как Вы говорите тоже часто бывает: на бэке строгая типизация, линтеры и свои правила/best practices и подходы к разработке/тестированию/отладке/мониторингу, а на фронте всё это совсем другое. И один и тот же человек вполне может писать один проект чисто и соблюдая кучу ограничений и при этом параллельно писать другой на другом языке быстро-грязно.
NyarukouSAMA
Погодите, а как же redux, который как раз выполняет функцию хранения данных. Мне вообще довольно сложно представить использование реакта без связки с редаксом. А многокомпанентная архитектура позволяет выстраивать кусочки данных в эти компоненты, таким образом мы же вполне можем свести все к очень не большому набору (если вообще не единичному вызову useEffect). Но в целом, я думаю согласится с автором можно. На бэке люди более дисциплинированны, потому что есть компилятор как минимум, который тебе скажет, почему ты чудак на букву м. А есть ещё всякие штуки, которые проверяют codesmells, типа sonarcube-а. В js этого изначально не было. Транспиляция согласно некоторым правилам появилась только вот в angular 2/react-е. А щас есть typescript и возможность писать реактивные компоненты на нем. Использование ts в свою очередь накладывает свои правила. А есть ещё js стандарты и паттерны, которые ты можешь заставить использовать в проекте подключи библиотеку контроля codesmells (забыл как называется). Просто вся эта дисциплина она не сразу же появилась в случае с бэкендом, в том числе умение говорить нет, ну или хотя бы предупреждать, что мы можем, но потом у нас всех будут большие проблемы с поддержкой и вам придётся заплатить крупную сумму за разработку и сопровождение. Упоминание крупных сум иногда действует на бизнес довольно отрезвляюще. Мне кажется это все дело времени. Пока во фронте не устаканится какие-то bestpractises, не наработаются шаблоны проектирования, пока разработчики и инструменты под них подстроятся... Все это требует времени.
Kerman
На бэке нет гуя. Если копнуть тот же шарп у него есть mvvm, который вырождается в реактивную ахинею со временем и очень сложно отследить, что как и куда меняет во вьюмодели и в какое место вью это полетит. Есть винформс, где сложность вырождается в кучу методов, которые по событию пытаются привести гуй в актуальное состояние.
В запущенных случаях и то и то ужасно. А чтобы держать в порядке, надо переосмысливать сам дизайн гуя, подходы к подаче инфы да и вообще весь UX.
Так что моё подозрение в том, что сложность возникает после работы с интерфейсом нескольких команд с разными целями в течении долгого времени.
nin-jin
Если использовать Объектное Реактивное Программирование, то никаких проблем с пониманием потоков данных по коду нет вообще. Так что проблема определённо не в гуях, а в инструментах для них не пригодных.
Kerman
Ну не бывает волшебных библиотек, которые решают всё. И технологий таких нет. И подходов, хотя они называются "серебрянными пулями". Ну допустим один подход работает лучше другого. В UI ад и израиль, но вот сейчас вытягивает. А потом приходят эффективные совы и в клювике приносят новые правки гуя. И волшебная библиотека говорит "кря". Потому что надо UI перепроектировать, а не кровати двигать, вот что.
powerman
Это довольно очевидный, напрашивающийся… но, вполне возможно, некорректный ответ.
Я не буду спрашивать в чём принципиальное отличие GUI от TUI и CLI (которые на бэке есть). Я спрошу другое: а как же условный Web 1.0? Ровно тот же HTML+CSS+JS, но рендеринг полностью на бэке - чем это не GUI? И окажется, что отличие тут ровно в том, о чём я писал - в ограничениях и дисциплине. Условно можно считать, что во времена Web 1.0 мы говорили продакту "нет, мы не сделаем SPA, а будем рендерить всё на беке, и страничка у юзера будет постоянно перечитываться". И никаких сопоставимых с текущей ситуацией на фронте сложностей при этом не возникало. (Подсказка: в случае TUI и CLI всё выглядит очень похоже - и там и там есть куча ограничений, которые приходится соблюдать, которые создают кучу неудобств и для пользователей и для разработчиков этих UI, но зато код получается вполне умеренной сложности.)
Kerman
Вот и ответ. Бэк рендерит ровно один стейт, а не следит за связностью какая кнопка тебе таблицу загрузит, а какая в подвал нагадит
nin-jin
О, это вы не застали какой-нибудь ASP, гоняющий весь вью-стейт туда-сюда в каждом запросе.
Kerman
Застал-застал. Я и фидонет застал, и на сях ббс писал. Я всё пытаюсь простую мысль донести: из огромной кучи параметров достаточно просто сделать одну страницу, просто потому что это поддаётся декомпозиции. А вот когда этот клубок змей шевелится и каждая змея каждую кусать начинает - вот тогда приходит пятилапый зверь
Spiritschaser
VCL нормальный гуй был.
maxim_ge
Какие-то проблемы на бэке определённо есть...
Dependency Hell in Microservices:
Зоопарк блоков для построения архитектуры:
powerman
Конечно. На бэке полно проблем. Именно поэтому и сформировались довольно жёсткие ограничения, которые мы стараемся соблюдать - где-то это помогает, где-то не до конца. Самое сложное сейчас - правильно определять границы между модулями/микросервисами и корректировать их при изменении бизнес-требований. Тем не менее, по сравнению с происходящим на фронте - на бэке тишина и спокойная работа, с использованием достаточно стабильного набора инструментов.
questpc
Сами себе противоречите. Как раз у ноды и будут макароны из кода и мелькание библиотек и фреймворков как и в клиентской части. Так что да, именно язык без полноценного ООП.
Хотя еще проблема в интерактивности. У бэка ее почти нет. Из за этого обычно меньше неопределенности.
powerman
Никаких противоречий нет - желающие творить фигню найдут способ. Разница в том, что является нормой. Особенности ноды для бэка - не норма, а исключение. Причём так сложилось как раз потому, что нормально ноду воспринимают в основном уже привыкшие к этому беспределу фронтендеры, которым понадобилось немного писать и бэк тоже - а для всех остальных такое на бэке скорее не норма, и они предпочитают более удобные ЯП и инструменты.
Языков без полноценного ООП на бэке полно - тот же Go. Это ничему не мешает, скорее наоборот.
Интерактивности на бэке вообще-то на порядок больше. Это на фронте юзер один, у него одна клава и одна мышка. А на бэке могут быть миллионы одновременно происходящих событий в одном многопоточном сервисе - включая как события от множества юзеров на фронте так и внутренние события бэка. И всё это льётся в общий стейт/БД, взаимодействует друг с другом, и должно обеспечивать консистентность.
gluck59
Вон тут с галерки вещают что для бэка существует куча языков на любой вкус и набор задач. А на фронте как был один JS из нетскейп навигатора, так и остался по сей день.
powerman
Это, конечно, правда, но, на мой взгляд, не очень релевантная. Во-первых потому, что на бэке тьма языков но в данном вопросе принципиальной разницы между ними нет. Во-вторых потому, что вроде уже есть консенсунс по использованию TS вместо JS, его поддерживают все основные библиотеки/фреймворки и большинство новых проектов делают на TS.
gluck59
Подскажите плиз кто из браузеров понимает TS.
orenty7
Нативно -- ни один из широко используемых. Но ts компилируется в js, поэтому непонятно зачем тут поддержка браузеров
Rion333
low coupling and high cohesion
gsaw
Мне лично нравится простота функциональных компонент. Как то понятнее, что-ли. Вот есть функция, которая возвращает компонент и все. Все на виду, в определенной последовательности. С классами весь код получается размазанным, там дефолтные параметры, там Стейт, там загрузка данных, в углу функция отрисовки опять же. Прочесть код класса сложнее кмк.
js2me
Вот есть функция Component, которая вызывает ещё функции use*, которые вызывают ещё функции useHook, внутри которых вызываются ещё другие функции useHookN…
gsaw
Я лет 15 назад был в проекте. Сервер, на Си. Там функции были на несколько страниц, в функциях были запросы к базе и ветвистая логика. Да и сами файлы были на 15к и больше строк. Там черт ногу сломишь. Проект был запущен, большая текучка. Я и сам сбежал от туда. Так вот я к чему.
Ведь такие огромные методы, не значит же, что Си плохой и с С++, с классами получилось бы лучше. Я думаю имели бы громадные классы на 15к строк и методами на три страницы.
Если писать по фэншую, придерживаться clean code. Не писать компоненты на десять страниц и на все случаи жизни, то вполне себе можно обойтись минимумом хуков.
winkyBrain
но ведь в классе будет происходит ровно то же самое, только без префиксов use. есть классовый компонент, в нём есть метод Component*, который вызовет в себе метод для загрузки данных(к примеру) и т.д. что изменилось глобально? кроме того, что в случае функциональных компонентов у нас нет привычной возни с контекстом, его потерей, необходимости местами прибивать его гвоздями и прочими весёлыми штуками
ant1free2e
перерисовки реакта т.е. повторный вызов кода скорее всего приводят к дрочеву памяти(а если есть утечки к быстрому ее исчерпанию) и логики, которая может быть написана в конструкторах
Sap_ru
С чего бы? Теперь и сейчас умеет переползать компоненты, а с классами это было заметно проще делать и снизило бы нагрузку. Все равно под капотом там самые обычные объекты, только обложенные костылями, чтобы их видно не было.
js2me
Смею предположить, что основная причина отказа от классов было нежелание изучать и/или внедрять ООП подход
DmitryKazakov8
Официально, насколько помню, причина в mixins - не до конца доведенной до ума фиче, в которой можно было переиспользовать логику, содержащую жизненный цикл. То есть это был аналог useEffect. А то, что "многие не умеют работать с this и форумы забиты вопросами - почему
onClick={this.handleClick}говоритthis is not defined" - это второстепенно.Нужен был именно механизм разбиения сложной логики на более атомарные части и возможность их комбинации и переиспользования. Но реализация в useEffect с ручными зависимостями и частой необходимостью оборачивать функции в useCallback для сохранения ссылок при очистке `window.removeEventListener` вкупе с "правилами хуков", что нельзя что-то включать-отключать-переставлять, привела к куда большим проблемам.
questpc
Попробуйте preact + signals. preact вполне одобряет использование классов. А signals создает реактивность более лаконично в сравнении с useEffect. Кроме того за счет библиотеки htm можно писать чисто браузерные приложения без огромной сборки на node.
winkyBrain
какой кошмар, столько плюсов сией нелепой мысли) для начала, в предположении, основная причина отказа от классов со стороны кого? тут два варианта:
- со стороны разработчиков реакта. то есть фейсбук не вывез в ООП, хотя до 16 версии реакта в нём активно использовались классовые компоненты? и их до сих пор никто не запрещает использовать. сомнительно, правда?
- со стороны разработчиков, использующих реакт. то есть разработчики использовали-использовали(раз отказались потом), и вдруг такие "ну всё, я больше не могу"? при том, что в рамках реакта ООП это в основном контекст и его привязка - совершенно ничего сложного. тоже сомнительно, но будто бы речь больше про это, ведь встречаются слова про "нежелание изучать/внедрять ООП". однако классовые компоненты не развивают с 16.8 версии реакт(с 2019 года, не секудочку), при этом активно развивают хуки(т.е. функциональные компоненты). смысл продолжать использовать умирающее?
удивляюсь порой, насколько далёкие от темы обсуждения люди, вместо того, чтобы хоть немного погрузиться или банально подумать, просто "смеют предполагать" какую-то дичь. а на самом-то деле прибежали просто адепты церкви ООП, и если сделать поправку на это - в принципе сразу всё встаёт на свои места