Куда катится React? Это успех или провал?

[@Кирилл-ж3м2н]

На правах деда, хорошо поработавшего еще с классовыми компонентами скажу так: хуки решили проблемы людей, которые не могли в проектирование ПО. Не могу сказать, было ли это ошибкой, плюсы хуков очевидны. Но по моему мнению, без них вполне можно было бы обойтись. А вот что касается серверных компонентов - вот это уже реально треш. К самому ССР у меня претензий нет, но по итогу он вылился в попытку создать фронтендо-бекендовский монолит, обмазанный со всех сторон подкапотной магией. Мне это напомнило древние веб формы от майкрософта, от которых давно уже отказались. Есть только один нюанс: веб формы не предназначались для разработки сложного фронтенда. В отличии от реакта, который при использовании всех этих современных фич превращается вообще в непонятно что. Мне вообще кажется, что проблема намного глобальнее. Если посмотреть в целом на инструменты, используемые для разработки, можно увидеть множество очень странных телодвижений. По сути мы постепенно упираемся в потолок, который можно охарактеризовать как "все уже придумано". И множество людей, которым нечем заняться, начинают выдумывать решения для все более и более узких кейсов. Иногда даже сначала выдумывается проблема, чтобы найти для нее решение. В теории, это должно сделать наши инструменты лучше. На практике это приводит к непропорциональному росту сложности этих инструментов и бесполезному прожиранию ресурсов, как человеческих, так и вычислительных. Давно обращали внимание, сколько памяти выжирает даже простенькая страница современного сайта? Вот то-то и оно. И кстати, как оно грузится? Быстро? Весь прирост производительности, который мы когда-то получили от использования СПА очень быстро был сожран. Пришлось переизобретать ССР. Это тоже прожрано. Теперь вот СПА-ССР-монолиты с NoSQL БД, россыпью микросервисов, балансировщиками на гео-ДНС, рейдами из ССД и четырехканальной памятью, и оптоволокном на сотни мегабит... а страница как грузилась 2 секунды, так и грузится. Только памяти и цпу жрет в сто раз больше. И что самое смешное - интерфейсы за последние 10-15 лет не стали сложнее. Они стали проще, потому что 75% посетителей заходит с мобилок, а там в плане интерфейса не разгуляешься. Ну вот и зачем все это было нужно? В итоге получается, что все развитие фронтенда в последние лет 10 было связано с тем, что поисковики плохо индексируют СПА 😂

[@romanwednesday4401]

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

[@kaifaty]

❤

[@ivankprod]

бесконечно плюсую, но имеем, что имеем)

[@kurasaored2775]

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

[@cinicrus]

Реакт в принципе не для тех кто умеет в проектирование. Людям сложнааааа ООП, this не понимаем, блять. Выучи сначала базу, а потом уже инструменты осваивай. Реакт сейчас это обычная поебень, заточенная под первоклассников.

[@alexmarch]

итак почитал комменты и сделал выводы: 1) хуки были нужны и очень хорошо что их внедрили есть нюансы но глобально все ЗА. 2) со стилями нет проблем 3) ССР все считают что многим они не нужны и вообще это прям навязывается со стороны команды Реакт, причем навязывается как и Некст. 3) От себя : я считаю что повторяется история с Ангуляр когда он стал слишком сложным и навороченным, а многие в поисках чего то более удобного перешли на Реакт, и теперь вот Реакт делает что-то подобное и многие уйдут на Вью, кстати я уже перешел.

[@chirkov]

А я наоборот ушел со Вью на Реакт уже как 2 года, и очень доволен выбором

[@artem_bohak]

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

[@AmirLatypov]

Неужели никого не бесили СПА где сначала белая страница с загрузкой, и только потом хоть что то появляется? С ССР как минимум можно отрендерить layout на сервере, и загрузка уже красивее станет, без прыгающих элементов. И даже данные на сервер сайд не обязательно грузить. Но вот с базой лучше работать в отдельном бэке

[@АлександрСкиталец-ц7р]

Вы видимо не поняли ещё что когда появилось серверные компоненты. Появилось потребность большую часть логики переносить на сервер. А оставлять только минимум. А если вы не хотите этого делать вы можете легко сделать spa. Клиент должен быть тупой и меньше логики выполнять на своей стороне. Очень часто видно на проектах. Как нам бекенд всё логику которую выполнить можно на сервер скидывает на клиент. Как начинается обсуждение где делаем? Всё делаем на фронте.

[@_always_21]

@@AmirLatypov если єто веб приложение, то не бесит. если сайт, то конечно там етого не надо. но вопрос не к спа, а почему кто-то решил его заюзать там где не надо

[@blockblock_]

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

[@it-sin9k]

повышение сложности проекта, я тут пожалуй соглашусь) но в общем и целом мне идея нравится)

[@dresdencodex9484]

