React заменит BACKEND? WTF?!?!
ฝัง
- เผยแพร่เมื่อ 2 มิ.ย. 2024
- Весенние новинки React.js будоражат программистов по всему миру! Наблюдаем за эволюцией фронтенда!
0:00 Эволюция фронтенда и React.js
02:25 React Server Components
05:03 Зачем вообще нужны?
06:21 Клуб фронтендеров!
06:55 Что за переполох и причем тут Next.js?
07:55 Как выбрать: серверный или клиентский компонент?
8:35 Стримы и Server Actions
9:43 Финал
******************
Книга + вход в фронтендерское комьюнити + дополнительные ролики:
boosty.to/how-to-learn-it
Мой телеграм:
t.me/howToLearnIT
******************
Литература:
1) nextjs.org/docs/getting-start...
2) legacy.reactjs.org/blog/2020/...
3) www.plasmic.app/blog/how-reac...
4) / what-are-server-compon...
5) • React Server Component...
6) habr.com/ru/companies/kts/art...
Спасибо авторам!
#reactjs #react #javascript #frontend
![โอ้มายก๊อด! ไม่ถึงชั่วโมงหมดเป็นแสน 😅 [cc] แดนแพทตี้ SS2 | EP.42 |](http://i.ytimg.com/vi/OH2ShXfO6tA/mqdefault.jpg)
Тренажеры HTML Academy (HTML, CSS, JS, React) + Академия + Книга рецептов фронтендера + комьюнити
за 99 рублей:
boosty.to/how-to-learn-it
Какие тренажеры бывают:
htmlacademy.ru/courses#fe-start
Мой телеграм:
t.me/howToLearnIT
******************
0:00 Эволюция фронтенда и React.js
02:25 React Server Components
05:03 Зачем вообще нужны?
06:21 Клуб фронтендеров!
06:55 Что за переполох и причем тут Next.js?
07:55 Как выбрать: серверный или клиентский компонент?
8:35 Стримы и Server Actions
9:43 Финал
******************
Литература:
1) nextjs.org/docs/getting-started/react-essentials
2) legacy.reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components.html
3) www.plasmic.app/blog/how-react-server-components-work
4) adhithiravi.medium.com/what-are-server-components-and-client-components-in-react-18-and-next-js-13-6f869c0c66b0
5) th-cam.com/video/h7tur48JSaw/w-d-xo.html
6) habr.com/ru/companies/kts/articles/653283/
Спасибо авторам!
#reactjs #react #javascript #frontend
"вам больше не нужно будет писать api" обратился Ден к реакт-разработчикам, 90% которых и так его никогда не пишут.
@Ivan Petrov *джаваскриптизера
теперь не только сайты будут лагать, но и сервера
😅😅😅 И баги прибавятся запрос к бд записывать будет пустую таблицу😅😅😂
Хороший, ёмкий вывод)
@@wildcat4435 ёмкий вывод ошибки error)
@polak и к вечному циклу)
печально что в 70% случаев это скорее всего просто приведет к усложнению кода, и возросшей нагрузке на сервера
это приведет к дополнительным деньгам и только
Почему печаль то? Это значит что зарплаты разработчиков снова вырастут :)
Зато это говно чат gpt не сможет написать
@@alfobarasovich55 стартапам больно станет, программистам то кто-то платит 🤕
ну и бизнесу вобшем
А вам ли есть дело до серверных мощностей как фронтендеру? Есть отдельное ответвление IT, которое занимается всем этим (devops). Клиент с годами становится все жирнее и если часть из этого выкинуть на сервер, то выиграют в первую очередь пользователи.
В большинстве своем бизнес не скупится на серверные мощности, поэтому нет никакой проблемы в нагрузке на сервер
Как мне нравится эти качели в АйТи.
Сделаем сначала инструмент, который все-все-все делает и кофе программисту варит.
Ряяяя - сложно. Потому что слишком много всего надо знать каждому разрабу чтобы с этим вот работать. После определенного этапа - получаем что все протекает куда не нужно, поддержка стоит больше чем добавление новых фич.
Декомпозируем. Пусть будет бекенд и фронтенд и какая-то прослойка между ними, чтобы общаться (не только про веб говорим же, это может быть системная шина, сокеты, всякие реббиты и прочее).
Ряяяя - мы хотим из одного уровня дергать другой, потому что нам не нравятся прослойки и вообще, столько бойлерплейта, столько бойлерплейта...
Опять собираемся в суперсложный инструмент который делает все и кофе программисту варит.
За мои 10 лет опыта - это уже в моем стеке произошло 5 раз. И каждый раз - когда хотят сделать тот самый инструмент, который все-все-все и даже больше умеет, выходит какая-то фигня. Разрабатывать такие приложения после определенного этапа - сложнее. Поддерживать - сложнее(слои протекают, логика смешивается, гроб-кладбище, новые разрабы - просто чтобы приблизительно вникнуть - либо тратят по полгода, либо идут и смотрят самый первый коммит, чтобы понять, что это вообще должно было быть и как шла разработка). Единственное что проще - это на начальных этапах, когда у вас голое поле и 2-3 программиста которые всего чуть по чуть умеют делать.
Так еще и тута, по тому что я вижу - вот прям жесткое протекание уровня доступа к данным в представление. В результате - все равно будет выстроен слой абстракции из которого эти серверные компоненты будут уже дергать че там им отрисовать надо. А потом - возникнет вопрос - а нафига мы тогда мы половину логики представления - держим на беке-то, давайте - во фронт утащим. И качелька качнется обратно. А кому-то это вот придется поддерживать.
Эх. Да. Не читают умных дядек, потому каждый раз по этим граблям ходят.
От кода, где в серверном компоненте идёт обращение к базе аж больно стало. Я не верю что это приживется в проектах даже среднего размера
я думаю, Абрамову с товарищами просто пофиг на чистоту кода, поддерживаемость и т.д., они просто играются с Реактом, не удивлюсь, если они скоро свою операционку на контейнерах под браузерный движок запилят со временем и скажут: "Вот это новый Реакт v38.0, интегрированный с серверами Амазон, чатом ЖПТ и Илоном Маском, ебитесь с ним🤣
ну скорее всего это будет просто как доп. фича, как сейчас SSR. Типо делаешь соло пет проект и нужен фулстек фреймворк - реакт теперь может. В больших приложениях это нафиг не нужно, такую лапшу городить
@@mastnova2676 если нужен фулстек фреймворк - есть внятный ларавель в связке с вью, по практичности и эффективности кода что на беке, что на морде Реакт рядом не лежал. И не будет 🤣
@@mastnova2676 для соло проектов есть гугл файрбейз, где уже все апи есть какие нужены.
И ему подобные.
Для прототипа хватит
Для меня этот сложный переход на хуки обернулся легким переходом на vue3 ))
Вот в меня щас качели, пилить дальше проект на React или уйти в Vue
@@syoritohatsuki когда я решал что учить реакат или вью, волей своей лени я начал с вью, а теперь думаю, а для чего мне реакт вообще может быть нужен. чем вью выигрывает дак это свой простотой и логичностью. по скорости работы проблем нет.
5:50 Какой п***ец. Запросы к БД в React-компоненте O_o. И это должно быть плюсом? React явно движется куда то ни туда.
Порождение уязвимостей
api удобен тем, что позволяет существовать не только фронту, но и телеграм ботам, и приложениям под ios/android
api подзволяет сторонним девелоперам напрямую взаимодействовать с приложением и делать различные расширения и свои приложения на основе этого (вспомните апи гугла и апи бинанса)
так что получается, бэк на фронте запрограммировали для мини аппов, чтобы не на wp или тильде делать и все радуются)))
А по рест ещё фиг его знает в каком виде там эти данные на серваке лежат, пока я на фронте жсончик дергаю
еще хочется добавить что есть работа с очередями, калбэки и запросы к внешним сервисам уже с бэка
не говоря об интеграции с 1с в россии
в nextjs ничего не мешает добавить api route
@@nikirobson3212 Для таких вещей есть swagger, кодогенераторы и typescript, главное только его всегда поддерживать максимально актуальным чтобы на клиенте всегда были актуальные типы из swagger спеки. И да, есть орг вопрос что беки не поддерживают swagger в актуальном состоянии или пишут его не подробно, но это как бы проблема команды, конкретных людей и банально не профессионализм.
@@Segosh Как по мне это лишнее, мы снова возвращаемся к мешанине из серверного и клиентского кода, может fb это и поможет, но на мой взгляд это только усложнит разработку и увеличит кол-во ошибок, а тестировать такое думаю будет отдельным развлечением. И вот эта штука со стримами разметки выглядит максимально криво
PHP и сейчас не умер)) 77.5% бекенда веба на PHP крутится. То что сейчас происходит на фронтенде это переизобретение PHP, уровня версии 4. Но сейчас то уже PHP 8.3 на подходе.
Да, но кому тут это объяснять?) У меня тоже возникал вопрос на протяжении всего видео, а почему бы просто не выбрать PHP в таком случае, где все это уже продуманно и в разы удобнее. Фейсбук подстраивает свою библиотеку под свои особенности разделения труда, всем остальным это незачем, но будут переучиваться. Будут озвучивать как обычно плюсы типа "зато один язык". Но выльется это в такое месиво как обычно, которое небольшие разработчики, следуя современным трендам, сами же не смогут поддерживать. Зато, переделывая потом эти проекты, очень хорошо лечится собственный перфекционизм)
PHP - вечен! У меня работы больше, чем желания ее делать)))
Я из тех, кто пытался убить php. Считал, что писать все на js - это "выгодно". Создав пару проектов на реакте(не без костылей), вернулся к php. Php - это сокращение времени и простота разработки, не говоря уже о запредельной скорости работы(кеш/хуеш и тд.).
Я пхпшник в доску, но и пописываю фронтенд на react/ts. Бэкенд пишу только на PHP, не вижу конкурентов ему. Ни разу не видел оптимизацию бэка на ноде, чтобы использовали что-то большее чем монго/аполло, мульти-процессинг очередей. Весь бэкенд на ноде - "авторизуй меня и дай список статей")
Единственное, советую изучать Swoole/workerman для PHP, разгоняет пыху так, что голанг курит в сторонке)
@@wildcat4435 потому что нам по прежнему нужен клиенсткий код на js. И удобнее когда код на клиенте и на сервере написан на одном языке и на одной технологии. Сам факт того что из серверноо компонента можжно сходить в базу не заставляет вас это делать. Все еще для большенства случаев будет правильно сходить в ваш бекенд.
Next не стент полноценным бекендом. Это скорее близко к тому что сейчас принято называть BFF
Зря с PHP уходил, получается)
Люблю когда фронт лезет в бек со своими js реактами и прочим )) потом по итогу зовут меня и просят переписать бек но уже нормально и задорого ))
ага на томже js..
😅😅😅 Прикольно, не люблю тыкать в чужие коды
@@alexpipin3693 к счастью на C#
Давайте я вам расскажу страшную сказку. Есть великий и ужасный nginx, очень крутой и везде proxy стоящий. Ну так вот, у него есть njs, официальный, православный. И вот на ём можно прям писать логику, в том числе и всякие фечи в умеющие в какой-нибудь http базы. И это прям очень забавно :)
А, а еще есть WASM и WAPI, который собрались прям в куберовские поды заворачивать, и им вообще ничего не надо.
В общем текущая движуха прям очень классная, наконец-то что-то интересное, а то 20 лет жуют одно и то же - скука.
@@user-hn1ph6ry8l и сказка) закончилась ошибкой error 🤗🤭🤣😂
А когда планируется мас-адопшион? Когда это станет мейнстримом для простых работяг с галер и обязательной строчкой для hr'ов? Или есть ещё время подождать, чем дело кончается?
(Действительно, интересно)
Так Laravel с помощью Inertia давно работает с фронтендем(с тем же Reactом) без api и прекрасно делает SPA приложения.
9:15 Вот это уже больно. Раньше максимумум вреда который мог нанести неопытный разраб это куча ненужных ререндеров. А тепреь еще и сервер положить смогу)
И реакт будет рендерить твой проект :), а тут когда хочешь по смотреть сперва погрузиться рекат 🫠🙄потом обновится и тут сервер скажет ку-ку и выводит Hello world 😅😅😎
все уже давно поняли, что монолиты - это плохо, тысячи разработчиков по всему перепиливают пхп на гоу, вкорябывая морду в отдельный слой, попутно раскидывая бекенд на микросервисы и тут Ден Абрамов такой: "Похер, пилим опять монолиты", это ж деградация, господа)) просто пришло откуда не ждали 🤣
Монолит - это не плохо, плохо - это использовать инструмент не по назначению) В частности, плохо подменять декомпозицию микросервисами, плохо преждевеременно оптимизировать, плохо делать распределённый монолит и называть это микросервисами.
@@vryaboshapko К такому подходу обычно приходят со временем и опытом)
Монолит это не плохо, голанг просто невозможно писать, не используя микросервисы. Самое смешное что оптимизация достигается не сменой языка, а просто банальным переписыванием старой-говно архитектуры на нормальную новую)
Тем не менее, по моему, всеравно удобнее юзать некст для фронта (через тот же REST) чем писать в нем и фронт и бэк (запросы в бд и прочее), несмотря на то что некст 13 позволяет писать на нем фуллстек приложение
отличная подача!
а где найти книгу или она еще не готова?
Очень интересно будет когда доведут до ума)))) получается написание серверных компонентов внутри NextJS будет наподобие бэкенда на nodeJS?
а потом скажут - проект вырос и надо сделать апки на native ios/android и кто-то начнет себе волосы на жопе рвать)
Лайк за солидарность!❤
Давай, давай, вообще красавчик, можно побольше вот это вот всё! Лукас с двух рук!
Ты по-моему перепутал
@@Unknown-vg9um хахахахахахахахаха
@@Unknown-vg9um сюда тоже подходит
да хватит уже доказывать свой дебилизм, хоспаде
А если надо добавить второй фронтэнд (например, мобильный), ничего при этом не меняя на бэке, как это должно работать?
Ответ будет в следующем ролике)
Возврат во времена cgi-bin и перл print ""
Досмотрел до таймера в 200 мсек и взоржал.
от постфиксов в названии файлов отказались в сторону директивы "use client" в принципе, не только в nextjs
нужно ли заворачивать компоненты сторонних библиотек в директиву зависит чисто от этих сторонних библиотек. Некоторые уже добавили себе "use client"
Я уже не раз говорил и в видео и на стримах, что мы двигаемся в эпоху serverных приложений. Дока реакта тому доказательство и описанные методы для сервера в ней. Не знаю на сколько будет архитектурно правильно писать полноценную логику бекенда в наших приложениях, но знаю точно что это следующий шаг эволюции наших приложений. Мы прошли с вами полный цикл, но вместо php будет nodejs, а после уже его заменит куда более крутые серверные языки, по типу rust и вот мы снова тут. Но разница колоссальна с тем временем. Next 13 это отдельный вид искусства, конечно есть коммерческие вопросы, но все же.
Отмечу, что многие до сих пор не понимают концепцию ssr и тут еще новая и крутая концепция. Нужен точно контент на тему, что такое сервер и как на нем работает наш код и как это попадёт в браузер.
Спасибо за видео 👾
Кстати да я вот вчера начал читать документацию Next JS там я обнаружил серверные и клиентские компоненты.
P.S. Подписан на вас давно очень крутой контент. Продолжайте в том же духе
Лол пхп вообще про другое. Ты путаешь теплое с мягким
@@user-tu9qb1ur4r Я сам недавно был в шоке от stable версии nextjs, они очень быстро развиваются посмотрим куда нас это приведет, надеюсь реакт сделает свой гайд по ssr и серверным компонентам в доке
@You Tube это зверь, на которого нам вскоре придется охотиться я думаю 😎
@@yaroslavmakarov2218 лол ты
Это какой сервер нужен, чтобы каждому клиенту каждые 200мс пулять данные?
😂😂😂🙄🫠Это будут пулять разработчики чтоб поймать error😅😅😅🎉
А как быть с приватностью? Если мидлвайры и бэк функции доступны во фронте и их можно легко вытащить?
Да это ридумали для каких то задач и гиков, 10 прослоек которые только им понятны. В итоге такую ерунду смогут обслуживать только команды. А надо просто делать html css, странички для клиентов с js и php :)
Так а чем это отличается от ssr в next?
кажется, лет 20 назад я где-то такое видел. вспомнил, в пхп!
Привет, Друг 🤝
Да, я ещё помню Backbone 😂
Ну там же и было тяжко и непонятно.
Зато название крутое
интересная концепция, жаль что это убьет удобство разработки клиента и сервера
особенно часть где можно явно с клиента кидать запросы в базу меня рассмешило, бекендер который потом будет пытаться ловить ошибки вам точно ничего хорошего не скажет_)
Nuxt 3 можно использовать как фронт и сервер. В корне создаём папку server и внутри файлы работают с сервером. Так же к этим файлам можно обратиться с других клиентов и работать через API.
ну и зоопарк
Развивается фронт, в чем проблема ?:)
@@ebadmaev Проблема в том ,что это называется и рыбку съесть и на *Уй сесть .
@@ebadmaev развивается бардак (под соусом вкусным). Знаете почему js единственный в своём роде? Потому что все (умные люди, которые разрабатывают языки/компиляторы и прочее) поняли как делать не надо и подобных технологий больше не будет, а бизнес индустрия в сфере it просто тащит эту кекешку (в силу отсутствия некоего количества мозгов), вот она и живёт. Пока что. Есть некоторые варианты эту технологию (я про js в целом) сделать допустимой, но очень много нюансов и все предусмотреть крайне сложно.
Всегда ржу с jsдрочеров: "каеф, классно, убобна, красиво, ря ща запилим фронтендик с анимашками и аджаксиками и все будет летать, там фичи в реакте еще подъехали, ща еще фронт на бэке запилим", кхм, но есть некоторые проблемы с правами конечного пользователя, на которые кладут болт жирный все эти jsдрочеры в силу своей некомпетентности об ответственности перед этими самыми конечными пользователями, им ведь ни кто ничего не сделает (опять же, они этого даже не понимают), но это тоже, лишь пока.
А зоопарк это, потому что снова какая-то хрень выкатилась и jsдрочеры поехали впаривать снова какую-то хрень всем вокруг и дальше тащить это в массы. Что там зоопарк, у фреймворкоделателей (костыль на костыле, код на коде, не летает, ну ща, все потоки и процессы сожрем прост), что в сообществе jsдрочерства.
@@somethingname9038 в итоге, в сухом остатке, благодаря развитию мы и получим парадигму стиля кода во фронте, который будет соответствовать потребностям рынка :) возможно через 5 лет, коренным образом изменится сам пользовательский опыт поиска информации в интернете) надеюсь, понимаете к чему клоню :)
@@ebadmaev к сожалению, не понял вас :(
Но я надеюсь что через 5 лет, а лучше - раньше, js будет отключён в браузерах по умолчанию или вообще его средства исполнения искорены и будет другая технология. Будут северные средства, будут по чётким и обозначеным правилам разработаны новые, вспомогательные средства фронта без всякого месива вроде js, которые не будут нарушать правила исполнения (не будут запускать что хотят без предварительного согласия и осведомления пользователя его же ресурсами)
Не ясно какую проблему решают своими подходами? Пока что выглядит как улюлюканьем оверхайп
пуляем на сервер через 200 мс? а это не будет расценено как DDOS атака?
😂😂😅SQL инъекции будут
Не совсем понял, а если бэк написан на другом языке?
Я только не понял, как работают северные компоненты, если после балда проекта ты болучаешь исходник, который будет загружать только клиент
Хм, я так понимаю это скорее стандартизированная абстракция которая просто автоматизирует и оптимизирует работу по API для React. Выглядит любопытно, но очень сыро, в особенности мне нравятся как разрабы на возникшие проблемы буквально предлагают костыли. Даже чтобы древо модулей построить, нужно костылять. Ну и SOLID, так понимаю фронт-ендеры послали давно куда подальше.)
Интересный подход
И реакт после этого остается библиотекой???
Вхахвх
Отличные фичи для небольшого проекта, где приходится писать простой api, который просто геттит и сеттит данные. Для больших проектов один React конечно не подойдет, нужен будет React backend + backend backend, который в свою очередь уже будет реализовывать сложную бизнес логику. И здесь уже можно использовать разные интерфейсы взаимодействия между двумя бэками - без устоявшегося http, что ускорит производительность. В общем, серверные компоненты - отличная идея
Я недавно протестил Svelte, как глоток свежего воздуха после реакта. Даже встроенный SSR есть
Открытие! В следующей 14-й версии Nextjs бэкэнд будет полностью отделен от фронтенда и наступит всемирное счастье )) Т.к. фронтенд станет намного проще.
Ну а в 13-й версии все будет в одной куче - как в пхп когдато было ))
Пробовал сделать небольшое приложение, не понятно пока что как взаимодействовать с редаксом в серверных приложениях. Еще тестировал с mui, где серверная страница возрващает стилизованную таблицу, но mui не может работать на сервере, хотя логики и интерактивности нет. Вообщем пока странная обнова, не ясно большой ли импакт от решения серверных компонентов.
Про редакс надо забыть в таком случае. Это уже не спа, тебе не надо хранить состояние в памяти, ты его запрашиваешь на каждой странице/после каждого экшена. Муи может рендерится на сервере, но его стили нужно кэшировать так как он использует сss in js. (Возможно в серверных компонентах ещё не докрутили, но при обычном ssr в Remix у меня всё работало)
@@izzy7541 а если я делаю запрос в каком-то большом компоненте и мне его пропсы нужны во фрейме этого компонента на 5 уровней вниз? Мне через 5 фреймов его прокидывать и тригеррить ререндер на всём протяжении этого самого пути?) Я не докапываюсь, просто эта тема для меня незнакома, решил задать вопрос)
@@bizkiqz6337 контекст, декомпозиция. Это явно лучше чем тащить на сервер условный релакс, а потом на клиенте гидрировать.
Прикольно будет рассказывать вашим пользователем что у вас сайт грузится долго потому что фронты не смогли нормально компоненты организовать или им пропсы не удобно прокидывать. Смех же :)
Шок контент! Без смс и регистрации!
ПС: Разработчики будут писать на том, что удобно и легко поддерживать.
И вот удивительно, но как раз разделение функционала на клиент и сервер это позволяет делать!
Вроде бы Google уже пытались сделать что-то подобное, забыл как оно называлось... собственно почти все это забыли, что как бы намекает на успешность данного начинания 😅
Ну это же маньяки с шилом в заднице. Давайте придумаем квадратное колесо и потом каждый его подпилит где надо.
Мама я в телевизоре! egoidnet)
Интересно, как это будет стыковаться с fsd
Офигенно качественный контент! Контент других похожих ютуберов которые постоянно светятся в рекомендациях и рядом не стоит с твоим (ДЖАВАСКРИПТИЗЕРЫ | КИРИЛЛ ПОЗДНЯКОВ, purple group, red group)
Через пару лет скажут - не ребята, мы приложения написали, конечно, но они не поддерживаемые, давайте лучше вернёмся к классическим вебсайтам без SPA 😂
я вот смотрю на дерево на 3:40, это что начинается эра 1С в реакте? процедуры сервера клиента туда сюда вызов бурум пуумпум
Почему реакт годится только для маленьких приложений с галочкой, в корне не согласен. Я видел довольно неплохо написанный энтерпрайз на реакте
Так не было утверждения, что он годится только для маленьких приложений, 2:05 было утверждение, что его чаще всего используют для маленьких приложений. Полагаю, это связано со структурой рынка (маленьких приложений больше, чем больших), а не с применимостью фреймворка.
Это Facebook 😎😎😎😈?,😂😂
Ну короче бэкенд из под коробки, в концепции ничто не мешает написать к этому всему обёртку для api, если таков необходим
где найти кодекс фронта ?
Сразу почему то nodeJs вспомнился) где кстати он сейчас...
Прикольно прикольно, но интересно, насколько "толстые" сервера в итоге получатся и насколько все это дело будет нагружать всю инфраструктуру)
просто будет работать так что теперь клиент ниделает запросы вообще, все делает сервер, а клиенту прилетает типа обьект и клиент просто его вставляет как обычно он и сейчас делает. просто нибольшая часть нагрузки уходит. Но если людям нужно СПА им как бы и некстжс не нужен для этого
Ща с бы снимать "очередной" курс по фронтенд технологиям для котиков за шекели
Webforms возвращаются?
И ради чего эти усложнения? Просто уменьшить размер бандла?
А в чем революция?) И 15 лет назад на сервере страничка рендерились шаблонизатором, затем "гидрируясь" с помощью JQuery/KnockoutJS/etc. Разве что модельку нужно будет запросить у соседнего приложения ("бэкенда"), скорее всего, по тому же rest-каналу.
А кто хотел писать веб-приложения полностью на JS/TS, тот уже давно это делал и так с NodeJS.
бекендеры на C#, Java сейчас напряглись 😅
P.S А как такой серверный BE компонент справляется с очень высокой нагрузкой если JS \ Noda работает на одном ядре?
Или там используются какие нибудь ВебВоркеры под капотом?
Я как бэкендер на Java вообще ни грамма не напрягся) Хочу увидеть эти реакт сервер компоненты вживую 😅
это типа wrapper компоненты?
Фронтом особо не занимался, по большей части бэк. Но вижу я какое то месиво вместо структурированного когда.
Что-то мне эта "новая" фича напоминает, много лет назад где-то я такое видел, писался код, который мог выполняться по разному, в зависимости от места выполнения - в UI или на сервере....
nextjs
Meteor?
В php фреймворке Livewire реализован фуллстек.
В некст в документацию повезли ещё экспериментальную фичу, возможность в клиентскую компоненту сразу добавить серверную функцию!!!!
А, в видео есть про сервер экшонс)
Давным давно выбрал Vue и не пожалел. После переезда на Vue 3 вообще не понимаю для чего нужен React.
я чувствую тоже перееду на Vue, т.к react мало того, что больше движений руками, так еще и теперь мне работодатель скажет "зачем нам бэкендеры, у вас же там реакт умеет в БЭК"
а разве не новая дока у реакта уже месец как вроде??
Как это нарушает принципы REST API и Микросервисов ?
о, скоро стану фулстеком видимо
я так понял что я зря первым фреймворком выбрал vue
А в какой момент и зачем "Бизнес-логика" уезжала на фронт?
Мне интересно, сам Абрамов пробовал писать приложения на своем реакте?
Ему некогда, он всякую херню выдумывает "мертворожденную"
Не уверен, что это подойдёт для больших коммерческих проектов. Всё-таки разделение на frontend и backend произошло не просто так, чтобы потом обратно схлапываться в такое.
такой же мысли придерживаюсь
Честно говоря выглядит как полная фигня.
Я не суперпрофи в программировании, но при работе над своими пет-проектами плавно перешёл к идее о том, что разбивать проект на логические части - это хорошо.
То есть у вас есть чисто фронтенд. У вас есть чисто бекенд. У вас есть ещё какой-нибудь вспомогательный модуль, который, к примеру, парсит данные откуда-то, либо выполняет какие-то ресурсозатратные задачи, получаемые от бекенда. И всё это крутится, например, в собственных докерконтейнерах, которые можно поднять в любое время на любой другой машине с минимум затрат по времени.
А что тут? Всё в одну кучу. Вы правда думаете, что разработчики всегда будут стремиться не смешивать одно с другим? "Технический долг" не просто так существует. Рано или поздно это будет из разряда "да давай сюда забубеним, потом поправим". Ага, конечно. Через пару месяцев там на это "поправим" столько функционала нарастёт, что в жизни потом не поправите никогда.
Слава богу, что в своё время я не повёлся на хайп и начал грызть ангуляр. Там такого дерьма нет.
На JS не писал, всегда бэк делал. Вот я не понимаю как они будут масштабироваться, как будут распределять бизнес логику по кластеру.
@@ningtanagrey9141 технически это вполне можно реализовать. Но практически, человек - это такая скотина, которая от собственной лени рано или поздно сделает так, что слои начнут друг в друга протекать) Это просто неизбежно, насколько бы квалифицированным специалист не был. И чем серьёзнее проект, тем больше вероятности того, что такое произойдёт
Вообще вся эта хрень хорошо работает с микросервисами, самый внешний сервис это по сути всегда фронтэнд+апи гейтвей, и вот такими вот техниками можно было бы объединить это в единое приложение, вместо того чтобы иметь 2 разных. Так же убрать гейтвей, так как запросы к микросервисам будут идти от сервера напрямую, и их уже не надо роутить по микросервисам. Ну и не будет проблем с тем чтобы доверить это фронтэндерам, так как по сути они будут заниматься тем же чем и всегда - посылать запросы бэку.
В этом случае так же нет проблем с тем что нагрузка с клиентских машин переходит на сервер, так как этот сервер по сути только этим и занимается и не влияет на производительность остального бэкэнда.
@@zkksch при объединении фронтенда и бекэнда одно в другое начнёт протекать рано или поздно.
К тому же усложняется поддержка всего этого дела: раньше у вас фронтендеры и бекендеры отвечали за разные направления, теперь же они слишком плотно друг к другу прижаты. Может получиться так, что из-за протечек фронтендер полезет на территорию бека и наоборот. С учётом того, насколько низкокачественный код пишут фронтендщики в основной массе своей (когда задал вопрос про DI в реакте, надомной посмеялись, типо зачем?), я сомневаюсь, что такой проект не превратится в гуано.
Помимо этого, микросервисы позволяют себя достаточно просто маштабировать в случае чего.
Очень интересно, но ничего не понятно. Мне бы обратно бейсик с паскалем, где всё ясно было )))
Чет сижу и не могу перестать улыбаться. В свое время начинал работу в IT лет 10 назад когда был моден SSR. Потом все решили что это говно и JS достаточно развился чтобы писать на нем более-менее сложную логику и все говорили что это новый виток в эволюции IT. Что SSR имеет кучу недостаков и лучше когда разные команды, с разными навыками занимаются разными вещами не мешая друг другу. Что это позволит фронту и бэку выбирать языки и технологии более подходящие их требованиям и еще куча аргументов. Появились сложные UI фреймворки и вот, вершина развития всего этого... тадам! SSR! Просто великолепно, я считаю! Надо будет показать этот видос следующему человеку который будет мне говорить что в IT тяжело потому что постоянно что-то новое появляется. А тут по факту каждые 10 лет переизобретают уже существующее в новой обертке и с другим DSL
просто у вас немного не правильный взгляд на это. Фронт так и так был завязан на JS, но вся экостистема была не сильно развита. JS на сервере был вообще в диковинку. Фреймворки для SPA дали сильный толчок к разтивию всей экоситсемы и самого JS. К тому же на них просто ПРОЩЕ писать фронт. И когда набралась критическая масса решений, эти SPA фреймворки стали развивать и серверую часть.
Я бы сказал так, что в целом идея что на клиенте и на сервере нужен один язык и одно решние, давно было в умах. Но все попытки решить это заходя со стороны бека - провалились. Тут же наоборот - зашли со стороны фронта. Сначала +/- удачное решение для фронта и уже его мы пытаемся затащить на бек
@@user-yw9wx4lv2w могу предположить что результат будет тем же самым. По той же причине - бэкендерам нравятся языки, которые лучше подходят под их задачи, как раньше фронтэндеры хотели использовать js и не зависеть от Бэка в выборе технологии. Время покажет, конечно. Но бэк - это другие компетенции с другими фреймворками, подходами и архитектурой. Зачем завязывать все это на фронт, особенно когда уже почти во всех конторах где я работал большая часть трафика приходила из мобилок? Хотя если это ФБ, то у них сильна лига фронтендеров. Они и мобильные приложения пытались на js писать в свое время. Теперь вот, до Бэка добрались.
Про эффект, который вы упоминаете, в разработке ПО известно уже лет тридцать, наверное. У нас с 80-х годов ничего принципиально нового не было изобретено. Каждые n лет ньюфаги просто переизобретают что-то, что было известно ещё в 60-е, например. Например, вся движуха с Reactive Extensions (~2015 год) это буквально паттерн Наблюдатель, из книги банды четырёх 94 года.
как бы это не тот старый SSR который сбрасывает табуляцию, или инпуты или другой стейт. При таком подходе стейт сохраняется.
@@LHLetale да и раньше так можно было сделать. Понятно что подходы эволюционируют. Но я бы изучил почему все отказались от ssr в прошлом. И это не проблемы с состоянием на клиенте.
монтаж класс
Профит в том, что мы перекладываем тяжесть на сервер, чтоб на клиент лёгкий бандл прилетал - звучит с одной стороны красиво, но!!! Сервер условно ОДИН, клиентов миллион, получается сервер будет рендерить серверные компоненты для миллионов клиентов. Получается мы только хуже сделаем?) Всю нагрузку на один сервер, когда можно было распределить её на миллион клиентов
Пока поставил на паузу видео, то бишь пока не досмотрел, но уже хочется сказануть, поэтому мб дальше в видео есть шанс, что тоже могут сказать об этом
Сервер один раз срендерил и отдает клиенту кэш при запросе
Бекендное ремесло хорошо умеет справляться с горизонтальным масштабированием, чтобы тянуть растущую нагрузку. За одним URL-ом могут стоять сотни физических серверов, плюс их количество и качество можно менять незаметно для клиентов. Вычислительные ресурсы клиента при этом сильно ограничены, нельзя просто взять и пересадить всех на более мощные ноутбуки и смарфтоны. Плюс сервер питается от розетки, а клиентское устройство часто от батарейки. То есть, перенос вычислений на бекенд не является проблемой.
@@vryaboshapko если смотреть со стороны бизнеса то похер на старпера с древним смартфоном, если из-за него время отклика всех запросов увеличится и да, ты не можешь вечно горизонтально масштабироваться, если ты не гугл
@@semensemenov9519 Во-первых, смотря какой бизнес. Кому-то достаточно десятка клиентов, готовых много платить. Кому-то нужен миллион неплатёжеспособных, но смотрящих рекламу, а кто-то живёт за счёт десятка «синих китов», но всё равно держит миллион бесплатных пользователей ради продвижения. Плюс десятки промежуточных вариантов, когда есть разные тарифы на разный кошелёк.
Во-вторых, хочу напомнить, что мы говорим о всего лишь предварительный генерации разметки, даже не картинки. Сгенерировать сотню килобайт JSON-а - это мизерная нагрузка для современного северного железа. Даже на node.js это потребует в разы меньше времени, чем установить TLS соединение с сервером. Так что бесконечное горизонтальное масштабирование из-за северного рендеринга - это не очень реалистично.
вернулись в PHP короче. Причём, PHP всё ещё проще и быстрее ;)
Звучит как какой-то гемор.
Сейчас. Есть комплнент, в юз эффекте запрос за датой, она кладется в стейт и отрисовываем. Все понятно..
А как хотят?
Есть некий серверный компонент, в нем логика сервера написана? Подключение к бд тоже? И выдача того что нам надо? Ок, получили, далее мы типа обернули серверным компонентом клиентский и пропсами прокинули данные? Полнейшая шляпа, просто пипец.
1:05 появились фронтендеры)))))) Ахахаха
Они переизобрели Blazor. Но в целом круто. Часто в задаче оптимизации дозагрузки данных в всякие списки (вечный скролл, пагинация) очень помогает ускорить все - это загрузка не обычного JSON, а готовой HTML разметки с SSR + JSON стейт компонентов. Тут по сути это будет из коробки. Если они еще научатся присылать в ручке стейт не в JSON а в протобафе, то вообще пушка будет.
а как реакт нейтив с такой штукой дружит?
Никак. Next это над вебовским реактом обертка, у реакт нейтива приблизительно похожую роль берет на себя expo. Но там даже близко ничего похожего нет и никогда появится - мобильные приложения устроены принципиально иначе. Весь бандл уже лежит на устройстве, не хватает только данных, которые можно запросить у бэкенда привычными fetch или axios без вот этих танцев с бубном
Поздравляю фронтендеров! Цукерберг и ко. придумали 1С с его &НаКлиенте, &НаСервере, &НаСервереБезКонтекста и тд.
1С-ники уже давно кодят на клиенте, на сервере, на сервере без контекста и на сервере и на клиенте. Тоже мне вселённую открыли.
Типа, как в 1С?
это конечно классно, но оно так не работает. api сервера писать всё равно нужно будет как минимум по 3 причинам: разработка разными командами; возможность иметь несколько клиентов (desktop, ios); простота клиентов - если писать общение с БД в next.js приложении со всей логикой клиентского кода, то получится большая каша даже для небольших приложений, т.е. увеличит порог входа в приложение и создает сложности в поддержке. ну, и конечно масштабирование не такое гибкое получается
Новый подход некста очень хорош. За два месяца переписал коммерческий проект с чистого реакта на новый некст. По метрикам производительность выросла в разы, а так же само разделение на серверные и клиентские компоненты мне показалось очень удобным
Кстати дай пожалуйста направление куда двигаться. Я хочу научиться определять производительность приложения. Какие инструменты?
@@user-tu9qb1ur4r лайтхаус и профайлер в девтулзах наше все. 99% потребностей в этом закрывает. Есть для реакта и некста еще либы, которые измеряют бандл твоего приложения в удобном формате. Этого всего с головой хватит. Также советую по копать про оптимизацию изображений и шрифтов. Мемоизацию, оптимизация лишних ререндеров, ленивая подгрузка компонентов и так далее
@@Ex3meTV спасибо бро
Не возникло проблемы с контекстами? Я недавно для проекта использовал директорию /app некста, но все легло, когда добавил провайдер для темы styled-components
@@Nixon671games я в отдельный компонент клиентский вынес все провайдеры и уже из главного лэйаута чилдрен прикидывал через него. Для sc еще нужен кастомный документ для подгрузки стилей на стороне сервера. Как в директории app это сейчас делается уже не подскажу
IMHO путь свелт правильнее. А web -api часто требуется на только фронтенду.
подключите firebase и делов то =D
Я не понял, это 1С?
90% того, что делает Дэн Абрамов - жуткий оверинжиниринг, который потом годами устраняется и переделывается. Я может не очень пока разобрался, но невозможность разрабатывать фронт без привязки к бэкенду, используя только апи, мне вообще не нравится. Что плохого в API и почему вообще от него нужно избавляться? С ним чётко видны потоки данных, что упрощает отладку и изолирует разные части приложения. И вообще это всё уже было в Rails когда HTML бэкендом создавался. Жуткое дело. Кстати, жду, когда придёт осознание, что хуки - жуткое г..
оке, пойду я дальше со своим накстом, потом посмотрю что из этого у реактеров выйдет ))
ещё на некст жиэс можно в бэк, так что калавая ревалюция
Вот вроде все устаканилось и целых два года во фронтенде ничего особо не менялось, все аж обрадовались что наконец-то теперь мы поняли что такое фронтенд и теперь-то заживем. Навозная кучка покрылась коркой и перестала вонять. Но нет, пришел ебаный Версель и начал опять все переворачивать. И опять у нас каждый месяц новая революция, куча фреймворков и библиотек. Я в этом деле новичок, и мне страшно читать подобные новости. Я еще хуки не все выучил, откуда мне время взять все это новое понять?
next уже давно в проде юзают так то, и по дефолту его не связывают с бэком, а используют просто как еще 1 микросервис, так что заявление громкое и с опозданием на несколько лет как минимум, а новые фичи всегда хорошо, мб работать все быстрее начнет
Ток не постфикс, а префикс. Оно ж впереди стоит
А вот в свелт ките уже 300 лет так
Реакт подсмотрел клиент/серверные компоненты у 1С?))