Поддержи видео лайком, 1000 лайков 👍 и я следующее видео полный курс по Next.js! 🔐 МК "Реализация оплаты от А до Я" - t.me/pay_red_mk_3_bot Подробнее о мастер классе - t.me/redgroupchannel/1533 🔥 Оформить премиум подписку - htmllessons.ru/premium
@@a1wa7tv пока тут из не актуального только next js))). фигачить проектики, которых никогда не увидит прод - это, конечно, здорово - но вот в поддержке все это дело весьма трудоемкое - и осложняется тем, что с каждой версией - это чудо все "лучше" и "лучше" - за ним не успевают целые команды фронтендеров. Ангулар другая история - он стабилен, он не лезет куда ему не надо лезть (сравните как там реализован ssr), прогнозируемая работа в проде - красота. так что все верно написано. @REDGroup Макс, давай видосы про ангулар - там next и рядом не стоял))))
Основная проблема как мне кажется заключается в том, что происходит путаница из за того что является сервером а что клиентом. Особенно это видно на формах. Например в том же Nuxt такой проблемы нет, там есть четкое деление где сервер а где клиент.
Работаю с nextjs примерно год, долго не мог понять почему они переносят всё на сервер. Вывод один - это будет приносить им больше денег, так как они продают продукт через vercel. Но вот в защиту скажу, что серверный компонент можно делать в клиентском, если вынести его в другой файл в функцию с 'use server' , что впринципе очень удобно и не вредит безопасности, в то время когда можно использовать все хуки на фронте. Кстати базу использую supabase, с ssr аунтификацией юзеров, не могу сказать что это прямо плохо. Наоборот, очень удобно.
Вы абсолютно правы, именно эти плюсы я выделил в видео. Но есть вещи которые крайне напрягают в разработке больших проектов, если ты не используешь vercel
Макс ты лучший. Уже эта мысль меня преследует как пол года. Сейчас перешел частично на Astro и Angular 17 Выбираю между этими вариантами в зависимости от проекта
Полностью поддерживаю. Ещё заметил, что помимо того, что они используют все в перемешку (на Западе), так ещё используют платные облачные платформы в своих проектах, а не пишут нативный бэк
Сколько раз пытался использовать React c пришитым Next так и не понял зачем мне оно надо если я пишу свой быстрый бек на Rust Tokio. Как будто мне намеренно навязывают делать часть бекенда в Nodejs
Как по мне все правильно двигается, большинству бизнесов не нужны сложные фронты и отдельные бэкенды. Некст к этому двигается чтобы проще было делать проекты для бизнеса, а самое главное быстрее
Я бэк, но посмотрел с удовольствием. Я много слышу о том, что бекендовые языки программирования не нужны с развитием фронта в сторону бэка, но я не понимаю зачем. Один человек все равно не потянет даже средний проект, либо потянет но привет перегорание. Возможно просто эмоции, так как это попытка отобрать у меня хлеб, а может действительно это функция просто для галочки, чтобы можно было говорить: наш фреймворк настолько крут, что бекенд уже не нужен, и на этом смысл заканчивается.
Я тот самый человек, который умеет хорошо и в бэк (PHP) и во фронт (React). Причем одновременно и уже в нескольких проектах, так что опыт говняния и исправления наговнянного имеется =). Наслушался про Next.js и решил его попробовать на новом небольшом проекте, с ненапряжными сроками. Больше я не буду это никогда использовать. Next.js создает проблем больше, чем решает. И, кстати, я не обнаружил никаких проблем с SEO, используя чистый React + React Router + Helmet, кроме объемного JS бандла при первой загрузке (решаемо, кстати). Есть и хорошее, конечно, но, в целом, можно и без этих удобств как-то обойтись или заменить. Реализация middleware в next.js - это вообще дичь какая-то, особенно после Laravel. Пришлось писать свою реализацию, похожую на Laravel, чтобы совместить несколько разных middleware и раскидать их по разным путям. Работа с cookies тоже имеет проблемы, особенно через cookies(), которые на отрабатывают изменение значений в некоторых ситуациях. Что касается бэка на js, то я интегрировался с таким вот js backend и это прямо боль какая-то. Там нормально не реализовано ничего - ни авторизация, ни очереди, ни производительность (кидаешь 10-15 объемных запросов в секунду, и оно виснет наглухо). Понимаю, что от кривости рук зависит, но зачем изобретать еще один велосипед (js backend) при наличии вполне себе исправного существующего (PHP + Laravel/Symfony), на котором уже реализовано практически всё что требуется? Go - неплохая попытка заменить "медленный" PHP, но что-то как-то не взлетело, если судить по тому какой огромный дефицит кадров, умеющих в Go и нытью HRов, что на рынке практически нет гошников, а зарплаты они просят как 2-3 PHPшника. Ну и там, говорят, довольно мало готовых решений, нужно много самостоятельно делать, а это время. Тем более go уже не имеет такого значительного отрыва по производительности от PHP как раньше. И что остается в итоге? Java/Kotlin и C# для enterprise и PHP для остального. JS/TS - не дает никакого преимущества относительно PHP, но добавляет много проблем, которые давно уже решены в PHP. Про отлов и понятность ошибок в JS - отдельная тема и боль. Так что - выдыхаем, PHP живее всех живых и еще долго не помрёт, как и чистый React.
Лично я предпочитаю разделять разработку Frontend и Backend. Для чистого Frontend я использую Next.js, а для Backend - Express или Nest.js. 😉 Считаю, что сочетание Frontend и Backend в рамках одного Next.js приложения может привести к неэффективной работе. Поскольку я чаще обновляю Backend, чем Frontend, раздельная структура позволяет мне избежать необходимости пересборки и обновления Frontend при изменениях только в Backend. 🚀
Так весь серверный функционал - это функционал react 19, а не некст. Он просто оболочка, которая поверх предоставляет пару новых функций. Тут предъява должна быть react, а не next.js. Серверная часть (на котором и происходят действия все сервера) буквально и позволяет оптимизировать приложение, благодаря кэшированию. Вместо того, что бы делать миллион запросов к бд, как это раньше делал react, мы делаем один запрос на стороне сервера-frontend и отдаем всем пользователям кэшированную версию. А еще хотят добавить ppr, но он пока экспериментальный (на уровне сборки компиляция страниц)
@@REDGroup Весь backend-функционал стоит рассматривать исключительно как возможность для маленьких проектов. Понятно, что в любом случае всегда будет отдельно бэк и фронт на больших проектах, но для маленьких - это отличный вариант. Зачем говорить о next.js, если form (server) actions - это функционал react, поэтому и говорить нужно о нем.
@@Aleksey-n5h согласен, возможность написать back вместе с фронтом в маленьком проекте - отличная и доступная возможность для независимых фронт-разработчиков без глубоких знаний бэкенда
React на классах было лучшее, нормальное понятное ооп, что и когда рендерится, полный контроль. Потом зачем то эффекты и прочее начали нести... Главная проблема nextjs это постоянный ад зависимостей, не самая быстрая сборка, и не очень понятно как строить микрофронты с ним, а если докинем сверху еще nx, pnpm - то понять где, что отлетело после очередного обновления либ - просто ад А фронт откатился до php в перемешку с js/css вставками)
да пошло оно все,буду использовать в будущем only solidJs/пофигу что мало либ и решений буду свое писать если надо,ьстро летает почти как ванилька,синтаксис jsx,а то все боятся что нету комюнит и либ и все в етом духе,ну и что,eсли бы создатель с либо с++ так думали то бы и языка не создали.
Этого тербует рынок, необходимо смотреть на текущие изменения сковзь призму денег. Железо дешовое, программист дорогой (это про запад, в особенности про зарплаты за океаном), отсюда и такие решения. Наклепали MVB, показали заказчику, чуть допилили, автотестами погоняли и в продашн. Если проект взлетел, будут еще деньги, разделят бэк и фронт. Если не взлетит, то какая разница prisma в api или на отдельном сервере.
@@REDGroup дружище, ты же сам выложил видео про альтернативы, а то что он лидер, с этим не поспорю. Просто суть в том что рекламировать курс, в котором преподается некст в видео, где ты критикуешь некст - не очень удачная попытка. А так само видео в целом - 👍
Начал пользоваться Next-ом. На первый взгляд вообще не гибкий. Например, как новичок, не представляю как кнопку по которому модалка должна закрываться и кнопку по которому идет серверный запрос держать в одном форме. При этом кнопки должные быть на одной линии под инпутом. Да, это можно сделать гридом, но все равно странно. Одна кнопка на client, другая на server компоненте.
Писал на реакте и экспрессе. Недавно попробовал некст по западному гайду и получил плохой экспириенс. Полностью согласен что запихивать призму дб и другое во фронтенд это плохо.
Мне нравится, использую server actions , что бы на сервере получить доступ к grpc java серверу и отправить клиенту уже готовые данные без описания rest api
Почему нет места такой реализации? Существовали же в начале двухтысячных приложения, которые жаловали SSR. Вопрос того, какой инструмент использовать -- это да...
Макс, я не могу с тобой не согласится, но это смотря для какого проекта мы создаем решение и насколько быстро оно требуется. Рано или поздно все в любом случае будет сходить на клиент-сервер, но в данный момент может требоваться "качественный" монолит, который можно впоследствии будет разбить по обязанностям (отрисовка, контроль bm и тд). Next.js данную потребность закрывают на сегодняшний день. Это обойдется гораздо дешевле заказчику, нежели набрать несколько команд и платить им.
Мне нравится новый Next, но я каждый раз в ужасе когда нужно передать данные в новый роут.Я до сих пор не понимаю как можно в query передать огромные обьекты и вообще открыто показать какую дату в UI используется при этом пользователь может свободно играть с этими query. Недавно видел как в url был query apiKey а там был показан private кей какого то сервиса 😂
С 9-ой версии начал использовать Next, очень понравился после Gatsby для фронта. Однако с 13 версии, когда выкатили app router, стало какое-то странное послевкусие и правильно ты сказал, что движется сей поезд с названием Next, не туда. Сейчас уже чуть больше года ушел на Astro и думаю, что так должен был бы выглядеть Next.js, только со своими фичами.
Честно не сильно хочется, очень противоречивая тема и много срача в комментариях. Это так крик души и чтобы канал не простаивал, пока я разрабатываю dark side
Посмотри 1С Элемент, там вообще сделали веб версию 1С, можно накидать фулстек приложение за день ничего не зная про вёрстку, вебпак, ssr и остальные кишки веба. Правда интерфейс контролов убогонький. Если дадут применять стили то будет убийца всех реактов и ангуляров
Недюсь они не будут пропагандировать что типо он не юзайте вообще отдельный бэкэнд типо что можно все в Некст, а будут просто типо фокус на фронтенде и максимально облегчить фронтенд с помощью серверных штук там. Понятно что бэкэнд отдельно должен быть в этом миллион плюсов
Макс, вам нужно обратиться к разработчикам Next,js и поделится своими соображениями, 😉😉 а то, похоже, им нехватает квалификации и понимания современных трендов разработки и делают они что-то не то 🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣
Полностью согласен. Пусть фронт остается фронтом, а бэк бэком. Мне не трудно один таск сделать на фронте, закоммитить, затем перейти в ОТДЕЛЬНЫЙ проект с бэком, поработать там. Но хрень вроде Ларавел, где все в куче... Казалось бы, и там и тут фулл стэк, но. Прислали недавно тестовое, на Ларавел, которого я не знаю. А я ради прикола стал разбираться, думал, будучи миддлом, неужели с джуновским заданием не справлюсь? Справился, ознакомился с Ларавел... Такая хрень! Все в куче, работать некомфортно, какие то макароны из кода, папок, импортов, экспортов. Не стал я это задание заканчивать. Надеюсь Некст все таки в такой винегрет не скатится
я работаю с таким же стеком, как и ты, но в силу своих возможностей с особо не сталкивался с большими проектами. Однако даже на средних+ проектах начинается ощущение того, что по немногу все превращается в кашу. И каша эта ещё остается читаемой, если совестливый разработчик делит всё по файлам, тем самым сгружая одномоментный поток информации, при заходе в какую-то часть приложения. А когда у тебя вперемешку сервер и фронтенд, так ещё и грамотного распределения файлов по проекту нет.... Добро пожаловать в ад.
Редко пишу комментарии, но тут согласен с автором, next пошел в развитии в не ту сторону, которую от него ожидали Да и вообще, кажется, что сейчас в первую очередь в React попадают фичи, необходимые для работы Nextjs, а не что-то полезное для разработчиков приложений. А если еще вспомнить, что всем этим счастьем управляет Vercel, то в будущем может получиться так, что для разработчиков будет доступен урезанный функционал, а действительно крутые фичи - только при условии размещения на Vercel
Полностью поддерживаю автора этого видео. Когда видел все эти нововведения и то как западные блогеры пропагандируют это, и как всем все нравится, я решил что видимо это я отстал от "трендов", раз считал это глупостью. Оказалось нет, я не одинок)
Поддержи видео лайком, 1000 лайков 👍 и я следующее видео полный курс по Next.js!
🔐 МК "Реализация оплаты от А до Я" - t.me/pay_red_mk_3_bot
Подробнее о мастер классе - t.me/redgroupchannel/1533
🔥 Оформить премиум подписку - htmllessons.ru/premium
Не парься, Макс. Выбирай Angular 17+ и все будет топ.
ангуляры неактуальны могут стать
@@a1wa7tv пока тут из не актуального только next js))). фигачить проектики, которых никогда не увидит прод - это, конечно, здорово - но вот в поддержке все это дело весьма трудоемкое - и осложняется тем, что с каждой версией - это чудо все "лучше" и "лучше" - за ним не успевают целые команды фронтендеров. Ангулар другая история - он стабилен, он не лезет куда ему не надо лезть (сравните как там реализован ssr), прогнозируемая работа в проде - красота. так что все верно написано. @REDGroup Макс, давай видосы про ангулар - там next и рядом не стоял))))
@@a1wa7tv почему?
@@a1wa7tv Они уже успели столько проектов написать, что ближайшие лет 10 точно актуальны. to my mind
Основная проблема как мне кажется заключается в том, что происходит путаница из за того что является сервером а что клиентом. Особенно это видно на формах. Например в том же Nuxt такой проблемы нет, там есть четкое деление где сервер а где клиент.
components твой друг?
Работаю с nextjs примерно год, долго не мог понять почему они переносят всё на сервер. Вывод один - это будет приносить им больше денег, так как они продают продукт через vercel. Но вот в защиту скажу, что серверный компонент можно делать в клиентском, если вынести его в другой файл в функцию с 'use server' , что впринципе очень удобно и не вредит безопасности, в то время когда можно использовать все хуки на фронте.
Кстати базу использую supabase, с ssr аунтификацией юзеров, не могу сказать что это прямо плохо. Наоборот, очень удобно.
Вы абсолютно правы, именно эти плюсы я выделил в видео. Но есть вещи которые крайне напрягают в разработке больших проектов, если ты не используешь vercel
@@REDGroup у nextjs позиционирует себя как serverless технология на vercel / lambda aws, поэтому они идут именно к этому. У них такая миссия...
Я пока только изучаю JavaScript, что бы в дальнейшем тоже учавствовать вот в таких срачах😊
Макс ты лучший. Уже эта мысль меня преследует как пол года.
Сейчас перешел частично на Astro и Angular 17
Выбираю между этими вариантами в зависимости от проекта
Полностью поддерживаю. Ещё заметил, что помимо того, что они используют все в перемешку (на Западе), так ещё используют платные облачные платформы в своих проектах, а не пишут нативный бэк
Сколько раз пытался использовать React c пришитым Next так и не понял зачем мне оно надо если я пишу свой быстрый бек на Rust Tokio.
Как будто мне намеренно навязывают делать часть бекенда в Nodejs
Next любят не за бэкенд, огромное количество полезных вещей. Которые в реакте нет из коробки.
Макс дай совет как правильно учиться ну узичаю реакт но от процесса кайфую но думаю слабо учусь дай совет самоучке@@REDGroup
Как по мне все правильно двигается, большинству бизнесов не нужны сложные фронты и отдельные бэкенды. Некст к этому двигается чтобы проще было делать проекты для бизнеса, а самое главное быстрее
Некст двигается к тому чтобы продавать верселевские облака и серверлесс инфраструктуру для них. Даже нормального, полноценного бэкенда там не будет.
@@icefrost5844Согласен, особенно учитывая что нормальная работа с тем же кэшем, в next из коробки, работает только если ваш проект на vessel
да, а завтра тебе заказчик скажет что "все, лендос не подходит, хочу себе интернет магазин", и как ты будешь это скейлить?
Бэкенд на php нужно делать, сами разработчики next об этом говорили, что next не подходит под бэкенд.
@@wowzull какой php дядя ты из какого века
Я бэк, но посмотрел с удовольствием. Я много слышу о том, что бекендовые языки программирования не нужны с развитием фронта в сторону бэка, но я не понимаю зачем. Один человек все равно не потянет даже средний проект, либо потянет но привет перегорание. Возможно просто эмоции, так как это попытка отобрать у меня хлеб, а может действительно это функция просто для галочки, чтобы можно было говорить: наш фреймворк настолько крут, что бекенд уже не нужен, и на этом смысл заканчивается.
Я тот самый человек, который умеет хорошо и в бэк (PHP) и во фронт (React). Причем одновременно и уже в нескольких проектах, так что опыт говняния и исправления наговнянного имеется =). Наслушался про Next.js и решил его попробовать на новом небольшом проекте, с ненапряжными сроками. Больше я не буду это никогда использовать. Next.js создает проблем больше, чем решает. И, кстати, я не обнаружил никаких проблем с SEO, используя чистый React + React Router + Helmet, кроме объемного JS бандла при первой загрузке (решаемо, кстати). Есть и хорошее, конечно, но, в целом, можно и без этих удобств как-то обойтись или заменить. Реализация middleware в next.js - это вообще дичь какая-то, особенно после Laravel. Пришлось писать свою реализацию, похожую на Laravel, чтобы совместить несколько разных middleware и раскидать их по разным путям. Работа с cookies тоже имеет проблемы, особенно через cookies(), которые на отрабатывают изменение значений в некоторых ситуациях. Что касается бэка на js, то я интегрировался с таким вот js backend и это прямо боль какая-то. Там нормально не реализовано ничего - ни авторизация, ни очереди, ни производительность (кидаешь 10-15 объемных запросов в секунду, и оно виснет наглухо). Понимаю, что от кривости рук зависит, но зачем изобретать еще один велосипед (js backend) при наличии вполне себе исправного существующего (PHP + Laravel/Symfony), на котором уже реализовано практически всё что требуется? Go - неплохая попытка заменить "медленный" PHP, но что-то как-то не взлетело, если судить по тому какой огромный дефицит кадров, умеющих в Go и нытью HRов, что на рынке практически нет гошников, а зарплаты они просят как 2-3 PHPшника. Ну и там, говорят, довольно мало готовых решений, нужно много самостоятельно делать, а это время. Тем более go уже не имеет такого значительного отрыва по производительности от PHP как раньше. И что остается в итоге? Java/Kotlin и C# для enterprise и PHP для остального. JS/TS - не дает никакого преимущества относительно PHP, но добавляет много проблем, которые давно уже решены в PHP. Про отлов и понятность ошибок в JS - отдельная тема и боль. Так что - выдыхаем, PHP живее всех живых и еще долго не помрёт, как и чистый React.
Да, SveteKit заменит (перегруженные vDOM'ом и овер-синтаксисом) React и Next.js.
SvelteKit в разы превосходит их
Посмотрим, но коммьюнити там нет с такими же охватами
Лично я предпочитаю разделять разработку Frontend и Backend. Для чистого Frontend я использую Next.js, а для Backend - Express или Nest.js. 😉
Считаю, что сочетание Frontend и Backend в рамках одного Next.js приложения может привести к неэффективной работе. Поскольку я чаще обновляю Backend, чем Frontend, раздельная структура позволяет мне избежать необходимости пересборки и обновления Frontend при изменениях только в Backend. 🚀
Так весь серверный функционал - это функционал react 19, а не некст. Он просто оболочка, которая поверх предоставляет пару новых функций. Тут предъява должна быть react, а не next.js. Серверная часть (на котором и происходят действия все сервера) буквально и позволяет оптимизировать приложение, благодаря кэшированию. Вместо того, что бы делать миллион запросов к бд, как это раньше делал react, мы делаем один запрос на стороне сервера-frontend и отдаем всем пользователям кэшированную версию. А еще хотят добавить ppr, но он пока экспериментальный (на уровне сборки компиляция страниц)
Внимательнее видео смотрите. Главная мысль не про это
@@REDGroup Весь backend-функционал стоит рассматривать исключительно как возможность для маленьких проектов. Понятно, что в любом случае всегда будет отдельно бэк и фронт на больших проектах, но для маленьких - это отличный вариант. Зачем говорить о next.js, если form (server) actions - это функционал react, поэтому и говорить нужно о нем.
@@Aleksey-n5h согласен, возможность написать back вместе с фронтом в маленьком проекте - отличная и доступная возможность для независимых фронт-разработчиков без глубоких знаний бэкенда
Спасибо next.js что я открыл для себя vue :)
Ааа зачем тебе Vue ?
ты враг народа тогда...
Фреймворк для девочек верстальщиц)))
@@vladimirpl4782 скажи это gitlab, upwork, Adobe, ozon и т.д. Они учтут твою оценку
@@vladimirpl4782Интллект как у обезянки, видимо не осилио вью, и начинает критиковать юзеров
@@vladimirpl4782 я не верстальщик, я фронтендер! На чем пишешь? На vue!
Жду с нетерпением курс по NEXT. Как раз собрался его изучать.
React на классах было лучшее, нормальное понятное ооп, что и когда рендерится, полный контроль.
Потом зачем то эффекты и прочее начали нести...
Главная проблема nextjs это постоянный ад зависимостей, не самая быстрая сборка, и не очень понятно как строить микрофронты с ним, а если докинем сверху еще nx, pnpm - то понять где, что отлетело после очередного обновления либ - просто ад
А фронт откатился до php в перемешку с js/css вставками)
да пошло оно все,буду использовать в будущем only solidJs/пофигу что мало либ и решений буду свое писать если надо,ьстро летает почти как ванилька,синтаксис jsx,а то все боятся что нету комюнит и либ и все в етом духе,ну и что,eсли бы создатель с либо с++ так думали то бы и языка не создали.
Этого тербует рынок, необходимо смотреть на текущие изменения сковзь призму денег. Железо дешовое, программист дорогой (это про запад, в особенности про зарплаты за океаном), отсюда и такие решения. Наклепали MVB, показали заказчику, чуть допилили, автотестами погоняли и в продашн. Если проект взлетел, будут еще деньги, разделят бэк и фронт. Если не взлетит, то какая разница prisma в api или на отдельном сервере.
Я бы посмотрел как будет идти разделение бэк и фронт. Думаю это очень дорого обойдется по ресурсам
Ну с многим согласен, но не согласен про отсутствие оптимизации. NExt жестко все кеширует
SSR нет, попробуй сравнить затраты ресурсов SSR и ISR подход
Добрейшего дня! Подскажите, когда у вас в платной подписке появятся новые интенсивы для продвинутых? Есть примерные даты?
Нет, у нас сейчас глобальные изменения и выход новой платформы. Потом уже будем заниматься новыми интенсивами
Видео мне понравилось, спасибо, но не понял одно: зачем рекламировать курс где обучают некст в том видео где, грубо говоря, поливаешь некст грязью?)
Потому что альтернатив в любом случае нет, некст Лидер рынка
@@REDGroup дружище, ты же сам выложил видео про альтернативы, а то что он лидер, с этим не поспорю. Просто суть в том что рекламировать курс, в котором преподается некст в видео, где ты критикуешь некст - не очень удачная попытка. А так само видео в целом - 👍
Начал пользоваться Next-ом. На первый взгляд вообще не гибкий. Например, как новичок, не представляю как кнопку по которому модалка должна закрываться и кнопку по которому идет серверный запрос держать в одном форме. При этом кнопки должные быть на одной линии под инпутом. Да, это можно сделать гридом, но все равно странно. Одна кнопка на client, другая на server компоненте.
Next двигается в сторону backend, но он до сих под актуален?
Конечно, альтернатив нет с таким же большим коммьюнити
Альтернатива реакт + свой сср
@@AlexGulyaev Чтош, удачи тогда написать свой next)
svelte kit
Писал на реакте и экспрессе. Недавно попробовал некст по западному гайду и получил плохой экспириенс. Полностью согласен что запихивать призму дб и другое во фронтенд это плохо.
Спасибо за комментарий. На западе еще важно понимать что в каждом видео интеграция к примеру клерк для авторизации. Но в реальной разработке шляпа.
Это превращается в fullstack 😂
Мне нравится, использую server actions , что бы на сервере получить доступ к grpc java серверу и отправить клиенту уже готовые данные без описания rest api
Я в видео про это сказал, есть реально полезное применение. Но я больше говорил про тогда когда года базу и призму к примеру запихивают прям во Фронт.
Почему нет места такой реализации? Существовали же в начале двухтысячных приложения, которые жаловали SSR. Вопрос того, какой инструмент использовать -- это да...
А зачем? Если есть более крутые способы более быстрые и оптимизированные для сервера и для клиента
Макс, я не могу с тобой не согласится, но это смотря для какого проекта мы создаем решение и насколько быстро оно требуется.
Рано или поздно все в любом случае будет сходить на клиент-сервер, но в данный момент может требоваться "качественный" монолит, который можно впоследствии будет разбить по обязанностям (отрисовка, контроль bm и тд). Next.js данную потребность закрывают на сегодняшний день.
Это обойдется гораздо дешевле заказчику, нежели набрать несколько команд и платить им.
Сейчас вот SQL во фронт подтянется и бек вообще будет не нужен. 😆 Понапридумывают своих Джангов и Ларавелей...
Макс привет! спасибо за твои мысли, интересно тебя слушать, а что думаешь о Nuxt?
Привет, в накст у меня очень мало опыта.
@@REDGroup Нукст)
@@FuIIstack Нюхт)
Мне нравится новый Next, но я каждый раз в ужасе когда нужно передать данные в новый роут.Я до сих пор не понимаю как можно в query передать огромные обьекты и вообще открыто показать какую дату в UI используется при этом пользователь может свободно играть с этими query.
Недавно видел как в url был query apiKey а там был показан private кей какого то сервиса 😂
по поводу оптимизации, можно использовать реакт квери, и тогда будет кеширование, и 10к юзеров не будут делать 10к запросов к базе
Можно, но мы же говорим про тренды некста. Я по сей день использую next в большинстве проектов и избегаю ssr
почему не будут? Первый то запрос всё равно улетит
Nuxt
Красавчик, видео с каждым разом все лучше и лучше
урааааа!
я дождалсяяя😂😂
Ждем курс по next
С 9-ой версии начал использовать Next, очень понравился после Gatsby для фронта. Однако с 13 версии, когда выкатили app router, стало какое-то странное послевкусие и правильно ты сказал, что движется сей поезд с названием Next, не туда. Сейчас уже чуть больше года ушел на Astro и думаю, что так должен был бы выглядеть Next.js, только со своими фичами.
Спасибо! Интересная тема. Просьба и дальше делать таких видео.
Честно не сильно хочется, очень противоречивая тема и много срача в комментариях. Это так крик души и чтобы канал не простаивал, пока я разрабатываю dark side
Интересно, спасибо за видео.
Тоже так думаю, зачем во фронтенд тянуть бэк, лучше разделять
Посмотри 1С Элемент, там вообще сделали веб версию 1С, можно накидать фулстек приложение за день ничего не зная про вёрстку, вебпак, ssr и остальные кишки веба. Правда интерфейс контролов убогонький. Если дадут применять стили то будет убийца всех реактов и ангуляров
Сто процентов 💯
учите джава ее. там такой каши нет.)
Крайне советую попробовать и дать шанс Remix ;)
Лучше использовать React а лучше идти против системы и брать vuejs
полностью согласен
Это называется “Толерантность” - смешаем люди, кони, и в продакшн😅
Похоже на то, что переключаются из режима приносить пользу в режим рубить бабло, если так в общем на ситуацию посмотреть..
Наопмнило как то давно в 1с появилось разделение на клиент и на сервер, меня тоже дико парило поначалу
пишу коммент в поддержку и продвижение этого канала
как всегда на высоте💪💪💪💪
Как всегда топ!
Забудьте про Vue и React.
*Svelte* фреймворк нового поколения! И без минусов первых...
Комьюнити гораздо мелкое, по сравнению с этими гигантами.
Чтож мы все не на свелте то пишем?
@@xebunwhynot заебали эти свелтщики которые один раз проект написали на нем и теперь всем твердят что он лучше лучше остальное говно
Ангуляр лучше
Но для «западных блогеров» с концепцией shipfast это всё невероятно упрощает соло фаундинг
Недюсь они не будут пропагандировать что типо он не юзайте вообще отдельный бэкэнд типо что можно все в Некст, а будут просто типо фокус на фронтенде и максимально облегчить фронтенд с помощью серверных штук там. Понятно что бэкэнд отдельно должен быть в этом миллион плюсов
Круто что у меня получилось донести мысль. Да, я тоже в это верю.
Макс, вам нужно обратиться к разработчикам Next,js и поделится своими соображениями, 😉😉
а то, похоже, им нехватает квалификации и понимания современных трендов разработки и делают они что-то не то 🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣
Полностью согласен. Пусть фронт остается фронтом, а бэк бэком. Мне не трудно один таск сделать на фронте, закоммитить, затем перейти в ОТДЕЛЬНЫЙ проект с бэком, поработать там. Но хрень вроде Ларавел, где все в куче... Казалось бы, и там и тут фулл стэк, но. Прислали недавно тестовое, на Ларавел, которого я не знаю. А я ради прикола стал разбираться, думал, будучи миддлом, неужели с джуновским заданием не справлюсь? Справился, ознакомился с Ларавел... Такая хрень! Все в куче, работать некомфортно, какие то макароны из кода, папок, импортов, экспортов. Не стал я это задание заканчивать. Надеюсь Некст все таки в такой винегрет не скатится
Тоже самое я могу сказать и про реакт с его хуками... Вот ангуляр - другое дело
я работаю с таким же стеком, как и ты, но в силу своих возможностей с особо не сталкивался с большими проектами. Однако даже на средних+ проектах начинается ощущение того, что по немногу все превращается в кашу. И каша эта ещё остается читаемой, если совестливый разработчик делит всё по файлам, тем самым сгружая одномоментный поток информации, при заходе в какую-то часть приложения. А когда у тебя вперемешку сервер и фронтенд, так ещё и грамотного распределения файлов по проекту нет.... Добро пожаловать в ад.
Редко пишу комментарии, но тут согласен с автором, next пошел в развитии в не ту сторону, которую от него ожидали
Да и вообще, кажется, что сейчас в первую очередь в React попадают фичи, необходимые для работы Nextjs, а не что-то полезное для разработчиков приложений. А если еще вспомнить, что всем этим счастьем управляет Vercel, то в будущем может получиться так, что для разработчиков будет доступен урезанный функционал, а действительно крутые фичи - только при условии размещения на Vercel
100й коммент для продвижения толкового контента!
Полностью поддерживаю автора этого видео. Когда видел все эти нововведения и то как западные блогеры пропагандируют это, и как всем все нравится, я решил что видимо это я отстал от "трендов", раз считал это глупостью. Оказалось нет, я не одинок)
Astro
Хорошая альтернатива, но пока слабовата. Надо время. И там больше упор на статику
Даёшь 100 комментов!
Laravel и Vue рулит
нравится