Зачастую смешивание клентской и серверных частей и невозможно. Тот же NextJS при добавлении одного хука для получения текущего УРЛ в лейаут компоненте говорит что это невозможно и что нужно теперь вынести все как клиентский компонент, поставить метку `use client`, и импортировать. И это только для того, чтобы в лейаут компоненте просто подсветить какая же ссылка активная. Добавление одной-единственной строки может привести к переписыванию кодовой базы. В Qwik же этот простой кейс просто работает. Как и многое другое. Вместо того, чтобы разбивать код по файлам по каждому чиху и ставить метки use client - qwik просто работает. React и Next уже давно не в лидирующих позициях и по фичам отстают от конкурентов.

[@servera-center]

​@@Qvazi74он никому на реакт нах не уперся

[@АлександрСкиталец-ц7р]

​@@servera-center я большие плюсы в серверных компонентах.

[@artsiom5942]

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

[@kamilmodest]

У меня немного голова кипит каждый раз когда я пытаюсь как эта смесь серверных и клиентских компонентов работает под капотом. Там же всё равно RestAPI зашит под капотом, просто неявный. Это напоминает мне бородатые времена, когда девелоперы думали, что классная идея будет, если меж сервисные вызовы будут выглядеть как вызовы внутренних функций (пример WSDL), а потом дебажили часами ошибку десериализации в XML потому что не всегда было в огромном энтерпрайз коде понять где какая неявная логика под капотом вызывается. Мы вроде как убежали от этого как от кошмарного сна и перешли на более явную REST API модель, а теперь опять продаём это как новую фишку. Меня это пугает, если честно.

[@123vitaha]

ну это же просто очередной способ бабок поотмывать, есть фонды развития, как линукс/опенсорс, там летят большие вложения в разработку инструментов, фреймверков и самих линуксов с опенсорсными прогами, кто втюхал что его проект по улучшению лучше ( мммм звучит) тот и получит финансирование. а вы ешьте. блин не думал что буду бубнеть, но когдато я на WPF и .Net пилил и думал не буду на фронт или ноду ваще смотреть, но даже тогда я не так бубнил и был недоволен как щас с некстом. после того как я уже около 3х - 5ти месяцев периодически пилю что-либо на этом. и опять таки, если бы его не рекламили как универсальный швейцарский нож/палатку/бензопилу, может я не был бы так разочарован но помимо пиара на старый реакт забли большой ДенаАбрамовый.... сервер компонент....

[@alekseybord5373]

А почему никто не пишет что все эти серверные штуки нужны абсолютно и очень-очень далеко не всем. Такое ощущение, что человечество страдало от spa, но react c rsc и next с его ssr пришли на помощь. Сейчас вся эта фигня глобально впаривается всем подряд как панацея от какой-то страшной болезни.

[@it-sin9k]

ну почему, там же и Дэн Абрамов в твите говорил, что тем кому нужно вот используйте. Мы сейчас в проде не пользуемся RSC, бизнесу особой пользы от этого нет :)

[@alekseybord5373]

@@it-sin9k Ну да, агрессивно не впаривают, но в этом и хитрость ) Это мягкое, ненавязчивое принуждение со словами "это не обязательно, но лучше все-таки на клиент доставлять статичный html, поэтому лучше используйте". Вот теперь и будут постепенно на админки и бекофисы ставить ssr и всю прочую чушь, которая там не нужна

[@it-sin9k]

ну это да) согласен)

[@uCryNet]

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

[@izzy7541]

@@uCryNet Мало того что возвращаемся, так возвращаемся через одно место. Теперь у нас между бекендом и клиентом чёрная дыра.

[@EwKlidstudio]

Уход от классов был ошибкой. Так бы у нас был нормальный апи от унаследованного серверного и клиетского компонента, а сейчас у на идиотские eslint правила, директивы, ошибки в рантайме, мол зря ты посмел использовать серверный компонент в клиентском. Они говорят «смотрите как классно, мы можем поместить серверную логику в клиентский компонент», но можем передать только через пропсы готовый серверный компонент. Никакой инкапсулированной логики мы не можем сделать, где клиентский компонент использует серверный. Это сильно усложняет разработку. Я пишу на реакте уже года 4 и у меня до сих пор нет понимания, как кому-то могло показаться сделать такое убогое api как СОСТОЯНИЕ у функций, доступ к которому нужно получать в ОДНОМ И ТОМ ЖЕ ПОРЯДКЕ. Сделать ужасное api контескстов, из-за которого самым популярным вопросом является «какой стейт менеджер использовать». И т. д. и т. п.

[@youtubehhhh]

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

[@oWeRQ666]

@@youtubehhhh сигналы и виртуальный дом не противоречат друг другу, см Vue

[@cinicrus]

Можно ещё Forest глянуть, от разраба Effector. Там понятия ререндер в принципе не существует)

[@golden_smiles]

Почему надо ссылаться на автора хака в качестве авторитета, чтобы узнать хак это или нет. Пользователям (девелоперам) придется пользоваться и судить, а не ему. 1. Мне лично побоку мнение Дена, и 2. по-моему хак, да еще какой. Реакт и так довольно неочевидная библа с кучей мутных конвеншен (и да, хуки туда же, начиная с их нейминг конвеншен), теперь стало все еще более непрозрачно. "Вся фишка в том что как бы да, и как бы нет." -- этим все сказано.

