Выкидываем ReactJS [ru] / Александр Соловьев
HTML-код
- Опубликовано: 12 сен 2024
- Видео с онлайн-конференции JavaScript fwdays'20 autumn, которая прошла 26 сентября 2020 года.
Описание доклада:
Все знают, что много джаваскрипта - это плохо. Но как быть, когда сайт большой, и не хочется через несколько лет упереться в стандартную проблему jQuery (и других библиотек того же поколения) - постоянные конфликты композиции?
Послушайте о том, куда решились спрыгнуть в Kasta, и что в результате получилось.
Страница доклада и презентации:
fwdays.com/eve...
Больше докладов и видео по теме конференции:
fwdays.com/eve...
Fwdays более 10 лет занимается организацией масштабных конференций для разработчиков таких направлений: JavaScript, .Net, Python, Data Science, PHP, QA, Highload, Architecture, DevOps, Databases.
Больше информации про актуальные события:
fwdays.com/events
Подписывайтесь, чтобы первыми узнавать про старт продаж билетов по самой выгодной цене:
Facebook: / fwdays
Twitter: / fwdays
Telegram: t.me/jsfwdays
![Як знайти свою половинку або чому алгоритми важливі [ukr] / Христина Ландвитович](http://i.ytimg.com/vi/XVdPi0_YM0k/mqdefault.jpg)
![Як знайти свою половинку або чому алгоритми важливі [ukr] / Христина Ландвитович](/img/tr.png)
![Александр Соловьев / Как modnaKasta трансформировалась [ru]](http://i.ytimg.com/vi/WssdWSbAPKE/mqdefault.jpg)
![Почему я отошел от TypeScript в своих React-проектах и куда [ru] / Илья Климов](http://i.ytimg.com/vi/jnSHRPCTFPc/mqdefault.jpg)
30:30 «Реакт позволяет делать всякие странные вещи» - аргументация от бога)
Александр - человек, из-за которого я начала кодить на реакте после уматного доклада) а ещё коллеге не-программисту показывала урезанную версию - ему понравилась)
2024: Подозрительно похожий htmlx набирает обороты) React становится Server-Side-Rendering
Александру спасибо за супер-доклад! Оказывается, это он придумал идею, а htmx - уже подхватили. Нереально крут!
Спасибо, интересно. Но не покидает чувство «спустя 10 лет бумеры снова изобретают $( "#result" ).load( "ajax/test.html" );».
Ну я там вроде пытался описать суть, но она следующая: жквери может делать то же самое, но 1) локальность поведения отсутствует - ты не можешь, смотря в хтмл, понять, что происходит - что большой плюс с реактом и остается на месте с твинспарком и 2) жквери тебя никак не ограничивает и потому жс плодится безнаказанно - тут же это одна из основных тем, чтоб жса было поменьше, и пока вроде относительно терпимо, не оч быстро растет он. Это еще надо наблюдать, полгода всего прошло, но цели именно такие: сделать локальность поведения и ограничить рост жса.
@@asolovyov , да, я понимаю - я без «наброса». Это фундаментальная проблема фронтенда - «поймать» этот баланс между количеством передаваемых по сети данных и размером бандла, потому что всякие демки на TodoMVC - это, конечно, хорошо, стильно, модно и молодёжно, но в реальном коммерческом проекте боттлнек где-то в районе сетевого взаимодействия (ну и шаблонизатор, да - дайте уже нам нормальный изоморфный (!) декларативный (!!!) реактивный шаблонизатор).
Чёт меня понесло…
@@Realetive райт, ну мы так и влетели, что пока мы переписывали старый сайт, где фич оч мало было (потому что там jquery-код сам себя гнобил и реально любое движение на фронте было болезненным) - всё было супер с реактом. Но за 5 лет оно всё превратилось в огромную тормозящую хрень. И главное что разработчики сидят на нормальном железе и боли особо не чувствуют, а оно болит.
Так ещё тема, что одно из переживаний было про интерактивность, типа гоняется по сети данных меньше етц. Вот буквально вчера обсуждал это (тоже публикация доклада триггернула), и всё в принципе не хуже, чем и раньше. Попап добавления в корзину обычно появляется через ~50ms, типа 3 кадра - вполне терпимо. Очень хочется загрузку списка товаров ускорить, там прям ДОЛГО может быть, но там куча работы, понемногу движется...
Александр, кажется вы ни разу не упомянули 'svelte', у них сейчас есть 'SSR' (может быть была и год назад?) - не пробовали, не тестировали, что думаете об этом?
Очень мотивирует. Временами мне кажется что Web жуткая скукатень. В рассказах Соловьёва это прям приключения без конца.
Я не хейчу, но есть вопрос. А как же тогда люди выбивают 100/100 в lighthouse на основе фраемворков?
Что насчёт ssr для быстрого старта? Почему нельзя было оставить реакт для написания кода, а потом из него делать , то что делает twin spark?
Это же отдельная специальная паралимпиада (в том смысле, что на ногах гири в виде реакта/вью). Я хз, есть ли люди, у которых такое несколько лет в продакшене на сложном приложении, но это же все вопрос компромиссов. Мне очевидно, что на реакте это будет делать просто слишком дорого, я не готов столько - лучше фронтендщики будут больше времени на осмысленную работу тратить.
Про сср мне непонятно: я ж несколько раз там говорю вроде, что у нас он есть с самого начала. Как вообще может екомерс без сср быть?
Последнее предложение не понял. :(
@@asolovyov Слава Богу - вы не доктор! Лисп в вебе - это как операцию на руке делать через мизинец на ноге.
@@asolovyov Интересно, на что будете переписывать касту через годика три. Давайте на ассемблере под ARM. И главное - доклад про это fwdays!
Весь код - бек + фронт пишете на асме. Далее, все это транслируется. Фронт - в asmjs, а бек - в JVM байт-код.
Трансляторы напишете без проблем - Лисп вы знаете, Кложуру умеете. Осилите!
Летать будет! 1000 из 100 в пейджспид покажет!
03:53 Мужик забыл как его зовут
подумалось, что сам мужик забыл как его зовут
Это пятёрка
Как стили? Инкапсуляция в компонент?
Вопрос. Загружаемый аяксом HTML чистый, или тоже c аттрибутами фреймвёрка?
В реакте с HTML плохо, но во вью есть аттрибут v-html.
Я получал на реакте 98 баллов с нативным ssr еще в 16м. Плохо написать можно на чем угодно, проблема обычно не в молотке, а в руках.
согласен, что с реактом можно получать приличные былы, даже не особо заморачиваясь(если конечно проект начинался сразу с SSR). Но тут я так понял что есть такая проблема, что юзают не js а clojurescript, возможно что это и добавляет какие то ограничения
Так не юзайте clojurescript если это добавляет проблем :-D. Инструменты обычно используют чтобы решить проблемы, а не добавить их :-D. Я только не пойму одного, зачем рендерить на сервере все? Я понимаю отрендерить точку входа, чтобы получить разные бонусы, но зачем рендерить все? Это же огромная нагрузка на сервер в случае большого трафика. В чем бонус? Странички тормозят на клиенте, ну так скорее всего это можно просто переписать более оптимальным способом, конечно если реакции ховера писать условиями на js... я даже не могу представить что такие товарищи могут понаписать еще, конечно может тормозить, но простите какое это имеет отношение к реакту, или скажем ко вью, или ангуляру или к чему угодно вообще?))))
Есть у меня один товарищ, работал в одной компании N являющейся одной из крупнейших IT компаний России и там они пилили одно приложение, интерфейсы были у них на react, так вот они использовали чанки, одна страница один чанк, каждый чанк весил у них по 5 мегабайт. Всё грузилось с отменой кеширования и все UI безбожно тормозили. С реактом ли тут проблема была?.....
@@artemgoncharuk5174 но сам подход с чанками довольно хорош. Проблема ведь только в отмене кеширования?
@@user-zg3vt6zh6y конечно, но там проблема была не только в отмене кеширования, там была масса проблем. Просто показательный пример, как можно взять что-то хорошее и сделать на этой основе что-то настолько плохое.
Вывод из всего сказанного: новая технология - вау! Это решение все- проблем!
Прошел год: это все отвратительно!
Бесконечный цикл радости и разочарования вызванный тем, что когда девам становиться скучно писать на чем-то и оптимизировать это что-то - они мечутся в поисках новых волшебных «либ и фреймворков»...
Я не один на этой планете , дай обниму !? ^^
Coupling академически переводится как Зацепленность.
А как же StimulusJS?
никак...
Так это способ писать жс, а я хочу поменьше этого. :)
А на чем тогда писать фронт?
И переписывает полностью году или идёт патчинг html?
Свой кусок хтмля заменяет. Если посмотреть демки - там всё понятно становится.
Стили ровно как и раньше, у нас же приложение не с нуля пишется, и подход к стилям мы не поменяли.
StimulusJS мне не нравится, там надо писать собственно JS постоянно.
*патчинг Dom
Как перенес с фронта на бэкенд? ..як ..як и в продакшен!
33:41 а разве это не называется всплытие и погружение событий? И это вроде одна из основных идей DOM.
Чуть не то. Пример: у тебя в компоненте сказано что знач пошли такой то запрос (ну и результатом замени себя). И тут ты его инклюдишь в каком то месте где выше сказано что таргет там-то. И внезапно твой компонент наследует это поведение и заменяет результатом не себя, а третью сторону.
Офигенно весело, да? Хватило один раз вступить, чтоб выпилить этот ахтунг.
@@asolovyov спасибо, за ответ)
Кстати очень сильно напоминает bootstrap с его data-аттрибутами
Короче если архитектор повернутый асс и все девелоперы синьоры то с вебом можно извращаться как угодно. Проблема в том что всё встанет раком если заказчик захочет сэкономить и уволит всех синьеров а наберёт мидлов с джунами. На реакте-ангуляре всё бы продолжало работать, хоть и медленно.
Ну зашибись теперь, давай жить в унынии, медленно писать медленные сайты на пхп и ангуляре, зачем делать нормально?)
Про повернутых синьоров ничего не понял, кста, мы выбросили супер-сложную штуку и написали себе либу на тыщу строк простейшую. С очень очень простым поведением, совершенно очевидным.
@@asolovyov Ну давай скажем честно, таких как ты десяток ну два в СНГ а проектов тысячи. Некому столько персональных фреймворков писать и поддерживать.
@@andreymanaenko1638 та ладно, если б там фреймворк был, там 680 строк кода. На гитхабе не видно, почти все коммиты мои, но внутри проекта его уже все, кто хотел, потрогали, оно очень простое.
@@asolovyov На пхп отличные сайты можно писать.
Свелтекіт виб’є усі 100, некст джс виб’є 95. Ті велосипеди того не вартують.
Посмотри на последователей языка Smalltalk: Lively Kernel, Glamorous Toolkit, Pharo
А раскрой мысль подробнее?
Саша, подумай о родном селе)
А почему не взяли next.js?
Потому что у нас уже было лучше последние 5 лет?
Как по мне это все ужасно, пишут лютую дичь) Очень странная фигня. Если Соловьев уволится то Касте прийдется закрыться)
Если Илон Макс умрет то ему придется умереть ...
если он не оставил после себя преемников - да. но обычно в команде есть единомышленники. так что - это вопрос - умрет ли проект если Соловьев уволится.
Сложилось такое впечатление, что был вполне себе адекватнный сайт на джанго (такой же мог быть и на пхп фреймворке). На фронте использовалось спагетти на джквери, кооторое тяжело было поддерживать.
Эти ребята, вместо того, чтобы привести в порядок фронт, работали 5 лет и пришли к какой-то жутко навороченной тормозящей приблуде.
Причем у них по еврейски как-то устроено, что в мобильных приложениях тоже куча логики, которую можно было на той же джанге оформить в виде АПИ на сервере и дергать через ХТТП по необходимости. Сами аппки - это просто фронт, дернул сервер и отрисовал красиво. Может я недопонял по мобильной части.
Технологии тоже какие-то слегка маргинальные - кложура, кложурескрипт. Реакт еще куда ни шло, но вот эти кложуры - дичь какая-то, если честно.
И еще вот этот интеркулер.жс - это жесть какая-то, первый раз слышу о таком. Атрибуты писать, а там еще они наследуются. Поэтому оно и неизвестно - потому что дичь!
Не кажется ли вам, что занимаетесь ерундой? Каста - обычный интернет-магазин по большому счету. Банальный сайт на пхп и пара моб приложений - торгуй нихачу!
Выдержит любой хайлоад в сотни тысяч юзеров, если нормально сделать И СЕО в порядке будет. Да, страница будет обновляться чаще, страниц будет больше - на каждый продукт будет страница. И что?
Каста тормозит не потому, что у Андроида тормозной ЖС движок, а потому что кложура, потому что оверинжиниринг дичайший. Во что вы превращаете веб? Кложура - это просто полный трэш!
Идите на хаскел пишите, функциональщики - достали уже! Отбираете у нас, скромных пхпшников, рынок. Еще и голову выворачиваете наизнанку. Каждый день по 10 фреймворков выдаете. Когда вы уже успокоитесь?
Пф вдохнул haskell, не тянет назад.
Насчет оверинжиниринга, разобрался бы сначала какие абстракции данных в кложуре доступны, а не писал бы такие глупости. По сути то какая функциональная разница для пользователя? У тебя там в конечном счете JVM, что быстрее Ноды в общем случае, а тем более PHP. Python еще медленее. У тебя есть API, прослойка в виде SSR. На PHP у тебя эта прослойкой будет Нодой. По сути неважно какой стек у них - идея в минимизации количества клиентского JS кода.
@@germanmalinovsky1719 Дело не в абстракциях данных. Просто я ленивый вникать. Для меня Lisp - это как в некоторых человеческих языках предложения строятся. Смысл сказанного превращается в загадку, а порядок слов похож на ребус.
Кложура там еще и на клиент компилится. Кложурескрипт у них. Поэтому, не только на JVM выполняется.
У них и сейчас сайт немного дерганный на телефоне. kasta.ua, там где докладчик СТО. Открываю страницу товара - его показывает, все ок, но мне там на полсекунды почему-то мелькает список категорий или фильтр по каталогу. Он открылся, через полсекунды закрылся. Как глитч. И по интерфейсу там таких глитчей хватает.
Ну его десять лет делают, переписывают с одного на другое. Зато люди заняты, и типа умные. Лисп умеют!
По-моему насчет того, что хаскель привлекает людей с самоконтролем и требует от них этого, а у js - наборот, мягко говоря, неправда.
Думаю, все ровно наоборот, в хаскеле людей контролирует язык, а в js людям приходится контролировать себя самим, чтобы всё не посыпалось :)
33 минуты посмотрел нытья.
В ООП наследование должно быть, есть, и будет!
нету, ООП уже как 10 лет: "НЕ НАСЛЕДУЙТЕ! реализуйте интерфейсы!!!"
капец, в бэме все давно придумали, но нет, мы будет обмазываться говном в погоне неведомо за чем
а причем тут BEM?
@@user-yw9wx4lv2w не могу ответить на вопрос, т.к. не понял, почему с твоей точки зрения он тут не причем
@@KopoLPedov как проблема которая описана в докладе(а именно проблемы с перформансом) решается бемом?
@@user-yw9wx4lv2w ну как, просто пишешь уже на готовом фреймфорке, а не свой пилишь, вот так
@@KopoLPedov о каком конкретном фреймворка идёт речь? BEM это в первую очередь методология нейминга. Фреймворк(и) аля i-bem вообще не получили широкого распространения за пределами Яндекса. А сейчас даже не уверен что активно используется в самом Яндексе.
И я повторю свой вопрос, каким образом bem (что бы вы под этим не имели ввиду) мог бы помочь в данной ситуации?