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

preview_player
Показать описание
Недавно случилась заруба между Андреем Ситником и Дэном Абрамовым. Тема спора была как развивается React. Он по прежнему топ 1 или уже более новые иновационные решения дышат ему в спину. Все это мы и обсудим в текущем видео!

Ссылка на телеграмм канал

Поддержать Айти Синяка можно здесь:

00:00 Анонс темы
00:24 Твит
01:11 Хуки - были ошибкой
01:50 Почему придумали хуки
04:25 RSC - неудобный хак
05:15 Мнение React команды
06:05 RSC как плагин
07:15 React lego

-------------------------

Данный канал создан для инициирования бесед на различные темы IT сферы (социальные / технические), а также для тех кому короткая видео выжимка статьи, выступления на конференции или же просто личных мыслей, являются более удобным форматом
Рекомендации по теме
Комментарии
Автор

На правах деда, хорошо поработавшего еще с классовыми компонентами скажу так: хуки решили проблемы людей, которые не могли в проектирование ПО. Не могу сказать, было ли это ошибкой, плюсы хуков очевидны. Но по моему мнению, без них вполне можно было бы обойтись.
А вот что касается серверных компонентов - вот это уже реально треш. К самому ССР у меня претензий нет, но по итогу он вылился в попытку создать фронтендо-бекендовский монолит, обмазанный со всех сторон подкапотной магией.
Мне это напомнило древние веб формы от майкрософта, от которых давно уже отказались. Есть только один нюанс: веб формы не предназначались для разработки сложного фронтенда. В отличии от реакта, который при использовании всех этих современных фич превращается вообще в непонятно что.

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

Кирилл-жмн
Автор

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

alekseybord
Автор

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

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

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

blockblock_
Автор

У меня немного голова кипит каждый раз когда я пытаюсь как эта смесь серверных и клиентских компонентов работает под капотом. Там же всё равно RestAPI зашит под капотом, просто неявный.

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

Мы вроде как убежали от этого как от кошмарного сна и перешли на более явную REST API модель, а теперь опять продаём это как новую фишку. Меня это пугает, если честно.

kamilmodest
Автор

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

TestTest-ny
Автор

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

alexmarch
Автор

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

s.o.v.a
Автор

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

youtubehhhh
Автор

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

АлександрГерасимов-сщ
Автор

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

TheLastSeason
Автор

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

en_kratia
Автор

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

golden_smiles
Автор

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

kgb
Автор

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

EwKlidstudio
Автор

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

ivanrussui
Автор

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

oWeRQ
Автор

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

gritsienkooleg
Автор

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

Lindar-buby
Автор

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

Igor-yhgl
Автор

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

bloodjopa