[@Vosoo-e9r]

Просто надо вырасти и переходить на серейезные стеки

[@golden_smiles]

@@Vosoo-e9r каждый инструмент хорош для своего дела

[@Vosoo-e9r]

@@golden_smiles для пет проектов если только

[@cinicrus]

Абрамов обычный юнит, который кушает свой корм и никогда на публику не скажет правду - реакт, говно, ааааа, мы обосрались, пизда, пизда, огорчение 😂 его уволят тогда завтра же. Хуки хуета, которая после классов принесла боль и страдания - из-за толпы джунов, которые начали думать что умеют что-то проектировать. А по факту вкладки по 2Гб памяти жрут 😢

[@s.o.v.a9837]

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

[@virtual5754]

Так это же тот доклад, после которого несколько месяцев мемы про sql инъекции делали

[@it-sin9k]

ага) побочка та еще)

[@rgnaros]

Ну по первому тезису согласен, спа далеко не для всех сайтов надо RSC как по мне штука сомнительная, но тут критиковать не буду Хуки не были ошибкой, ошибкой было сделать их так, как сделали сейчас. Как по мне идеи вью с реактивностью, их хуками, и методом рендера куда удобнее. Как по мне реакт мог запилить примерно следующую конструкцию, у нас есть функция, это что то типа setup, и уже она возвращает метод рендера. И все хуки сдвигаются в тот самый setup Со стилями сложно сказать. Как по мне да, есть проблемы, но не прямо беда. А беда как раз в огромном количестве технологий(начиная с нативный css-ов заканчивая всякими тайлвиндами и styled components). Но это все же проблема не только реакта

[@gooseob]

"функция, это что то типа setup, и уже она возвращает метод рендера" в чём смысл этого? тайлвинд и styled components это ж вообще про разное

[@rgnaros]

​@@gooseob Функция типа setup выглядит примерно так const TestComponent = () => { // начало setup const data = ref(0); // его конец return () => (Count {{data.value}}) // метод рендера } А суть в том что мы получаем явный метод инициализации, и явный метод рендера. При этом все наши функции которые мы создаем в setup-e они не пересоздаются, нам не требуется париться с useMemo и useCallback, и еще много чего. При этом да, мы получаем не совсем чистую иммутабельность, но опять же она достигается тем, что у нас рефа возвращает обьект с сеттером, а не с глубокой проксей И это если что примерная структура вью компонента после компиляции темплейта На счет стилизации. Ну я о том же. Это зоопарк решений, в котором есть куча различных идей, и мы от проекта к проекту меняем их. С одной стороны мы получаем чуть чуть более удобное решение, а с другой очень сильно теряем в унификации

[@Lindar-bu7by]

Спасибо большое за работу, всегда интересно посмотреть твои видосы)

[@it-sin9k]

спасибо!) очень благодарен за поддерживающие комментарии!

[@oWeRQ666]

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

[@mrstronciy1060]

Дыд маунт и дыд апдэйт - это угар 😂😂😂

[@АлександрАртюхов-у6я]

Спасибо за видео. Мало такого контента

[@Igor-yh4gl]

И почему я не удивлен что именно Vercel выпускает доклад в котором продвигают rsc

[@ivanrussui4126]

В детстве обожал Лего! Ссылка в описании на доклад Лего будет?)

[@it-sin9k]

уже добавил) kzbin.info/www/bejne/b3SxaoV5r9-hkMU

[@alexdubkov6998]

RSC открыл ящик Пандоры - дебажить и понимать такой код будет то ещё "удовольствие"

[@gritsienkooleg3447]

Спасибо Дружище! Лайк и коммент за качественный контент 🔥

[@EduardAndreichev]

Спасибо за ваш труд! Как всегда очень познавательные видео и без воды🥰

[@it-sin9k]

спасибо за такой приятный комментарий!)

[@artsiom5942]

Совсем не согласен с доводами на тему внедрения хуков. Основная идея - у нас были проблемы, мы решили ее изобретя хуки, вот если бы их не добавили - так бы и жили с этими же проблемами. А кто мешал, например, сделать, чтобы та же функция component will mount возвращала массив функций (ну или одну) которые отпишуться. Из описанных проблем не было видно, как конкретно на тех же классах нельзя было решить проблемы. По ощущениям все было придумано во время функционального хайпа, чтобы показать, что в реакте тоже "стильно, модно, молодежно". При этом я не говорю, что хуки это плохо. Скорее вопросы к аргуметам

[@KrtNinjaDev]

Не использую хуки совсем, при этом приложения даже спустя годы разработки больших приложений так и не нашел им применения :) > Классы усложняют изучение Реакт А надо начинать изучение с реакта, чтобы стать заложником библиотек с самого начала?)

[@SuhushinAS]

Серверные компоненты - это принципиально неправильный подход: это перенос ответственности за потоком данных с уровня приложения на уровень отдельного компонента. А потом 500 компонентов разом кинут запрос на одну апишку...

[@it-sin9k]

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

