Недавно работал над хобби-проектом, который описал в другой своей статье. В процессе его реализации у меня возникло желание чиркануть пару абзацев о том, почему 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 только там, где это реально необходимо».
Хуже точно не станет.
Комментарии (311)
oliva80
13.07.2025 09:14создание интерактивного UI, где любой компонент может обновлять любой другой компонент, просто является одним из сложнейших аспектов в разработке
возможно, с помощью Redux или чего-то аналогичного, но здесь у меня недостаточно опыта
React+Redux для этого и существуют. на смену redux пришёл react context api, и неплохо с этим справляется.
Простота и польза React особенно видна в React Native, который упрощает и удешевляет мобильную разработку.
Эта штука прекрасна для своего класса задач!
от авторской критики веет безумием.. :)
DmitriyDev
13.07.2025 09:14Разработку под мультплатформы - да, но вот поддержку…
У нас вышел новая iOS, клиент хочет новые фишки. А вот фиг, так как вы используете package для push notifications, который автор не хочет пока обновлять. А когда обновит, он не хочет собираться под старый gradle от андроида, а что бы обновить версию gradle вам надо обновить все остальные пакеты. И тут оказывается что один из них заброшен и вам надо переписывать половину приложения под новый пакет. Особо приятно было когда перестал поддерживаться NativeBase.
Ну или не клиент пишет, а гугл. Мол со следующего месяца ваша приложение будет удалено если не обновите версию api, что вызывает те же проблемы, описанные выше + ещё и reactnative надо обновить до какого-нибудь 0.80 у которого половина пакетов не работает, просто потому что мы решили что разработчики слишком хорошо живут без глобальных изменений.
Vedomir
13.07.2025 09:14Так это так сейчас практически везде. Весь софт стремительно протухает и портится стоит ненадолго оставить без внимания. Я вот в ближайшее время буду переделывать один проект с PHP 7.2 на PHP 8.2. И там во Vue части есть еще древние куски с Vuex которые надо бы переписать на Pinia. И сборщик заменить с webpack на vite потому что он тоже уже протух. И это еще PHP пожилой и зрелый язык, про Go и Rust пишут, что там чехарда не слабее JS библиотек.
Я видимо уже не молодой и наблюдал как одно и то же приложение переписывалось по пять раз практически не меняя функционала
Trubo C + assembler
Clarion
Windows Forms/Delphi
Классический server-side web с JQuery
Angular/Vue/React
Ладно, первые два пункта по рассказам старших коллег, но Clarion приложение еще видел вживую.
На чем оно будет переписано в следующей раз? Go + Flutter? Rust?
Единственное заметное изменение для пользователей было - появление многозадачности при переходе с DOS на Windows, даже графический интерфейс ничего особо полезного для пользователей не принес.
Для поддержки появление постоянных каналов связи с сервером. Правда центральные сервера имеют обыкновение временами падать, причем даже не в самых мелких и бедных конторах вот недавно В «Спортмастере» из-за ливней затопило IT-инфраструктуру, серверы «сушили» почти сутки (то приложение о котором я пишу было в намного более бедной и простой организации).
Функционал не менялся.
С другой стороны я без работы не останусь, если только ИИ программистов не заменит.
DmitriyDev
13.07.2025 09:14У нас сейчас всё на Flutter переписывают. Но у меня нет опыта с поддержкой Flutter. Но по идее должно быть проще чем react-native
ekkebeatovich
13.07.2025 09:14react context api — это не средство для стейтменеджмента, а скорее средство для DI. Смешно слышать, что релакс с кучей фичей заменяет штука, которая передает данные глубоко вниз по дереву
iroln
13.07.2025 09:14Простота и польза React особенно видна в React Native, который упрощает и удешевляет мобильную разработку.
Даже сложно представить как бы тормозил какой-нибудь Telegram если бы его написали на React Native. Я не говорю, что Telegram хорошо написан, он ужасно написан (посмотрите исходники Android-клиента, там настоящий ад и файлы по 20 тысяч строк), но на Java можно написать так, чтобы приложение было супер быстрое и отзывчивое, а на 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 проще было пересаживаться на что-то кошерное )
artptr86
13.07.2025 09:14А на что «более кошерное» им понадобится пересаживаться после Solid?
dale0
13.07.2025 09:14Например, на Qwik (но только для SSR приложений). Отличие которого в том что у него нет гидрации, но при этом он тоже похож на React, как и Solid.
artptr86
13.07.2025 09:14Что-то он медленнее всех конкурентов: https://krausest.github.io/js-framework-benchmark/2025/table_chrome_138.0.7204.50.html
Скрытый текст
Чем же он более кошерный?
dale0
13.07.2025 09:14По ссылке в моём первом комментарии можете подробно почитать про Resumability и отличие её от гидрации. Но если совсем коротко: Меньше JS на клиенте (только то, что должно быть на клиенте чтобы интерактивные элементы работали), меньше кода исполняется (выполняется только код, который нужен в данный момент), ленивая загрузка кусков вашего приложения (раньше они делали это через service worker, а теперь через modulepreload). Ну а скорость - это проблема решаемая. Кроме того чтобы понять, почему бенчмарк такие результаты показывает, нужно понимать, как он реализован,
а ещё обновлять фреймворки до актуальных версий, например
novaboreckii
13.07.2025 09:14Не от простой жизни на фронте существует тот же Angular. Фреймворк задает структуру и правила, при соблюдении которых в крупном проекте получается довольно неплохо бороться со сложностью и видеть все взаимосвязи. Плюсом также является наличие Typescript и наличие в компиляторе строгой проверки шаблонов. Таким образом весь код обложен всеми возможными видами поверок и уже на этапе компиляции можно отловить большинство багов. Также можно провести изменение на сотню или две файлов и быть уверенным что ничего не изменится. Конечно платим мы за это жутко костыльным механизмом change detection, но вроде с сигналами стало чуть полегече. Ну и справедливо это все для действительно сложных интерфейсов, например каким нибудь редактором дашбордов, тогда есть смысл платить эту цену, потому что в long-term это окупится.
Однако же замечу, что часть коллег из фронтенда пренебрегают жесткими настройками компилятора в угоду скорости. И тогда поддержка проекта после таких «разработчиков» превращается в серьезное испытание.
funca
13.07.2025 09:14Ну и справедливо это все для действительно сложных интерфейсов, например каким нибудь редактором дашбордов, тогда есть смысл платить эту цену, потому что в long-term это окупится.
UI для Google Cloud Platform написан на Angular. Может им удаётся экономить на костах разработки, но чисто со стороны пользователя решение выглядит как антиреклама данному фреймворку: тяжело, медленно, неудобно и некрасиво.
iroln
13.07.2025 09:14выглядит как антиреклама данному фреймворку
Достаточно просто зайти на сайт angular.dev, уже там антиреклама начинается.
MadeByFather
13.07.2025 09:14Без монструозного и запутанного инструментария
Как раз у Vue инструментарий более монструозный, как минимум в силу того, что это фреймворк. Можете даже банально сравнить кол-во страниц в документации реакта и вью. Если из реакта "выкинуть" "легаси" про классы, SSR и хуки, которые опционально используются раз в сто лет, то это несколько страниц
тормознутой помойки под названием npm
...которая никак с реактом или вью не связана - и при этом вью точно так же его использует. Хотите меньше тормозов - yarn или pnpm
кучи препроцессоров
Которые настраиваются один раз или не настраиваются вообще, потому что есть готовые коробочные решения. Или вы думаете, что вью ничего не препроцессит?
системы/пайплайна сборки (конфиги которых передают по наследству, даже не пытаясь в них разобраться)
Сами написали рандомные конфиги, а виноват реакт
кучи доп. библиотек для совершенно базовых вещей
То есть буквально никакой разницы со вью нет, вы что там ставите внешние стейт менеджеры, клиенты для апи, валидации, дат, тестинга и т. п., что там
RulenBagdasis
13.07.2025 09:14Или вы думаете, что вью ничего не препроцессит?
Vue прекрасно работает вообще без сборки, npm и т.д. Особенно, когда речь про небольшие приложения на несколько страниц.
вы что там ставите внешние стейт менеджеры
vue reactive state доступен из коробки, ничего ставить не надо. Для небольших приложений на несколько страниц этого более чем достаточно.
dale0
13.07.2025 09:14Vue прекрасно работает без сборки, npm и т.д.
React тоже можно использовать без сборок, npm и прочего: Просто импортируете его из какого-нибудь esm.sh в обычном JS-модуле и используете: https://codepen.io/octet-stream/pen/EaVjVmK
У вас не будет JSX - придётся вручную вызывать createElement, но так тоже можно. Другое дело что, а нужно ли? Равно как и с Vue - намного удобней использовать его со всеми этими инструментами.vue reactive state доступен из коробки, ничего ставить не надо
Опять же, useState, useReducer и createContext доступны из коробки, ничего ставить не нужно. Для простых приложений должно быть достаточно. Работает даже без препроцессоров (ссылка на codepen выше в моём комментарии).
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 для нормального и удобного управления состоянием
kvd264
13.07.2025 09:14вообще не вижу смысла это обсуждать
Если вы не можете сделать так на Реакте, значит никому это не нужно, верно? )
с двумя кнопками
Ну почему же. Законом не запрещено ещё табличку и дропдаун добавить
Почему на реакте нельзя написать ванильный fetch?
Извините, вы похоже невнимательно прочитали
> вроде бы никто не заставляет
Каким образом связан react и axios?
> 95% разрабов на реакте будут использовать какой-нибудь Axios
Знаете, самому было интересно, почему
И мне не нужно при этом тащить аналог Pinia
Представляете, мне тоже! Ну хоть что-то вам тащить в реакт не надо, уже хорошо.
Fenzales
13.07.2025 09:14Там, где 95% разрабов на реакте будут использовать какой-нибудь Axios (хотя вроде бы никто не заставляет, но это почему-то распространено повсеместно)
Потому что там есть intercept, catch, таймауты и прогресс из коробки. Вообще не вижу ни одной причины пользоваться голым fetch где-либо кроме крохотных пет-проектов.
kvd264
13.07.2025 09:14Спасибо что просветили. В проектах, где я видел axios, эти фишки не использовались, и его можно было легко заменить на fetch. Поэтому не знал о них.
radtie
13.07.2025 09:14А у меня впечатление, что Vue не знает кем хочет быть, и просто пытается быть на гребне тренда.
Сначала он был как типа улучшенный AngularJS, т.к. Angular 2 - сложна, потом пришел React, и Vue начал косить под него, сейчас вроде уже выработался свой стиль, но кто знает, щас ребята впечатлятся чем то еще, и привет Vue4.
artptr86
13.07.2025 09:14Разве когда-либо Vue косил под React? Да, у него есть и VDOM, и JSX он поддерживает как следствие, но React он в целом не повторял ни в developer experience, ни в системе реактивности.
mayorovp
13.07.2025 09:14У Vue есть хуки, и из-за этого некоторые думают что он косит под React. Однако, при внимательном взгляде видна принципиальная разница: если у React вызовы хуков делаются во время рендера, то во Vue они используются на этапе инициализации компонента.
И наличие этого самого этапа инициализации очень многое меняет в архитектурном плане.
Zalechi
13.07.2025 09:14Это ведь была эволюция. Сначала был JQuery. Парни из Google посмотрели на это безобразие и сделали Angular. Потом парни из Facebook посмотрели на безобразие под названием Angular и сделали React. Потом один чел из гугла снова посмотрел на всё это переусложненное безобразие и сделал Vue.
Вот чтобы всего этого безобразия не было, было бы круто, чтобы все уважаемые вышеперечисленные персоны и фирмы выделяли своих людей для работы в спец-комитете. И академики там должны присутствовать. И решал бы этот комитет все насущные задачи совремнников и задавал бы тон развитию:
https://habr.com/ru/companies/ruvds/articles/926286/comments/#comment_28575664
не отдельные люди / фирмы должны создавать парадигмы, а специальный комитет в состав которого они и входят. Сообща.
А то сегодня Линус хочет так, а завтра Гейтс ему такой — эдак. Вот вам и бардак.
PrinceKorwin
13.07.2025 09:14Благодаря этому бардаку и происходит прогресс. А что до комитетов, то пожалуйста не надо.
Если вас какой-то фреймворк/библиотека/подход не устраивает - не используйте. Благо есть выбор.
Zalechi
13.07.2025 09:14В том то и дело, что я обычный пользователь, и из года в год баги-баги-баги.
Дайте мне мне пул-сертифированного ПО для выбора, а не один глаобальный черный ящик.
И нет — этотне я требую рюшечки, эты вы и дизайнеры мне их впихивайте.
Мне нужна, простота, быстрое исполнение, стиль да -пусть будет, его не может не быть, и минимизация багов. Что не возможно без создания комитета регулирующего взаимодействие между Большой тройкой.
Ах да, и если у Вас не увязывается одно с другим, то я подскажу, как это реализовать без потерь доя прогресса и стабильного развития.
Видете ли — мир стал очень комплексным, сложным, чтобы решать все насущные задачи старым добрым методом.
Соревновательность и маргиналов никто не отменяет , но нужна СТРУКТУРА ПАРАДИГМ ПОВЕДЕНИЯ И ВЗАИМОДЕЙСТВИЙ.
PrinceKorwin
13.07.2025 09:14Вы думаете в сертифицированном ПО не бывает багов?
Как наличие коммитета поможет вам с минимизацией багов?
Мир никогда не был простым.
но нужна СТРУКТУРА ПАРАДИГМ ПОВЕДЕНИЯ И ВЗАИМОДЕЙСТВИЙ.
так они есть. И не один. Хотите ООП, хотите ФП и так далее. Выбирайте под задачу. Есть баги? Ну так помогите с их починкой.
Zalechi
13.07.2025 09:14Даю другой пример.
Обучение: школы, вузы.. все это организовано. Однако есть возможность воспитывать дома, персональными учителями и тд
PrinceKorwin
13.07.2025 09:14И не факт, что это хорошо на самом деле. Есть страны где одновременно несколько разных образовательных систем и у родителей есть возможность выбора.
Вы так и не ответили каким образом коммитет сделает так, что багов будет меньше.
Zalechi
13.07.2025 09:14Вы бы по ссылке прошли.
ОРГАНИЗАЦИЯ ПРОЦЕСОВ. Задание тона, четкое структурирование имеющихся вызовов, парадигм их решения и введение/разработка соотвесствующих рекомендаций.
Что ттут непонятного…
Вот было обучение через подмастерье раньше, от отца к сыну, но почему мы пришли к организованным вещам. Ибо комплексность увеличилась. Мы вынуждены регулировать это через Мин Просвещения (или как там оно у вас называется).
А модель OSI добилась большего. Весь мир бегает по ее «указке». Результат не идеальный, но….
Вы поймите. Я не иделаьный, и лишь пытаюсь направить в нужное русло решение насущных проблем, плюс закладка фундамента.
funca
13.07.2025 09:14Соревновательность и маргиналов никто не отменяет , но нужна СТРУКТУРА ПАРАДИГМ ПОВЕДЕНИЯ И ВЗАИМОДЕЙСТВИЙ.
На самом деле стандарты, сертификация, обучение и лицензирование персонала используются там где это важно (PSI DSS, SOC2, и т.п). Но там критерии, по классике, указываются в терминах результов ("что", а не "как"). Маршеровать строем ни кто не заставляет, но если вы пойдёте не туда, то на это укажут.
Zalechi
13.07.2025 09:14Я узер, и как вы там собирайтесь решать свои задачи меня условно не волнует. Но вы должны отталкиваться не от приихоти бизнеса или меня, а от заданых цивилизациооных задач. То чем занимаются в академиях.
Поэтому я желаю иметь магазин, где бду уверен, что это ПО написано красивым стилем, имеет минимум багов. —Дорого? Окей, но я имею выбор, а не этот глобальный черный ящик.
Сертеыицированное ПО. Не Вы, а ПО.
Суть не в этом, а то шо вами крутят как котят, а вы все прихоти бизнеса и дизайнеров исполняйте
funca
13.07.2025 09:14Поэтому я желаю иметь магазин, где бду уверен, что это ПО написано красивым стилем, имеет минимум багов. —Дорого? Окей, но я имею выбор, а не этот глобальный черный ящик.
Глобально правила игры задаёт государство. В остальном же любой каприз за ваши деньги - в конце-концов за все платит не бизнес или дизайнер, а клиент.
acsent1
Я вот одного не понял: почему отказались от классов? Не уж то классы в js так тормозят, что что использование всяких мемо для функций и переменных выходит дешевле
Sadler
Нет, производительностью самой системы классов на данном этапе для большинства нормально написанных проектов можно пренебречь. Я думаю, что основной причиной послужило желание избавиться от наследования и иерархии классов, которые в ООП создают самый большой объём сложности. За это мы заплатили отсутствием встроенного стейта и необходимостью использовать хуки, соблюдать правила хуков, иметь ту самую неочевидную последовательность исполнения.
Лично я не знаю одного идеального способа разработки, я писал свои проекты очень по-разному, и везде есть плюсы и минусы. Большинство программ стремится либо к "морю акторов" (много мелких блоков/функций/компонентов, взаимосвязи которых сложно проследить), либо в "монолит" (одно большое неделимое ядро со сложным, почти неопределённым состоянием и его обвязка). Всегда выбор сводится к тому, предпочитаем мы терпеть объёмную или концептуальную сложность кода. Всегда приходится прикладывать чудовищные усилия, чтобы проект представлял собой прозрачные взаимодействия фиксированного количества акторов, и в процессе роста он всё равно будет стремиться в одно из вышеописанных состояний, какой бы парадигма ни была.
powerman
Интересно, что никто, похоже, не задумывается, почему всех этих проблем нет на бэке. Отговорка с "много входов/выходов" тут не очень работает, потому что практически на все ваши фронтовые входы есть соответствующие им входы в API бэка. Этот API нередко очень объёмный, и, как и на фронте, в конечном итоге влияет на некое очень большое состояние (БД), иногда разделённое между компонентами (микросервисами), иногда монолитное. В общем, параллели довольно очевидные, а вот такой боли (и заодно непрерывного мелькания инструментов/библиотек/фреймворков) как на фронте - нет. Причём этого нет вне зависимости от используемого ЯП бэка (может, за исключением ноды, там теоретически должно мелькать примерно то же, что и на фронте, но это результат того, что вы в каком-то смысле "взяли фронт и запустили его на бэке" как раз для того, чтобы не использовать штатные технологии и ЯП бэка - так что это особый кейс и его в текущем контексте обсуждения можно игнорировать).
Идея автора статьи рендерить часть UI на бэке выглядит рабочей, но он тоже не задаётся вопросом "а почему выполнить ровно эту же самую работу на бэке не является настолько же сложным, как на фронте - ведь работа-то в конечном итоге одна и та же".
Лично я предполагаю, что ключевой частью ответа на этот вопрос может быть "дисциплина". На бэке принято соблюдать длинный список ограничений, к которым мы настолько привыкли, что для многих "так было всегда" и они их даже не воспринимают как что-то особенное. Например, на бэке никто не делает свои БД. В смысле, чтобы вот у каждого проекта была своя уникальная БД - такого нет. А ведь когда-то такое было нормой, и я даже эти времена ещё немного застал. Но уже нет. Есть SQL, есть NoSQL, есть message brokers, есть K/V кеши - все они накладывают свои ограничения, но мы всё-равно берём кого-то из них а не пишем своё хранилище состояния приложения. Любые глобальные переменные вызывают нервный тик, даже если это "просто" конфигурация или логгер. Чуть менее очевидные/однозначные примеры включают в себя чистую/гексагональную архитектуру (100% изоляцию бизнес-логики от внешнего мира для простой тестируемости), модульную/микросервисную архитектуру (тут фишка в том, чтобы адекватно спроектировать архитектуру, чтобы размер этих модулей был и не очень мелким и не очень крупным плюс удачно соответствовал границам транзакций и UX-ожиданиям консистентности - для этого придумали стратегические паттерны DDD). Чуть более очевидный пример - на бэке в принципе считается нормальным сначала сделать архитектуру и уделять ей много внимания, даже если это блокирует новые фичи. А ещё - на бэке считается нормальным говорить "НЕТ" в ответ на пожелания бизнеса (это примерно то же, что рекомендует автор статьи в контексте "делайте меньше кнопок"): "нет, это работать не будет", "нет, это слишком сложно реализовать и мы в этом утонем", "нет, это будет архитектурная дыра в безопасности", … много разных "нет". И хотя за некоторыми из них может скрываться "нет, мне лень это делать", сам факт что бэк умеет говорить "нет" имеет значение!
nin-jin
Ну я вот пилю своё хранилище, где не нужны ни SQL, ни message brokers, ни K/V кеши, но я вам его не покажу, а то ещё больше забанят личку.
themen2
Люди уже устали читать про твои либы, извини, слишком навязчиво это.
ef_end_y
Пошел на свидание nin-jin. Девушка говорит: какая сегодня хорошая погода. А nin-jin: я как раз хотел тебе об этом сказать, я делаю одну библиотеку...
Sadler
На бэке просто уже есть наработанный набор инструментов, в т.ч. БД, которые уже отлично решают задачу хранения больших массивов данных. Теоретически, на фронт тоже можно затащить чисто клиентскую БД вместо ручной обработки и фильтрации данных, и завязать реактивность на неё, и даже можно бинарные блобы выгружать куда-нибудь в localStorage, но всё это настолько редкие и нишевые решения, что ими можно пренебречь. Да и задачи разные, не будут те же инструменты так удобны на фронте. Собственно, все стейт-менеджеры, в какой-то мере и являются простым аналогом базы данных для хранения данных и обновления UI.
Особенно весело, что из дисциплинированности бэка вытекает, что я, нажав Alt+Tab, становлюсь мгновенно более дисциплинированным, и наоборот.
powerman
Есть вероятность, что задачи просто кажутся разными. Иначе почему перенос рендеринга на бэк обычно всё заметно упрощает? Я допускаю, что ключевое различие между задачами, из-за которого они и воспринимаются "разными", заключается как раз в дисциплине: на фронте задача "сделать что сказал продакт", а на бэке задача "сказать продакту что мы можем и чего не можем сделать".
Собственно, на бэке вполне долго и упорно пытались писать без оной дисциплины, послушно делая всё, что просил бизнес. Как правило, всегда получали в результате "большой комок грязи" и необходимость переписывать проект с нуля. Этот подход просто не работает, особенно если проект изначально сложный или его нужно много лет развивать.
Ну, я говорю о дисциплине "в среднем по индустрии". Отдельные разработчики могут значительно от этого среднего отличаться. Но и как Вы говорите тоже часто бывает: на бэке строгая типизация, линтеры и свои правила/best practices и подходы к разработке/тестированию/отладке/мониторингу, а на фронте всё это совсем другое. И один и тот же человек вполне может писать один проект чисто и соблюдая кучу ограничений и при этом параллельно писать другой на другом языке быстро-грязно.
themen2
Потому что на беке не надо собирать данные для view из асинхронных запросов api. Либо sql запрос и сразу все взял что нужно, либо какой то относительно удобный orm и работа с моделями. Выглядит это все равно проще чем работа с данными из api методов на фронте
NyarukouSAMA
Погодите, а как же redux, который как раз выполняет функцию хранения данных. Мне вообще довольно сложно представить использование реакта без связки с редаксом. А многокомпанентная архитектура позволяет выстраивать кусочки данных в эти компоненты, таким образом мы же вполне можем свести все к очень не большому набору (если вообще не единичному вызову useEffect). Но в целом, я думаю согласится с автором можно. На бэке люди более дисциплинированны, потому что есть компилятор как минимум, который тебе скажет, почему ты чудак на букву м. А есть ещё всякие штуки, которые проверяют codesmells, типа sonarcube-а. В js этого изначально не было. Транспиляция согласно некоторым правилам появилась только вот в angular 2/react-е. А щас есть typescript и возможность писать реактивные компоненты на нем. Использование ts в свою очередь накладывает свои правила. А есть ещё js стандарты и паттерны, которые ты можешь заставить использовать в проекте подключи библиотеку контроля codesmells (забыл как называется). Просто вся эта дисциплина она не сразу же появилась в случае с бэкендом, в том числе умение говорить нет, ну или хотя бы предупреждать, что мы можем, но потом у нас всех будут большие проблемы с поддержкой и вам придётся заплатить крупную сумму за разработку и сопровождение. Упоминание крупных сум иногда действует на бизнес довольно отрезвляюще. Мне кажется это все дело времени. Пока во фронте не устаканится какие-то bestpractises, не наработаются шаблоны проектирования, пока разработчики и инструменты под них подстроятся... Все это требует времени.
clerik_r
Открываю глаза, есть такая штука, называется MobX. И все проблемы у неудобства управления состоянием сразу как рукой снимет.
Aetae
Не снимет, т.к. в react оно пропихивается через явный костыль и использовать его можно сотней неудачных способов(на которые я насмотрелся до крови из глаз).
Нет, если правильно использовать то всё отлично, но тут та же проблема что и со всем React в целом - излишек свободы говнокода и мутные best practice, зачастую выглядящие как грязные хаки.
Kerman
На бэке нет гуя. Если копнуть тот же шарп у него есть mvvm, который вырождается в реактивную ахинею со временем и очень сложно отследить, что как и куда меняет во вьюмодели и в какое место вью это полетит. Есть винформс, где сложность вырождается в кучу методов, которые по событию пытаются привести гуй в актуальное состояние.
В запущенных случаях и то и то ужасно. А чтобы держать в порядке, надо переосмысливать сам дизайн гуя, подходы к подаче инфы да и вообще весь UX.
Так что моё подозрение в том, что сложность возникает после работы с интерфейсом нескольких команд с разными целями в течении долгого времени.
nin-jin
Если использовать Объектное Реактивное Программирование, то никаких проблем с пониманием потоков данных по коду нет вообще. Так что проблема определённо не в гуях, а в инструментах для них не пригодных.
Kerman
Ну не бывает волшебных библиотек, которые решают всё. И технологий таких нет. И подходов, хотя они называются "серебрянными пулями". Ну допустим один подход работает лучше другого. В UI ад и израиль, но вот сейчас вытягивает. А потом приходят эффективные совы и в клювике приносят новые правки гуя. И волшебная библиотека говорит "кря". Потому что надо UI перепроектировать, а не кровати двигать, вот что.
nin-jin
Я правильнорпонимаю, что вы пробовали ОРП и говорите со знанием дела, а не просто транслируете свои убеждения, основанные на опыте использования иных парадигм?
mayorovp
Про него не знаю, но вот мой плюс тому сообщению был поставлен на основе опыта работы с реактивными библиотеками.
nin-jin
Менять библиотеки, оставаясь в той же парадигме, это как кровати в борделе переставлять, а потом с умным видом заявлять, что нет достойных девушек на свете.
mayorovp
Хватит считать оппонентов идиотами, парадигмы я учу в первую очередь.
nin-jin
Продолжайте изучение.
mayorovp
Вы сейчас серьёзно утверждаете, что для изучения парадигмы ОРП я должен знать пробовал ли его @Kerman? А где связь?
nin-jin
Для изучения новой парадигмы вам нужна любознательность и желание вырасти как профессионал.
mayorovp
Где связь любознательности и желания вырасти как профессионал со знанием о знаниях другого хабрапользователя?
Причём тут изучение новой парадигмы, если обсуждаемую парадигму я уже знаю?
Kerman
Я вертел на болту ОРП, вертел реакт, жаваскрипт и весь веб в целом. Десктопщик я. А для своего сайта сделал ssr и мне за глаза хватает.
artptr86
Так-то это выглядит у вас, что с ростом сложности задачи нужно не думать об инструментах, позволяющих снизить сложность её решения, а снижать сложность задачи.
Kerman
Если не выбрасывать контекст, то не выглядит. Я не против инструментов управления сложностью. Сам топлю за типизацию и всякие ORM. Но в этом примере показывал, что источник бардака - гуй. И гуй ты чего сделаешь со сложность, пока у тебя всратый UX.
powerman
Это довольно очевидный, напрашивающийся… но, вполне возможно, некорректный ответ.
Я не буду спрашивать в чём принципиальное отличие GUI от TUI и CLI (которые на бэке есть). Я спрошу другое: а как же условный Web 1.0? Ровно тот же HTML+CSS+JS, но рендеринг полностью на бэке - чем это не GUI? И окажется, что отличие тут ровно в том, о чём я писал - в ограничениях и дисциплине. Условно можно считать, что во времена Web 1.0 мы говорили продакту "нет, мы не сделаем SPA, а будем рендерить всё на беке, и страничка у юзера будет постоянно перечитываться". И никаких сопоставимых с текущей ситуацией на фронте сложностей при этом не возникало. (Подсказка: в случае TUI и CLI всё выглядит очень похоже - и там и там есть куча ограничений, которые приходится соблюдать, которые создают кучу неудобств и для пользователей и для разработчиков этих UI, но зато код получается вполне умеренной сложности.)
Kerman
Вот и ответ. Бэк рендерит ровно один стейт, а не следит за связностью какая кнопка тебе таблицу загрузит, а какая в подвал нагадит
nin-jin
О, это вы не застали какой-нибудь ASP, гоняющий весь вью-стейт туда-сюда в каждом запросе.
Kerman
Застал-застал. Я и фидонет застал, и на сях ббс писал. Я всё пытаюсь простую мысль донести: из огромной кучи параметров достаточно просто сделать одну страницу, просто потому что это поддаётся декомпозиции. А вот когда этот клубок змей шевелится и каждая змея каждую кусать начинает - вот тогда приходит пятилапый зверь
mayorovp
Я вот эти веб-формы застал. И бардак в них был такой, что реакт на том фоне выглядит шедевром архитектуры.
Spiritschaser
VCL нормальный гуй был.
Uporoty
в VCL разве было хотя бы что-то типа MVVM? там, насколько я помню, был ровно тот же самый пердолинг как и в WinForms, когда надо руками каждый раз дергать свойства виджетов, а потом в обработчиках событий вручную присваивать значения обратно куда надо и дергать свойства других виджетов.
TemaAE
Да чего там был — прямо сейчас 3 живых проекта на нем веду.
По соотношению заработок/качество/скорость просто топ до сих пор для определенного вида проектов.
Я, понимаю, что эти три проекта - это не показатель "живости" для индустрии.
Но пример того, что можно брать и успешно использовать.
themen2
Похоже на то да. Видимо сама программа становится настолько большой по функционалу, что управлять состоянием gui становится слишком сложно независимо от того какой подход ты используешь...
Оно просто сложное само по себе.
Выход: просто меньше элементов ui для взаимодействия с пользователем) , либо выделять новые отдельные приложения (по образу микросервисов на беке)
maxim_ge
Какие-то проблемы на бэке определённо есть...
Dependency Hell in Microservices:
Зоопарк блоков для построения архитектуры:
powerman
Конечно. На бэке полно проблем. Именно поэтому и сформировались довольно жёсткие ограничения, которые мы стараемся соблюдать - где-то это помогает, где-то не до конца. Самое сложное сейчас - правильно определять границы между модулями/микросервисами и корректировать их при изменении бизнес-требований. Тем не менее, по сравнению с происходящим на фронте - на бэке тишина и спокойная работа, с использованием достаточно стабильного набора инструментов.
questpc
Сами себе противоречите. Как раз у ноды и будут макароны из кода и мелькание библиотек и фреймворков как и в клиентской части. Так что да, именно язык без полноценного ООП.
Хотя еще проблема в интерактивности. У бэка ее почти нет. Из за этого обычно меньше неопределенности.
powerman
Никаких противоречий нет - желающие творить фигню найдут способ. Разница в том, что является нормой. Особенности ноды для бэка - не норма, а исключение. Причём так сложилось как раз потому, что нормально ноду воспринимают в основном уже привыкшие к этому беспределу фронтендеры, которым понадобилось немного писать и бэк тоже - а для всех остальных такое на бэке скорее не норма, и они предпочитают более удобные ЯП и инструменты.
Языков без полноценного ООП на бэке полно - тот же Go. Это ничему не мешает, скорее наоборот.
Интерактивности на бэке вообще-то на порядок больше. Это на фронте юзер один, у него одна клава и одна мышка. А на бэке могут быть миллионы одновременно происходящих событий в одном многопоточном сервисе - включая как события от множества юзеров на фронте так и внутренние события бэка. И всё это льётся в общий стейт/БД, взаимодействует друг с другом, и должно обеспечивать консистентность.
gluck59
Вон тут с галерки вещают что для бэка существует куча языков на любой вкус и набор задач. А на фронте как был один JS из нетскейп навигатора, так и остался по сей день.
powerman
Это, конечно, правда, но, на мой взгляд, не очень релевантная. Во-первых потому, что на бэке тьма языков но в данном вопросе принципиальной разницы между ними нет. Во-вторых потому, что вроде уже есть консенсунс по использованию TS вместо JS, его поддерживают все основные библиотеки/фреймворки и большинство новых проектов делают на TS.
gluck59
Подскажите плиз кто из браузеров понимает TS.
orenty7
Нативно -- ни один из широко используемых. Но ts компилируется в js, поэтому непонятно зачем тут поддержка браузеров
gluck59
То есть, на чем бы мы не написали фронтовый функционал, в результате он все равно откомпилится в js потому что
Но несмотря на этот факт я несу какую-то "не очень релевантную" чушь...
Хм.
Ок.
Хорошо.
DarthVictor
Как будто на бэке какая-та среда исполнения понимает Java или C#. Максимум — JVM / CLR Bytecode. Я уж не говорю о разработчиках C++ / Go / Rust, которые как-то с набором инструкций AMD64 обходятся. Поддержка языка на уровне браузера нужна только для дебагера, где она вполне себе есть.
orenty7
Я говорил только про тайпскрипт. Так-то есть wasm ещё.
Вы так и не показали как этот факт релевантен
Uporoty
И это будет совершенно не важно в контексте нашего вопроса - потому что сам исходный код может быть написан на любом другом языке - хоть даже на C++ или C#. То что оно откомпилируется в JS никак не влияет на то, как будет написан исходный код на другом языке, и в принципе даже особо ни в чем не ограничивает (кроме необходимости event loop'а и некоторых моментов по производительности, хотя и там придумали asm.js и wasm).
art1z
Так в этом и смысл, JavaScript - божественный дар, на этих ваших бэках уже десятки языков и фреймворков родились и умерли, от ColdFusion и ASP и до RoR. А в браузере - лучший из языков вселенной, созданный за 7 дней. Аминь
radtie
Так проблема же не в молотке, никакой ЯП не решит архитектурную проблему.
Zalechi
Во-о-о, сразу видно, что бэкенд тесно связан со школой сетевых парадигм проектирования.
Священная инкапсуляция и обязателность ее исполнения заложенная в протоколы поведения:
https://habr.com/ru/companies/ruvds/articles/926286/comments/#comment_28575664
foal
Я пишу на беке, но иногда нужен фронт. Для меня выбор был сделан уже давно и похоже навсегда - для фронта я использую GWT и только его :) Так что подобные статьи у меня вызывают искренний вопрос - "о чём говорят все эти люди?" :)
skoder
Вы не пишете сложный фронт
foal
Да, сейчас нет. Но GWT довольно мощная штука, а я в нём неплохо разбираюсь. В общем мне хватает :)
skoder
Дисциплина у вас есть, ага. У вас есть машинка с известной цпу и оперативкой, вот что у вас есть. Все проблемы в промышленном frontend начинаются когда надо отобразить миллион всего на разных устройствах, появляются сложные паттерны, которые так невзлюбил автор. Все ваши знания о промышленном фронтенте видимо и сидят где-то - ой да там же формочки, можно и на бэке генерить. Когда нужно на 4-м андроиде показывать бесконечную ленту я бы посмотрел как вы бы ее на бэке генерили. Сложность про на которую мы идем в самом начале заложены боль от прошлых решений. .
Hobri_bobri
Ты просто не понимаешь фронтэнд, чтобы отрисовать один ui элемент приходится запрашивать данные из разных источников, бывает что и из 10, с таблицами это повсеместно, именение в ключевых данных, скажем статус пользователя, влияет на ui элементы по всему приложению, это не похоже на: пришел запрос, о ветил и забыл, правда? Все данные у тебя в памяти, изменение их влияет на логику других, все перепелетено
Rion333
low coupling and high cohesion
Zalechi
Радует то, что отраслевики начинают задумываться о фундаментальных причинах, обсуждать их.
Я топлю за «структурированную/организованную инкапсуляцию парадигм для разных нужд».
Окей, если нам нужен для разных задач/проектов дифференцированный подход к исполнению парадигм, то давайте это пропишем в некой «Глобальной доктрине парадигм программирования»! Разработкой и поддержкой которой будут заниматься уважаемые представители отрасли в составе Комитета, например. Все протоколировано.
Сам Линус, Интел, академики, и остальные представители производства железа, ОС и конечного ПО будут участниками этого Комитета / Института.
Появилась задача — подумали полгода — выбросили решение на рынок — рынок подстроился. Организовано, обязательно, структурировно.
PS: нет, я не предлагаю вводить тотальную регуляцию, но какой организованный остров решений стремящийся к безопасным и солидным решениям — призываю построить.
Есть большая тройка: производители железа, ОС и конечного ПО, — те кто из гих будут придерживаться этих политик, их ПО и железо будет получать сертификат, и распространяться в соотвествующих «магазинах» со знаком качества.. а остальное — без этого знака и уже на риск покупателя.
Bronx
Начинают?! LOL. Они начали когда вас ещё в проекте не было.
Просто люди не учат историю. И история не учит людей, ибо всякая старая глупость предстаёт перед ними в новом свете.
Откуда вы берётесь такие, любители доктрин?
gsaw
Мне лично нравится простота функциональных компонент. Как то понятнее, что-ли. Вот есть функция, которая возвращает компонент и все. Все на виду, в определенной последовательности. С классами весь код получается размазанным, там дефолтные параметры, там Стейт, там загрузка данных, в углу функция отрисовки опять же. Прочесть код класса сложнее кмк.
js2me
Вот есть функция Component, которая вызывает ещё функции use*, которые вызывают ещё функции useHook, внутри которых вызываются ещё другие функции useHookN…
gsaw
Я лет 15 назад был в проекте. Сервер, на Си. Там функции были на несколько страниц, в функциях были запросы к базе и ветвистая логика. Да и сами файлы были на 15к и больше строк. Там черт ногу сломишь. Проект был запущен, большая текучка. Я и сам сбежал от туда. Так вот я к чему.
Ведь такие огромные методы, не значит же, что Си плохой и с С++, с классами получилось бы лучше. Я думаю имели бы громадные классы на 15к строк и методами на три страницы.
Если писать по фэншую, придерживаться clean code. Не писать компоненты на десять страниц и на все случаи жизни, то вполне себе можно обойтись минимумом хуков.
winkyBrain
но ведь в классе будет происходит ровно то же самое, только без префиксов use. есть классовый компонент, в нём есть метод Component*, который вызовет в себе метод для загрузки данных(к примеру) и т.д. что изменилось глобально? кроме того, что в случае функциональных компонентов у нас нет привычной возни с контекстом, его потерей, необходимости местами прибивать его гвоздями и прочими весёлыми штуками
js2me
Только без префиксов use
Без ограничений React экосистемы (можем ли мы под условиями запускать хуки? Можем ли мы одноразово вызывать сложные вычисления ? Можем, но при помощи хуков, но хуки у нас вызываются на каждом рендере (useMemo, useEffect, useState)
Да, тут согласен, только теперь у нас есть возня с хуками
ant1free2e
перерисовки реакта т.е. повторный вызов кода скорее всего приводят к дрочеву памяти(а если есть утечки к быстрому ее исчерпанию) и логики, которая может быть написана в конструкторах
Sap_ru
С чего бы? Теперь и сейчас умеет переползать компоненты, а с классами это было заметно проще делать и снизило бы нагрузку. Все равно под капотом там самые обычные объекты, только обложенные костылями, чтобы их видно не было.
ant1free2e
там рендеринг это вызов функции, результат выполнения которых хранится закешированным, т.е. может содержать ссылки на созданные в процессе объекты. И если такая функция 10 раз все-таки отработала она 10и-кратно повысила нагрузку на ресурсы, это не считая каскадных вызовов по зависимостям. Поэтому там все заворачивается в useMemo и useCallback. А решение аплаить ли новую верстку на страницу принимается на основе диффа, что тоже вычисления.
Использовать реакт составляющие в контексте обычного кода прямо запрещается его рантаймом, а без этого использовать классы вообще довольно малоэффективно и насколько я помню не рекомендуется.
Снизить нагрузку можно было бы не занимаясь софтовым рендерингом за браузерный движок, но все эти концепции закладывались когда поиски и изменения на DOM-дереве в большинстве Интернет Эксплореров работали крайне медленно, поэтому такие архитектуры казались более оптимальными.
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 года, не секудочку), при этом активно развивают хуки(т.е. функциональные компоненты). смысл продолжать использовать умирающее?
удивляюсь порой, насколько далёкие от темы обсуждения люди, вместо того, чтобы хоть немного погрузиться или банально подумать, просто "смеют предполагать" какую-то дичь. а на самом-то деле прибежали просто адепты церкви ООП, и если сделать поправку на это - в принципе сразу всё встаёт на свои места
shsv382
Очевидно, чтобы всех запутать. Во времена классовых компонентов код можно было просто читать таким, какой он есть. Но, видимо, были люди, которые не умеют в ООП, у которых аллергия на классы. Поэтому сейчас нужно всего лишь изучить правила хуков, не запутаться в их многообразии и знать, какой кусок кода читать снизу вверх
taujavarob
Всё дело в замыканиях.
Функции позволяют "замыкать" свойства и состояние компонента, а для классов пришлось бы для этого помещать почти весь код в один метод render() класса. - Но зачем тогда вообще использовать класс, если бы он состоял в основном из одного метода?
Более подробно об этом Ден Абрамов написал в "How Are Function Components Different from Classes?" (March 3, 2019)
Finesse
В классовых компонентах код группируется по событиям, то есть низкоуровневой логике:
componentDidMount,componentDidUpdateи т.д.. А в функциональных компонентах код группируется по высокоуровневой логике, например, синхронизация данных, интерактивность дропдауна, подключение D3.js. Группы кода можно вынести в отдельные функции, благодаря чему код компонента разделяется на независимые куски высокоуровневой логики (хуки, комбинирующие другие хуки). Эти функции можно легко переиспользовать между компонентами. В то же время классовый компонент — это спагетти из логики, где для понимания куска логики часто приходится прыгать по коду на десятки строк вверх и вниз.