[@SuhushinAS]

@@it-sin9k Значит будет 500 запросов в базу, принципиальной разницы нет.

[@SuhushinAS]

@@it-sin9k Я и говорю, что нужно отделять работу с данными от представления, а в серверных компонента всё сваливается в одну кучу

[@ГенаПетров-н5ы]

Где ссылка на доклад?

[@it-sin9k]

уже добавил) сорри) kzbin.info/www/bejne/b3SxaoV5r9-hkMU

[@vanivka]

Ситник под бедой со стилями имел в виду что нет официального React way для их использования, так или иначе уже сами разработчики решают, как же их завозить, а самый популярный способ через css модули имеет проблемы поддержки этого способа или типа того (это короткая моя интерпретация), в других фреймворках такой проблемы нет

[@it-sin9k]

хмм, ну разве что так. Возможно я настолько привык к особенностям CSS modules, что уже не замечаю неудобств с ним. Да и мне кажется у сообщества особо запрос нигде не стоит на изобретение такого способа. Нужно ли это кому то?

[@imthebest8000]

А как же ссылка на доклад?

[@it-sin9k]

так и знал, что, что то забыл)) kzbin.info/www/bejne/b3SxaoV5r9-hkMU Добавил в описание)

[@imthebest8000]

@@it-sin9k Спасибо 🙏)

[@МихаилВикторович-р2я]

Это реальные факты, могу обосновать каждый тезис: 1. SPA лучшее решение для всех типов сайтов. 2. RSC - это поворот не туда 3. Хуки - были правильным решением 4. Со стилями все круто

[@it-sin9k]

спасибо что поделились) а что в RSC самое ошибочное?)

[@МихаилВикторович-р2я]

​@@it-sin9k то что бэк должен быть бэком, а фронт должен быть фронтом. Фронт должен уметь работать без бэка, а бэк без фронта. Почему вообще существует такое понятие как конвейер, потому что лучше уметь делать одну какую-то вещь, но делать ее идеально. Создание приложения это то же производство. Автомобиль может с нуля собрать один человек, но гораздо эффективнее и дешевле собирать автомобили на конвейере. Так и приложение лучше собирать на конвейере, бэки делают бэк, фронты фронт, тестеры тестят и т/д. Вот напишу я приложение с помощью RSC, буду делать запросы в БД и все такое. Мне скажут надо еще нативное мобильное приложение прикрутить, а еще плагин для хрома. И что мне для каждого фронта отдельный бэк писать? Приложение на RSC не расширяемое получается. Если рассматривать RSC с точки зрения серверного рендеринга, то это уже SSR и подобное ему, это уже другой вопрос (хотя и SSR бредовая идея).

[@grenadier4702]

Я слишком консервативен для этого булщита, видимо пора уходить в embedded

[@it-sin9k]

ахах)

[@rashzh5502]

💯

[@yersainaldabayev8836]

То есть медленно но верно уходим от FLUX?

[@en_kratia]

Если Вы не поняли почему беда со стилями, то Next.js уже 4й год борется с webpack`ом, чтобы тот правильно обрабатывал css файлы некста, они уже сдались и написали новый бандлер под названием Turbopack и все равно безуспешно (хотя и стало лучше). Буквально пару недель назад об этом писал разраб некста.

[@ИсмаилАюбов-ы3я]

Спасибо за видео

[@ОлегКочиев-э9т]

Спасибо за познавательное видео❤

[@ЕгорЛазука-й1э]

Спасибо

[@kgb9742]

Как же достали с этим this, это легенда кочует уже из поколения в поколение разработчиков, что люди не понимаю как работает this внутри функции.

[@it-sin9k]

а почему это легенда?) это же реально была боль) я помню эти темные времена)

[@bizuha]

Почему была? У нас на проекте до сих пор есть легаси компоненты на тыщу строк, которые страшно переписывать. Если работает - не трожь 😊

[@it-sin9k]

ахаха) я уже давно не работал с классами) уже забылось)

[@Александр-ф9в4ю]

Вся ООП модель JSа это сущий ад и кошмар

[@kgb9742]

@@Александр-ф9в4ю Я бы так категорично не говорил, но в целом я с вами абсолютно согласен. Я до сих пор помню статьи до появления классов, как люди извращались обертывая методы по несколько раз реализуя их приватность и прочие штучки.

[@boldureans]

RSC классная тема. Единственную проблему вижу с перехода классических SPA это кроме классического бекенда на том же .NET нужно еще и ноду ставить и дублировать rest api :|

[@it-sin9k]

любая миграция на новую историю, требует переписывать) вообще мигрировать с SPA на Next задача достаточно сложная) мы даже не смотрим в эту сторону на работе)

[@boldureans]

@@it-sin9k Согласен. Только проблема не только миграции, но и стоимости. Если у вас тот же BFF в классическом бэкэнде без ноды, то с ней стоимость деплоя вырастит значительно. К тому же надо думать стоит ли дублирование серверной логики на ноде всех плюсов RSC? Для нас как разработчиков - однозначно. Для бизнеса и клиентов уже под вопросом.

[@DrFreez]

​ @it-sin9k если применять при разработке FSD или CA, то никаких проблем с переездом в next. Сначала у вас обычное спа на нексте, потом вы потихоньку перепиливаете его в мпа. Существует только одна проблема по которой перекат на некст болезненый -- вы сильно умные и любите удалять гланды через альтернативные отверстия

[@NeQwerty0]

А почему надо дублировать rest api? Я так понял можно из серверных компонентов запросы к беку написанному на другом языке делать напрямую. Но ноду придется ставить, да, чтобы там компоненты работали. Реакт на сервере как BFF по сути будет сам по себе.

[@egorovsa]

Само высказывание про использование СПА для всех типов сайтов является ошибкой, поскольку надо быть идиотом, чтобы использовать СПА для сайта который планируется продвигать в поисковиках (Имеется. в виду SPA в чистом его исполнении, без намека на SSR). Тоже самое как тащить НЕКСТ, когда тебе нужен простенький СПА. Короче высер Ситника на вентилятор.

[@cinicrus]

эээ, пауки уже давно умеют js запускать. о_О

[@andreybogdanov3]

Ой, мало ли кто там что взбзднул в твиттере. Собака лает, караван идет

[@it-sin9k]

ахахах)

[@NeoCoding]

я похоже один кому всё нравится в Некст и реакте. ну мож кроме оптимизаций, которые скоро дропнут

[@it-sin9k]

я думаю таких много) просто негатив люди любят писать чаще) чем позитив)

[@alexeyfilippov42]

хм а почему хуки были ошибкой по его мнению

[@it-sin9k]

когда я попытался выяснить, оказалось, что я душнила)

[@ИванСамарин-ц6к]

Ну, вообще есть предположение Сам уже давно отметил несостыковку: реакт позиционируют как библиотеку для отрисовки (ни больше, ни меньше), а хуки - это набор решений задач работы с данными. Можно поспекулировать навроде "эта работа с данными чисто для визуала/рендеринга", но все мы понимаем Идеологически было бы правильно сделать подлибу @react/hooks. Но, правда, личный вывод - просто назовите вы реакт "платформой для создания веб-интерфейсов" или вроде того хд Скорее всего автор треда имел в виду что-то другое , конечно)

[@Илья-с1л6э]

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

[@shrpne]

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

[@Илья-с1л6э]

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

[@TestTest-n8y]

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

[@tranquility_lane]

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

[@TestTest-n8y]

@@tranquility_lane Обычно привык не начинать вести диалог с людьми, которые начинают с диалог с подколок, с намерением "унизить".

[@Nomikama]

Ну что же, Реакт потихоньку превращается в... PHP + JQuery? По сути так же строили раньше - куски серверного кода в премешку с HTML разметкой, которой управляли через JQuery

[@lpx7634]

Может ли кто-то кратко описать как данная проблема решается в Angular и Vue? Потому как мне кажется это не столько проблема React как в целом веба когда по каким-то причинам есть необходимость работать с серверными данным на уровне компонентов. Типа изначально писали код в таком стиле потому что так было удобнее всего. Потом подумали про архитектуру и начали разделять код, а потом все равно пришли к тому что в некоторых случаях ну реально так удобнее всего

[@smith-dev]

@@lpx7634 причина очень проста - React обсуживает боли фейсбука. Если ты не пишешь фейсбук, то и смысла реакт брать в 2024 нет.

[@ds_amahasla]

@@lpx7634 Angular изначально более строго структурирован, с чётким разделением слоёв через Dependency Injection, сервисы и компоненты. Angular имеет чёткую архитектуру MVC/MVVM , где логика, данные и представление хорошо разделены. Сервисы отвечают за бизнес-логику и взаимодействие с сервером, а компоненты - только за отображение данных и передачу команд сервисам. Такое разделение помогает избежать смешивания уровней и делает код более поддерживаемым, что хорошо для больших проектов.

[@AlexanderBorshak]

@@lpx7634 За Ангуляр не скажу, а во Вью, насколько знаю, рендеринг на стороне сервера отдан под отдельный фреймворк (Nuxt.js). То есть, проблемы как бы и нет как таковой. Примерно то же было и на Реакте, где SSR был в отдельном фреймворке поверх Реакта (Next.js), но почему-то кор-тима Реакта решила, что данный момент надо поправить, и охватить серверный рендериг прямо в Реакте ))) Кстати, если не нужна сильная интерактивность на клиенте, то проблему вообще можно решить на корню, взяв HTMX. Он прост как палка, там даже JS скорее всего не придется писать, разве что только для чего-то хитрого. Зато сразу SSR и SEO из коробки. Для простых сайтов - самое оно.

[@oWeRQ666]

Для меня реакт с самого появления выглядел как шаблонизатор который позволяет писать клиентские шаблоны как на сервере, не императивный подход с jQuery и костылянием интерактивных элементов поверх только что вставленного куска html, форма отрендерилась, выполнился экшен, отрендерился результат, так работает и с серверным подходом и с реактом, основная разница в обработки экшена, но теперь мы получили продолжение этой истории. Так что нет, никакой аналогии с jQuery не просматривается, с php в некотором смысле да, но только в том как работали старые многостраничные приложения на сервере.

[@DubinArtur]

Пока не понятно, как работает объединение серверных и клиентских компонентов. Надо в это занырнуть, посмотреть примеры и потыкать, как работает

[@it-sin9k]

так тут уже все рассказано) kzbin.info/www/bejne/jpvRgn-qn6t_jq8

[@liganshow]

возьму фразу на заменту) как стану тех лидом, достану ее, буду юзать)

[@liganshow]

Самая большая ошибка react, это посоветовать использовать, полное костыльное гавнище, next js. Это полностью хуйня, особенно с app route. Там где в react я делал все легко и просто и быстро, в next просто раздражает. Тот же уебанский роутинг

[@it-sin9k]

поэтому создатель react-router пилит v7, где можно будет использовать RSC и т.д. Вот у него как раз продающий момент, что все будет как раньше и не нужен вам Next)

[@liganshow]

@@it-sin9k дело не в том, что нам нужен или нет next, я могу сейчас с тем же vite работать с ректом и все ок. А в том, что сам реакт склоняет, своими рекомендациями на их сайте, юзать фреймворки такие как некст, и ни какой vite на сайте и близко не вспоминается. Я думаю это плохая тенденция. Привет догоняющему vue)

[@yrsafam]

Легко и просто в SPA? 🤔 Next решает определенные задачи, как и все остальные инструменты)

[@liganshow]

@@yrsafam Да, именно. И не было вопросов к next, когда мне нужен, ну к слову, SEO. Я думаю, это единственная разумная задачу которую может решить SSR. Мне когда говорили, что нужен SEO, я брал next, не нужен - все возможные вопросы покрывал react. (правда потом клиенты приходили к тому что SEO не достаточно, еще бы и CMS какой то, и тут next js не чего не предлагал тогда, кроме headless cms)

[@yrsafam]

@@liganshow тогда не понял в чём проблема не использовать next.js, если SSR тебе не нужен. Бери Vite вместо CRA и делай привычную SPA

[@ssurrokk]

❤

[@chikenmacnugget]

Какой вопрос Ситнику задал, такой ответ и получил, а здесь выворачиваешь уже в третью сторону…

[@it-sin9k]

ничего не понял о_О

[@chikenmacnugget]

@@it-sin9k ну ты посмотри на 3 вещи. 1. Что ты спросил у Ситника 2. Какой ответ получил 3. И какое умозаключение на его ответ дал. У тебя здесь очевидная несостыковка. Декларируешь одно, а показываешь другое

[@chikenmacnugget]

@@it-sin9kты декларируешь, что спросил: «Почему рск это хак», а на деле спрашиваешь «где почитать об этом». Это абсолютно 2 разных вопроса, несущих 2 разных смысла. Таким образом происходит подмена понятий. К тому же, если слова Дэна разнятся от доклада к докладу, то это доказывает то, что свою речь он скорректировал. А следственно это не как не доказывает его реального отношения. Факторов для этого может быть много…

[@levsonc]

@@chikenmacnugget «об этом» относилось к утверждению про хак. Нельзя же так грубо игнорировать контекст!

[@chikenmacnugget]

@@levsonc где игнорирование контекста? Человек задал один вопрос, а декларирует другой. Он не просил объяснить конкретно Ситника, он просил источник. А задекларировал как будто Ситник не смог ответить на вопрос. В ответ могу Вам также ответить. Нельзя же так грубо игнорировать развитие когнитивных способностей…

[@АлександрГригорий-е6о]

Ситник обосрал реакт, забыв снять штаны

[@Maxim9575]

какой умный комментарий, достойный автора - иди уроки делай шкила

[@chikenmacnugget]

Александр Григорий обосрал Ситника, забыв снять штаны

[@Александр-ф9в4ю]

​@@Maxim9575ситник, разлонтнься - иди реакт лучше подучи по видео айти-синяка

[@Maxim9575]

@@Александр-ф9в4ю лезь в воду не зная броду - это про вас недоскриптизеров 😄

[@TheLastSeason]

Я на ваш канал пришел, когда посмотрел крутые разборы технологий, глубже чем другие. Но в какой-то момент вы свернули не туда. Зачем вам это.

[@Evgeny..]

Реакт писали руские получается😂

[@alexandrcorbin]

Высасывание мозгов никто не отменял.

[@chikenmacnugget]

Реакт - фрик

[@wizardoflightnings6841]

Денчик, по ходу, чёлкой в бензин упал, как красиво переливается нефтепродуктами ))

[@it-sin9k]

ахахха)

[@izzy7541]

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

[@smith-dev]

С каких пор вью стал проще реакта? Вью конечно лучше реакта, но не проще.

[@uCryNet]

Как там поддержка TS в Vue 3? А то на работе сидим на второй версии и обновляться пока не собираемся, то даже перестал следить за развитием истории с TS.

[@smith-dev]

@@uCryNet идеальная поддержка TS. Во внутренности лучше не заглядывать, но для нас сделали очень удобный интерфейс.

[@izzy7541]

​@@smith-dev Субъективно, конечно, но я не вижу сложностей в использовании вью. В реакте больше проблем с перерендерами, больше зоопарк экосистемы, больше способов написать плохой код. В итоге, среднестатистический код на вью будет лучше, чем на реакте

[@swayok]

@@izzy7541 но шаг вправо, шаг влево с рельс - и получили головную боль. Про несовместимость либ 2го Вью с 3м я промолчу, это было очень больно для меня, после чего я в ту сторону больше не смотрю. С TS тогда тоже были серьезные проблемы, как и с подсказками в IDE (плагин был влючен). Вью - ограничивает, чтобы те, кто не слишком глубоко в теме, не делали ошибок. Для больших команд, в которых есть не очень опытные разработчики - Вью решает проблему качества кода. Реакт же дает возможность сделать всё что угодно, как угодно и как удобно тебе. Плюс есть огромное количество пакетов почти на все случаи жизни + сообщество значительно больше. Тот, кто хорошо разобрался в Реакте, врядли перейдет на Вью по своей воле.

[@go_better]

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

[@AndriiKuftachov]

Реакт изначально задумывался как веб-сайт Джуниора на PHP когда отображение вперемешку с логикой (в отличии от Vue и Angular). Но если они пошли дальше - это уже просто вершина говнокода.

[@oWeRQ666]

@@AndriiKuftachov Вам приходилось хоть раз переиспользовать весь шаблон без изменений в ангуляре или вью?

[@AndriiKuftachov]

@@oWeRQ666 ???

[@oWeRQ666]

@@AndriiKuftachov Должен же быть профит от разделения логики(нет), на самом деле в реакте отображение отделено не сильно меньше чем в однофайловом vue или angular подходе, но да чуть более гибко, можно с дурнины инлайном больше прописать, там где парсеры шаблонов вью и ангуляра начинают ломаться, в реакте доступен полноценный js посреди шаблона.

[@AndriiKuftachov]

@@oWeRQ666 в Ангуляр логику вообще в сервисах пишут, это и есть правильный подход.

[@bloodjopa]

@@oWeRQ666 компилится в функцию, которая рендерит html. В ней нет проблем с инлайнами, глопустями в коде и прочими штуками

[@vvlkblkc]

Если вы хотите ООП, типизацию из коробки, SSR (если требуется) c ExpressJS под капотом, то пользуйтесь Angular. А если у вас мозг с горошину, и вы хотите бесконечно переписывать сайт, в том числе с выходом каждой новой версии движка, то добро пожаловать в React.

[@Ernuna]

Стандартный паттерн хейта реакта в твите: - не понимаю зачем это нужно - квик/солид/ангуляр/вью это делают лучше - мы вернулись к php удивлен почему Дэн Абрамов вообще отвечает на подобные твиты

[@golden_smiles]

Потому что знает что это справедливый хейт. Повторяющийся паттерн не означает, что он неверный.

[@shrpne]

@@Qvazi74 ты не свободен в выборе, попробуй найти работу во фронтенде не на реакте

[@AlexanderBorshak]

HTMX! И все проблемы решены! )))

[@kaifaty]

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

[@it-sin9k]

да, мне реально нравится React :) не понимаю, всю эту волну хейта)

[@KuruApni]

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

[@АраГорн-ж5ы]

Именно. Сторонники реакта обычные фанатики, а не сторонники реакта весьма оригинальные и рациональные люди. Потому что мир чёрно-белый и естественно большинство черных, потому что сторонников реакта больше, а нас адекватных белых так не хватает этому миру.

[@Roger-qj4wu]

Особо впечатлительные, не осилившие инъекцию зависимостей, называют ангуляр ночным кошмаром😂

[@BOCbMOU]

Если ангулярщик не считает себя лучше других, то это не ангулярщик.)

[@shittywizzard5727]

Как же так вышло что ангуляр не используется повсеместно, если он абсолютно во всем так хорош? может быть существуют разные потребности, которые закрываются разными инструментами?

[@Илья-с1л6э]

@@АраГорн-ж5ы любой стронник "n-фреймворка" своего рода. фанатик) Инструменты надо брать под задачи

[@satanoffdev]

хорошо что ушел в Ангуляр и зарплаты выше, и конкуренциия ниже и технология - адекватней. Само название Реакт-а ущербное. Реакт от слова реактивный - но где в нем тогда реактивность или RxJS? Угадайте где есть реактивность

[@grenadier4702]

Правильно, она есть в Svelte. Используйте его

[@oWeRQ666]

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

[@scooterzav]

Давай поспорим, что в Реакте зп не ниже. Я приведу цифры и ты!

[@sv3163]

> Угадайте где есть реактивность в $mol ? 🤔

[@satanoffdev]

@@sv3163 именно

[@sergeygultyayev4828]

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

[@it-sin9k]

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

[@sergeygultyayev4828]

@@it-sin9k нужно руками импортировать файл, потом на импорт руками сослаться (по крайней мере когда я их пару лет назад трогал вебшторм не делал это сам, вроде). Очень не удобно. Тот же ангуляр, вью, астро - ты просто определил стили для класса и использовал класс. Не надо никаких прокладок из импортов и ссылок на них. Классик хтмл+цсс стайл. Может, конечно, проф деформация, но я такой флоу нахожу неудобным для себя 🙂

[@andriirastorhuiev208]

​@@sergeygultyayev4828 styleUrls: ['./deposit.component.scss'] что это для тебя? ты скорее навязываешь cli которая делает все это за тебя, как фичу. React это немного другое. Тот же astro, мне кажется ты сравниваешь вещи которые вообще никак не должны сравниваться :) Ты же не сравниваешь кузов автомобиля с двигателем?

[@bonnus4675]

@@sergeygultyayev4828 Вы так же можете использовать обычные стили для класса и использовал класс, использую классический css, css modules просто позволяет более удобно и проще контролировать что определенные стили, не выйдут за рамки компонента в котором они используются

[@KorolPaul]

@@sergeygultyayev4828 сам не люблю реактовский зоопарк библиотк для работы со стилями, но надо признать, что css modules - единственная нормальная из них. Но, при желании, и от нее можно отказаться, просто заимпортить глобальный файл стилей где-нибудь в руте приложения и просто писать имена классов текстом, безо всяких импортов.

[@lirrr6555]

объясните кто-нибудь уже что такое RSC?

[@egorovsa]

реакт сервер компонент .,, загугли.

[@it-sin9k]

так я же два раза в видео проговорил, что это и еще обложку на выпуск показал, где разбирается это все)

[@lirrr6555]

@@it-sin9k это же шутка как раз на то, что ты за пару минут целых 2 раза упоминал)

[@MahramsMusicc]

Мне кажется прогресс технологий не должен иметь под собой цель угодить бородатым программистам. Всегда было так: новые технологии встречались с критикой, подхватывались джуниорами и мидлами, на которых они потом становились сеньорами и так по кругу. ИИ внедренный в IDE и знающий контекст будет превращать всех в фуллстек разработчиков. А реакт успешно адаптируется под новые реалии. Если кому то нравится Qwik, SolidJS и тд, пожалуйста, радуйтесь что есть выбор. Можете в любой момент уйти. А RSC мне очень нравится, Server Actions в NextJS вообще пушка.

[@123vitaha]

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

[@it-sin9k]

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

[@123vitaha]

@@it-sin9k спасибо за ответ! В этом и проблема, так рекламировался NextJS что я решил попробывать. midleware и Next Auth, да, работает, ну это и понятно, но оно такое муторное, по сравнению с реакт роутером обычным, и стейт менеджментом, как например мой любимый MobX. И столкнулся с тем что сессии, чтение кукисов ( :) ), и многое другое, либо работает но не всегда так как ожидается или не совсем стабильно или не работает. Я могу ошибаться и не понимать что. да как в нексте, я не эксперт в нем... 🤷

[@swayok]

Я вот тоже решил один небольшой проект сделать на Next.js в качестве эксперимента, благо ни сроки, ни требования не ограничивали меня. Кое-что мне понравилось, но слишком много геморроя с локализацией, авторизацией (cookies на сервере очень специфично работают, точнее в одном месте работают, в другом - нет). Реализация middleware - вообще бред несусветный, пришлось делать свою реализацию, как в Laravel. Локализация клиентских компонентов - либо через передачу ВСЕГО словаря в контекст (а в чем тогда выгода?), либо через передачу частями в пропсы, что приводит к тому, что практически во всех клиентских компонентах нужно добавлять props типа trans. Это практически убивает возможность переиспользовать компоненты копи-пастом. Из хорошего - возможность маскировать запросы к бэкендовому API, который рамещени в отдельном проекте или сервисе. Мой вывод: для небольшого проекта типа "только клиентский UI", в котором критичен SEO - ок, можно и попользовать. Для чего-то более серьезного, с админками для сотрудников/бизнеса и прочего, next - это костыль, который очень сильно затормозит разработку, даже тем кто хорошо в нем разобрался. Да и с SEO вроде не всё так уж плохо у SPA с нормальным роутингом. Я проверял смежные проекты, которые написаны на React полностью и в гугле вообще небыло проблем с индексацией. Да и sitemap никто не отменял - с ним большие проекты всегда лучше индексируются чем роботом. Так что этот SSR, фактически, не особо-то и нужен сейчас.

[@123vitaha]

@@swayok еще добавлю, боюсь что с этим некстом реакт начнет скатываться в ангулярову дыру, когда ниче не работает, все криво, а чтобы работало что-то простое, роутинг с ролями, или что, подобное, надо будет потратить пол дня и молиться чтобы не сломалось при следующем пуше....

[@bloodjopa]

Слава богу реакт продоложает лететь куда-то не туда. Вакансий на вью будет все больше

[@papa_paskualle]

шо?

[@АлександрАфнасьев-и9ь]

Спасибо