По моему слухи о простоте фронтенда сильно преувеличены) особенно когда слышишь мнение чистых бэков, которые пытаются разобраться как там на фронте что то работает. Плюс куча проектов которые уже написаны с разделением клиентской и серверной части, их надо будет поддерживать еще долгое время
@@YuliyaAnts не смешите меня) там чистый фронт с n годами опыта (впишите абсолютно любую цифру), сидит с квадратной головой, что там будет делать не профильный фулстэк я хз
Вот мнение чистого бэка на этот счёт. На мой субъективный взгляд, обвесится фреймворками, препроцессорами, префиксерами, оптимизаторами, шаблонизаторами, хинтерами, линтерами пакетами к ним и сборщиками всего этого говна, это слегка перебор для лэндинга, который продаёт десять платьев, и на котором две с половиной кнопки.
Читаю комментарии и удивляет что есть люди которые говорят что либо фронтендеры не нужны или бэкендеры. Мне кажется сейчас все на своих местах. Если бы бэкендеры попробовали сверстать что нибудь сложнее формы (без готовых библиотек, которые кстати тоже фронтендеры пишут) с кастомныи дизайном, с анимациями и адаптивом, а фронтендеры попробовали спроектировать высоко нагруженный бэк и оптимальной архитектурой БД, то все бы начали ценить работу других.
Тут вижу два момента напряжных. Первый, это то что с некст нужна ноду на сервере заводить. Второе что в любом случае большинство крупных проектов не ограничиваются только сайтом. Есть мобильные приложения, есть десктопные решения. Соответственно всё это ходит на сервер за данными, и естественно это не сервер next) Это полноценный сервер, к примеру на nestjs. То есть получается использование next будет рационально далеко не на всех проектах. Я себе вижу next-овый сервак как небольшой сервер для выполнения местных, фронтовых задач, а так же выполняющий проксирование запросов на большой нормальный бэкенд. Работа с базой данных непосредственно в рамках next это для каких то очень мелких проектов годится.
Уже уйму лет Next так и используют, как BFF. А бэк отдельно на JS или любом другом языке. Если есть мобильное и/или десктопное приложение то само собой бэк будет отдельным.
@@woodzimierz9621 проблема в том, что антипаттерн - это только в голове, кто-то где то когда то решил что вот это хорошо, а это плохо. Но проблема в том что это он решил, всем остальным пофик и тут начинается религия! Крестовые походы по смене регилии и вот это вот все. прям смотришь на этот цирк и смешно.
Слышу я про простой фронтенд и вспоминаю недавнюю задачу, когда 1 страничка хендлит 5 разных переходов на неё, при этом в парочке надо сетать данные в форму, 4 вида бредкрамбсов и т.д. и т.п. И вот тут 1 из них не работает... Плюс вспоминаю таски из разряда на 13 андройде ноунейм бренда не работает хендлинг того-то и того-то в реакт прилаге завёрнутой в капаситор =)
Тут проблема не в технологиях, проблема в реализации. На счет последнего примера не удивительно. Условные Capacitor, Cordova, RN - бюджетные решения со всеми вытекающими. При экономии на полноценной мультиплатформе - Kotlin, Flutter, а уж тем более нэтиве, придется мириться с специфичными проблемами
Если мы будем говорить про сферический вебапп в вакууме то ssr подойдет. Когда же мы начнем туда прикручивать мобильные приложения, доп админки, синхронизации с CRM/ERP, то этот монолит нужно будет разбивать и оптимизировать и все вернется на круги своя. Так же если мы говорим про хайлоад, то затраты на серверные мощности легко превысят затраты фонда оплаты труда с дополнительным бекэндерлм.
+, выбесило пздц, влепил диз. Выпускать контент разговорного формата, в котором ребёнка слышно не сильно хуже, чем тебя. Что блять. Банальное неуважение к аудитории.
Тут скорее делоив том, что фронтенд переусложнен на данный момент. Множество сайтов можно было бы реализовать jQuery. Безо всяких компонентов и реактов с ангулярами.
@@deniskhakimovРеакт по сути вообще не нужен. В большинистве кейсов достаточно Vue или Alpine.js. Второй кстати можно юзать без npm-а, прямо в вёрстку вставлять и юзать как vue. Даже подобие composition api имеется.
@@deniskhakimov И только тру скиллоовые архи разрабы пишут крутые инерактивы на jQuery и чистом JS, потому что React / Vue / Angular для тех кто не тру и не думает, верно?)))
Я ток не понял, нафига при таком подходе функции бэка во фронт пихать? Ну рендерятся теперь странички на сервере, дык нехай серверный рендер на бэк апихи ходит, как раньше с браузера ходил.
Я думаю тут логика простая "Почему бы и нет". Каждому продукту нужно выделяться чем-то на фоне остальных. Вот и Next.js выделяется. Считаю что выбор стека это дело вкуса, а не обязанность каждого инженера бежать за трендами.
Начиная с next 13 начинаешь задумываться о таких вещах как сделать больше серверных компонентов. А из за бекендеров это сделать не возможно просто. История о том как всегда бек всю логику с удовольствием готов скинуть на фронт. Это пагинация фильтрация и т. д. При больших объёмов передачи данных.
Ну по сути как я давно делаю начиная работь с Firebase для не очень сложных web app типа магазина или чата или todo и т.д. отличный вариант для фронтендера без гдлубоикх знаний backend, я пишу сам фронт и юзаю готовый бэк с не реляционной БД. Для экономии времени просто шикарно. Мне больше не нужен server не нужно арендовать сторэдж на AWS "whatever" замарачиваться с аутентификацией и прочее.
2:20 - я ночью смотрю и я один в квартире. И тут какие-то жуткие голоса. Я аж обомлел. Анекдот вспомнил: нет ничего прекрасней детского смеха, но только не ночью и только если у вас нет никаких детей
Это как с верстальщиками было, с появлением фреймоворков их становилось всё меньше и меньше, и вот сейчас только крупные компании могут себе позволить держать в штате парочку верстальщиков. Но, думаю, что многие преувеличивают говоря что фронт вымирает и мы потихоньку вступаем в эру фулл стака. Скорее всего, как и было сказано, небольшие проекты будут переходить на такую разработку, а средний и крупный бизнес будет работать по старому
Так когда на клиенте рендерилось, в этом и приэмущество было, что сервер меньше напрягается, пусть сервер крутится на каком-нибудь говно-vps с гигом памяти, а клиент на свое супер компе со 100500 ядрами рендерит сам себе в браузере страницу. А теперь что, обратно в сервер все тащим?
Пишем большой проект на новом app router и, честно говоря, уже столкнулись с массой проблем. 1. Есть четыре вида кеширования, из всех можно выйти кроме одного, клиентского, что есть большим минусом, а единственное решение это костыль 2. Часто бывают баги при билдинге 3. Документация явно недописана 4. Критически не хватает инициализации сторы на сервере для синхронизации данных со сторой на клиенте, в последствии чего, стора на сервере могла бы удалиться. 5. Проблема уже самого реакта, но все же. Реакт не дает возможность передавать пропсы пропсу children (во вью есть такая фича), что могло бы помочь создавать переиспользуемые компоненты
Есть клиентская платформа на реакт CPA, которая грузит процессор у КАЖДОГО пользователя около 20%. Всего около 400 работников. Я представляю какой мощности нужен сервер, чтобы все это считать на сервере.
Фронт в последние года сильно усложнился. Да еще и меняется с большой скоростью. Но тоже чувствую тенденцию, что фронтенд разработчики станут фулстэк. Это экономически выгодно.
Все возвращается на круги своя! Я еще помню времена, когда никаких стеков вообще не было. Был некий "оператор ЭВМ", который должен был уметь все! Сделать полностью сайт и дизайн к нему, поднять сервер и обеспечить безопасность, настроить все компьютеры в офисе, заправить катриджи в принтерах, починить розетку и кофейный аппарат...
я скорее всего ошибаюсь, но это очень похоже на Java EE технологию для серверного рендеринга страниц, которая была представлена в 1999 году. поэтому бегите учите джаву пока не поздно )
Не смотрел презентацию Next 14. Но мне кажется автор что-то не так понял про написание бэка и фронта в одном приложении.. Ага, я уже представляю как огромное бэкенд приложение с туевой хучей микросервисов пишется с фронтом в одном приложении. Забавно наверное разрабу получить такое тз где он будет писать и бэк и фронт:D
Ну бэкенд не ограничивается только запросами к БД, если это не бэкенд какого-то тудутиста условного. Если на бэке какая-то сложная логика происходит то тут некст сам не справится имхо.
По-моему 99% проектов именно так и работают. Вследствие не совсем понятно, зачем вообще бекендеру деньги платить, если можно это не делать, просто научив фронтендера писать sql-запросы.
@@Гооол-й4ч , ну не sql-запросами едиными:) У меня есть свой проект на котором бэк ходит на сторонние сервисы, собирает некоторые данные, обрабатывает их, рассылает пуш-нотификации юзерам в приложение на телефон, отправляет мне некоторую статистику и уведомления и много чего еще, что не ограничивается sql-запросами.
Для меня самый большой минус этого всего , опять надо что-то учить , ну почему я не пошел на data engineer , писал бы сейчас таблички и запросы в sql и python (((
согласен. мне тоже не нравится, что нужно каждый день свои знания актуализировать, т.е мы все по сути обречены быть 50 летними дедами-школьниками которые каждый день после раб отки будут сидеть и смотреть, что же там выпустили нового в вротэнде... боже спаси и сохрани души этих клятых грешников, аминь.
По пункту что форнты не нужны: я фронтенд разработчик и когда устроился в текущую компанию мне стало плохо от того как коряво, плохо, некачественно, на костылях и с очень сложной возможностью поддерживать приложение написан код в нескольких приложениях. Работодатель хотел сэкономить и нанимал фулл-стек разработчиков в разное время, пришло к тому что сейчас большая чать просто переделывается фронтендиром, бекендиром и девопсом. Выводы делайте сами.
Дык живые приложения всегда переписываются. Один из самых вменяемых моих клиентов даже после того, как я неоднократно объяснял ему, что после завершения проектирования БД и начала работ, добавить новый функционал будет сложнее, если мы заранее не обговорим эту возможность, через пару месяцев активной разработки внёс несколько серьёзных изменений, которые потребовали от меня отказаться от изначальной почти идеально нормализованной структуры БД в пользу быстрых, но корявых решений. Корявыми решения были только потому, что изначальная структура проекта не подразумевала гибкости там, где она понадобилась клиенту, а эта самая гибкость аукнулась снижением скорости работы, в результате чего пришлось создавать ненужные кеширующие таблицы с дубликатами данных. Всё в итоге заработало быстро, но внутри там местами такой код, за который мне стыдно. Собственно, в течение последующих нескольких лет я периодически ломал изначальную структуру проекта для внесения новых фишек, которые изначально считались абсолютно ненужными. И подобная картина наблюдается практически со всеми проектами, которые живут, эволюционируют и приносят реальную пользу своим владельцам. Так что подобная корявость - это скорее норма. Если вы сталкивались в работе с очень крупными общероссийскими проектами, то должны знать, какой там код )
В корпорате) Я как-то делал одну форму месяц за много денег =) правда там было около 300 различных импутов разделенных табами и аккордеонами, плюс значения одних импутов влияли на валидаторы других.
Изучаю его сейчас. Советую тебе смотреть официальную документацию, делать себе заметки. Лучше, если ты начнешь какой-то проект и будешь спрашивать у чат гпт какие-то моменты по настройке next.js. Когда не у кого спросить, очень помогает
@@PacoOfficial может помочь и версия 3.5. Там, кажется, сейчас в любом случае бесплатно не зарегистрируешься. Но вообще, в телеграме есть разные боты бесплатные (даже с версией чатгпт 4)
Господа фронтендеры, спешу вас огорчить, описанная технология (по крайней мере, как я понял) принесет просто нереально много проблем. Все хорошо будет работать, если сценариев похода в базу будет 5-10, но когда их станет больше 100, отлаживать это станет просто нереально больно! Для средних и крупных проектов нужны очень строгие правила обработки бизнес транзакции, не представляю как это реализовать на данной штуке. Такие проекты просто будут одноразовыми, так как по мере их роста, поддерживать такое будет нереально =( А бизнесу не объяснить опасность, им главное модно и прикольно (нанять 1 человека вместо 2), правда потом велик шанс все это переписать, но уже понадобятся 5 человек...
Погоди чуть-чуть, они еще непуганные, нестрелянные. Пройдет немного времени, они понапилят этого мусора, потом придут ко мне, а я буду сидеть, как Крестный Отец, с сигарой в зубах и говорить: "Ты просишь меня пойти к тебе бэкендом за 3 ставки от рынка, но делаешь это без уважения".
Крупные проекты и так не слезут с рельс бекенд + фронт. А мелким до 100 к пользователей вполне хватит. Да и вообще на мой взгляд next решила просто убрать bff сервера=)
да все будет как и сейчас, запросы разделятся между некст серваком и основным если есть мобайл аппки то будет ток основной, плохо это или хорошо фиг знает))) но то что бизнесу это очень нравится это факт 23 год вообще хайп словили на этой теме, нанять команду взять nextjs и какой firebase или supabase и разработать среднего размера продукт за пару месяцев с этим не поспоришь) лично мне нравится такое развитие событий
Да, я в таких ситуациях всегда вспоминаю напряженные лица господ бэкэндеров или же фулстаков от бэкэнда, когда они пытаются понять с чем же употреблять это ваш CSS и его производные. К сожалению обычно это заканчивается доказательствами того, что дизайн аля win2000 style это отличное решение и вообще всё выглядит просто улётно, а главное так же замечательно работает и все свои функции выполняет.
да тут даже все фреймворки морально устарели т.к ложат переменные в инлайн код. т.е фреймворки сегодня должны объявлять css переменные и работать через них. так что тут ещё фронту нормальной фреймворк лет 40 делать ...
Ад даже девопс хотя казалось бы тоже на серверах настроен и выполняется. Про фронт вспоминать страшно. Я иногда захожу на дейлики коллег которые пишут проект с UI и такой: как же хорошо что этогл гемора в моих сервисах и лямбдах нет ❤
Часть из тех _офисных бездельников,_ с которыми я сталкивался по работе, стремились скорее к домашнему уюту: любимому креслу, приставке, телевизору, лодке, гамаку, и т.д. И это не удивительно, ведь когда твои основные финансовые "хотелки" закрыты, а работаешь ты за время, а не на результат, то вполне естественно, что у тебя не будет сильной мотивации к развитию. Сам помню, что когда торчал в офисе много лет назад, хоть и развивался, но делал это заметно медленнее, чем "на воле". В офисе много отвлекающих от обучения факторов + основная задача - исключительно то, что нужно выполнить по работе. А на вольных хлебах твоя основная задача - быть максимально эффективным и разносторонне развитым, иначе клиент уйдёт к другому специалисту.
Нагромождение фреймворков есть следствием удешевления и ускорения разработки. Я думаю с внедрением и улучшением ИИ, фреймворки просто вымрут. Роботы смогут текстовое описание проекта превращать в нативный высокопроизводительный код html + css + js без паразитных надстроек.
А вы уже пробовали Locofy AI? Судя по видео и обзорам это весьма неплохая штука. Если будет прогрессировать так же, как и другие инструменты с применением машинного обучения, то через годик-два веб-разработка начнёт замечать грядущие масштабные изменения в IT отрасли...
Еще проблема бекендеры не любят FP. А любят ООП. Фронтенд уйдет в фулстек. Когда говоришь любому беку что его можно легко заменить. То он сильно обижается. А на js очень сильно обижены бекендеры.
Бэкенд это не просто отдать апи на фронтенд, это еще и фоновые задачи, различные базы sql/nosql, кубер, транзакции, саги, микросервисы, и тп. задачу забрать данные из простого хоанилища фулстек заберет не проблема, но то что скрыто под водой айсберга нет
Такой вопрос, немного не по теме! Было несколько сайтов на укозе. Сейчас все заблокировано. Есть ли бесплатная Западная альтернатива? Чтобы на конструкторе сделать свой сайт и туда загружать свои материалы и чтобы хостинг был бесплатный. Несколько лет подряд укоз навязывал хостинг за 74 доллара....
А вам не кажется, что таких слоев абстракций уже намешали - только ради денег - усложнили тоже ради денег (дай угадаю за поддержку денег берут). Ходят по кругу не знают что еще придумать, ради бабосиков. По моему скромному мнению 90-95% задач решается проверенными технологиями. У нас же в каждом дворе по НЕТФЛИКСУ и АМАЗОН.
Ухты, как в старые добрые времена: - "Ты кем работаешь?" : - "Я работаю вебмастером": - "Ооо, правда что-ли, тогда можешь сделать мне сайт под ключ по-дружески?"
Миш, у тебя макбук 14. Мог бы ты выпустить ролик с обзором, какое разрешение, норм ли влазит контент с открытыми вебтулзами. Вообщем глазами веб-разработчика, чтобы понять подходит 14ый дисплей или нет
Я знаю как минимум 5 ребят которые работают на 13 дюймовых эйрах и им всё ок. Я не могу так работать, мне например и 16 мало. Так что это всё вкусовщина.
Мне 14 терпимо, коллега на 13 работает в кайф, а моя жена (автотесты пишет), так ей 16 дюймовый как минимальное требование. Вкусовщина и восприимчивость глаз. Но по сути, 4к на 14 дюймах уже сложно читаем. Я 2048*1330 использую, но бывает покрупнее делаю.
Чувак 14мау бук про на м2 это лучшее что у меня было за последние время)) это просто топ топчанский я хотел купить один 14, а второй 16 чтобы сравнить их, но после 14 я купил второй 14 потому что 16 слишком большая
14 дюймов идеален для разработки. Веб тулзы для правки стилей каких-то не то чтоб прям супер удобно (супер удобно это когда на разных физических мониторах разнесено), но вполне терпимо, за счет плотности пикселей можно масштабировать изображение и всё равно комфортно работать. 16 точно как рабочая лошадка не пойдет, слишком громадный
На Postgres доку читали? Там куча всего! Бэкапы, версионирование,права, миграции.... Ещё и логики куча. На сервисы всё разбивать? Потом di придумают в компоненты😂.
@@Longmanrus , блин, расскажи, давай проверим. Индексы это у массивов что-то, да? Я в них просто тоже не очень, мы обычно на фронте работаем с такими технологиями, как и , в чём-то большем разбираться не приходится.
Какие же бекендеры в коментах мерзкие, с чего вы вообще решили что чуть ли не все лучше всех могете, чуть ли не каждый высерает что то в духе -'я за секунду выучу все фреймворки + могу еще и свои создать если надо' Кмон в 2023 году живем и фронт уже куда обширнее и сложнее стал, ибо все ударились в оптимизацию, нахуя приводить в пример лендинги одностраничные которые вообще на конструкторе клипают, я не понимаю.? Чел на авторе вообще шизоид и каждый видос у него КАТАСТРОФА для мира фронта. Про алгоритмы на бэке вообще смешно слышать...
та они судят по фрейморку\библиотеке одной, забывая, что фронт - это браузер. Браузеров херова туча, куча версий, говноIE. И вот тут все начинают жрать говно, когда на макос работает норм, а на винде повляется скролл и все едет по п...е)) Так же забывают про адаптив, accessibility. Почему-то все смотрят на реакт в вакууме, а это всего лишь инструмент для работы с любимым DOM)
Как раз перешёл на проект с Nextjs, актуально, спасибо! Но перед этим работал на проекте где заказчик строго разделял бэк и фронт. На каждого свои разработчики. Не думаю что из-за next фронты останутся без работы
Стандартизированый фронтэнд - да, вымрет. Но, уникальные решения и разработка новых интерфейсов, либо сложных анимаций, webgl и прочего смежного с дизайном - нет. Я видел как бэкеры работают с домом, оптимизацией и UX. Мне про вёрстку в 10 году году говорили что я мамонт, в итоге люди не могут папап анимаровать нормально без библиотек. Решаю сложный уникальный интерфейс создавая библиотеку стилей за 5 дней. Кто-то писал про GPT - будете дольше промты писать чем я создам поддерживаемую архитектуру
А если бэк на Java и api это бэка кроме вэба ещё и мобильные приложения дёргают? Да и на серьёзном проекте никто фронтов к бэку не подпустит - имхо чисто для малобюджетных простых проектов с исключительно веб интерфейсом.
Хз почему бэкендеры в комментах радуются. Ты как-то неправильно интерпретировал. Такие фулстэк приложения пишут как раз фронтендеры, обходясь без бэкендеров. По сути они отбрасывают надобность найма командны профессиональных бекендеров, уменьшая затраты компании. Что как раз хорошо для бизнеса. Если мир пойдет по направлению nextjs, проблемы возникнут у большинства бэкендеров. Фронтендеру не трудно перейти с того же реакта на Некст. А вот типам, пишущим на других языках, будет не легко познать джава скрипт
"Такие фулстэк приложения пишут как раз фронтендеры, обходясь без бэкендеров. По сути они отбрасывают надобность найма командны профессиональных бекендеров, уменьшая затраты компании", сразу видно гуманитария) погугли что такое чел/час
ну, кроме страниц где нужно SEO есть еще очень много приложений где нужны и фронты и беки, и бек JS'ом не заканчивается, но да, делать сайт на PHP и быть фулстеком проще, чем быть бекендером на Java, Go и т.п. и быть фулстеком сложнее. Мне кажется % бека на Node сейчас все равно еще очень и очень мизерный, чтобы об этом как то серьезно говорить, чтобы фронты двигались в сторону бекенда. Могу ошибаться, но ощущения примерно такие.
SSR как кастыль, впрочем и javascript фреймворки появились от нежелания вчитываться в спецификацию языка. Javascript воистину самый непонятый ЯП в мире программирования. Даже у php куда лучше дела чем у js. Очень забавно, что вернулись к проверенной временем парадигме: «На сервере вычисляем, а на клиенте отрисовываем данные.» Подрядчик может заблуждаться, но не карман заказчика. Потому благоразумие возьмёт рынок и время верно расставит акценты.
Раньше ученые или просто талантливые коллективы создавали языки и технологии. Прорабатывалась концепция и все работало. А сейчас миром программирования (веб больше всего пострадал от этого) правят "хипстеры" с их "вейпами", "барбершопами", и прочей ересью. А потом случаются разного масштаба "хайпы", которые потом становятся мейнстримом... и попробуй отказаться от мейнстрима.
Да нет, просто сейчас все хотят с минимумом затрат что-то получить. Собрать как конструктор. И что бы один человек им все это сделал. Поэтому придумывают всякую хрень. В идеале вообще писать с нуля без всяких фреймворков и лишней лобуды. Она не нужна.Тогда сайт получается легкий, грузится моментально. Аяксом только динамически изменяемые данные передавать в JSON по минимуму, а не все подряд с огромными кусками html, css. Все ссылки можно сделать без перезагрузки и т.д. И тогда при 200 000 уников в сутки и более сайтик может работать на самом простом хостинге за 500 рублей в месяц. И никаких проблем не будет вообще. У меня такое чувство что эти все разработчики специально создают всякие идиотские геморойные технологии, что бы у людей постоянно возникали с ними проблемы и они вновь и вновь искали пути их решения. Такое чувство, что не упрощают они жизнь людям, а усложняют.
Да ладно вам, в самом ReactJS нет ничего сложного. Сложности созданы (и продолжают создаваться прямо сейчас) искусственно - это частые обновления мажорных версий и применение React там, где легко можно обойтись простым VanillaJS. React ведь не привнёс в Web ничего нового. Всё, что можно на нём реализовать, раньше без проблем создавалось на чистом JS.
О каком бекенде может идти речь если ни базы ни апи не сделать? Это лишь подготовка фронта на сервере не более того. Запросы просто идут через прокладку еще одну серверную на нормальный бэк. Без этого полноценного приложения с отправкой и сохранением данных не построить, только статику.
Миша, ты рассуждаешь с точки зрения что использовать JS - это нормально, я тебе скажу как Java dev - это не нормально, это страдание, все на фронте сложно не потому что фронт сложный как сфера, а потому что JS убог как и Meta со своим реактом. Если говорить в общем, то по мнению 95% бэков JS - это полное убожество, не может вся web индустрия вот так вот переползти полностью в JS, хотя-бы потому что он интерпретируемый, не говорят уж про его убогий синтаксис, не будут все жрать кактус и становиться фуллстаками на основе JS фреймворков.
Очередной способ, разрабам убедить бизнес "нам нужны деньги, мы снова будем все переписывать, а все что было написанно ранее, это легаси " Дайте денег))
По моему слухи о простоте фронтенда сильно преувеличены) особенно когда слышишь мнение чистых бэков, которые пытаются разобраться как там на фронте что то работает. Плюс куча проектов которые уже написаны с разделением клиентской и серверной части, их надо будет поддерживать еще долгое время
Фуллстеки с поддержкой вполне могут справиться
На фронте просто дикий зоопарк технологий решающих одни и тежи проблемы.
@@YuliyaAnts не смешите меня) там чистый фронт с n годами опыта (впишите абсолютно любую цифру), сидит с квадратной головой, что там будет делать не профильный фулстэк я хз
Вот мнение чистого бэка на этот счёт. На мой субъективный взгляд, обвесится фреймворками, препроцессорами, префиксерами, оптимизаторами, шаблонизаторами, хинтерами, линтерами пакетами к ним и сборщиками всего этого говна, это слегка перебор для лэндинга, который продаёт десять платьев, и на котором две с половиной кнопки.
@@zmirk все для нужд бизнеса как говорится)
Читаю комментарии и удивляет что есть люди которые говорят что либо фронтендеры не нужны или бэкендеры. Мне кажется сейчас все на своих местах.
Если бы бэкендеры попробовали сверстать что нибудь сложнее формы (без готовых библиотек, которые кстати тоже фронтендеры пишут) с кастомныи дизайном, с анимациями и адаптивом, а фронтендеры попробовали спроектировать высоко нагруженный бэк и оптимальной архитектурой БД, то все бы начали ценить работу других.
Тут вижу два момента напряжных. Первый, это то что с некст нужна ноду на сервере заводить. Второе что в любом случае большинство крупных проектов не ограничиваются только сайтом. Есть мобильные приложения, есть десктопные решения. Соответственно всё это ходит на сервер за данными, и естественно это не сервер next) Это полноценный сервер, к примеру на nestjs. То есть получается использование next будет рационально далеко не на всех проектах. Я себе вижу next-овый сервак как небольшой сервер для выполнения местных, фронтовых задач, а так же выполняющий проксирование запросов на большой нормальный бэкенд. Работа с базой данных непосредственно в рамках next это для каких то очень мелких проектов годится.
Уже уйму лет Next так и используют, как BFF. А бэк отдельно на JS или любом другом языке.
Если есть мобильное и/или десктопное приложение то само собой бэк будет отдельным.
Это похоже на анти-паттерн (бизнес логика внутри react компонентов), точно будут пазлы из серии "какой компонент обновил базу" итд
Ну почему сразу похоже, зачем этот политес? Это и есть антипаттерн.
что такое бизнес-логика это какой- то бизнес внутри Nextjs есть ? какая маржа там ?
@@ant3413 бизнес логика - это код, который определяет как клиент будет получать информацию о продукте и как с ней взаимодействовать
@@ant3413 Доменный уровень приложения (из DDD), иногда его так называют
@@woodzimierz9621 проблема в том, что антипаттерн - это только в голове, кто-то где то когда то решил что вот это хорошо, а это плохо. Но проблема в том что это он решил, всем остальным пофик и тут начинается религия! Крестовые походы по смене регилии и вот это вот все. прям смотришь на этот цирк и смешно.
Слышу я про простой фронтенд и вспоминаю недавнюю задачу, когда 1 страничка хендлит 5 разных переходов на неё, при этом в парочке надо сетать данные в форму, 4 вида бредкрамбсов и т.д. и т.п. И вот тут 1 из них не работает... Плюс вспоминаю таски из разряда на 13 андройде ноунейм бренда не работает хендлинг того-то и того-то в реакт прилаге завёрнутой в капаситор =)
:0
Тут проблема не в технологиях, проблема в реализации.
На счет последнего примера не удивительно. Условные Capacitor, Cordova, RN - бюджетные решения со всеми вытекающими. При экономии на полноценной мультиплатформе - Kotlin, Flutter, а уж тем более нэтиве, придется мириться с специфичными проблемами
Если мы будем говорить про сферический вебапп в вакууме то ssr подойдет. Когда же мы начнем туда прикручивать мобильные приложения, доп админки, синхронизации с CRM/ERP, то этот монолит нужно будет разбивать и оптимизировать и все вернется на круги своя. Так же если мы говорим про хайлоад, то затраты на серверные мощности легко превысят затраты фонда оплаты труда с дополнительным бекэндерлм.
полностью поддерживаю, писать бэк чисто для мобилки вряд ли кто-то захочет, а мобилка есть почти у всех уже
Я писал прям отдельные сервисы для мобилок но это действительно редкий случай.
шум на заднем фоне заствалял меня каждый раз проверять не появились ли у меня соседи
🤣 снимал наушники каждый раз пока не увидел твой коментарий
Ахаха я представляю как ты со своей иконкой выходишь на улицу и смотришь не появидись ли соседи🤣🤣
+, выбесило пздц, влепил диз. Выпускать контент разговорного формата, в котором ребёнка слышно не сильно хуже, чем тебя. Что блять. Банальное неуважение к аудитории.
Подождите ещё годик-два, они свой php напишут на js..
Смотря на их энтузиазм, это вполне реально
еще один хоронитель РНР. Уж хоронят его, хоронят, а он все живее всех живых.
TL DR:
Опять фронтендеры не нужны, всё пропало, учите бек
Тут скорее делоив том, что фронтенд переусложнен на данный момент. Множество сайтов можно было бы реализовать jQuery. Безо всяких компонентов и реактов с ангулярами.
+ многие новички верят, что без React или Angular невозможно создать интерактивный, быстрый и отзывчивый интерфейс.
@@deniskhakimovРеакт по сути вообще не нужен.
В большинистве кейсов достаточно Vue или Alpine.js.
Второй кстати можно юзать без npm-а, прямо в вёрстку вставлять и юзать как vue.
Даже подобие composition api имеется.
@@fastwalker3551 "Реакт по сути вообще не нужен. " "В большинистве кейсов достаточно Vue"
Во ты выдал конечно🤣🤣🤡🤡
@@deniskhakimov И только тру скиллоовые архи разрабы пишут крутые инерактивы на jQuery и чистом JS, потому что React / Vue / Angular для тех кто не тру и не думает, верно?)))
Next js мне нужен только для того чтобы индексировались страницы для сео. Вообще не собираемся использовать серверные экшени.
мы роботов отделяем и подкидываем им направляем на отдельный пререндер от мтса
Если фронтенду надо двигаться в сторону фуллстека, то не надо ли бекенду тоже двигаться?
Замкнутый круг получается
чисто лайк за классное отношение к ребенку!
Я ток не понял, нафига при таком подходе функции бэка во фронт пихать? Ну рендерятся теперь странички на сервере, дык нехай серверный рендер на бэк апихи ходит, как раньше с браузера ходил.
Я думаю тут логика простая "Почему бы и нет". Каждому продукту нужно выделяться чем-то на фоне остальных. Вот и Next.js выделяется.
Считаю что выбор стека это дело вкуса, а не обязанность каждого инженера бежать за трендами.
Начиная с next 13 начинаешь задумываться о таких вещах как сделать больше серверных компонентов. А из за бекендеров это сделать не возможно просто. История о том как всегда бек всю логику с удовольствием готов скинуть на фронт. Это пагинация фильтрация и т. д. При больших объёмов передачи данных.
Ну по сути как я давно делаю начиная работь с Firebase для не очень сложных web app типа магазина или чата или todo и т.д. отличный вариант для фронтендера без гдлубоикх знаний backend, я пишу сам фронт и юзаю готовый бэк с не реляционной БД. Для экономии времени просто шикарно. Мне больше не нужен server не нужно арендовать сторэдж на AWS "whatever" замарачиваться с аутентификацией и прочее.
Nuxt3 вроде тоже самое имеет? Или что то больше есть в next?
2:20 - я ночью смотрю и я один в квартире. И тут какие-то жуткие голоса. Я аж обомлел.
Анекдот вспомнил: нет ничего прекрасней детского смеха, но только не ночью и только если у вас нет никаких детей
Это как с верстальщиками было, с появлением фреймоворков их становилось всё меньше и меньше, и вот сейчас только крупные компании могут себе позволить держать в штате парочку верстальщиков. Но, думаю, что многие преувеличивают говоря что фронт вымирает и мы потихоньку вступаем в эру фулл стака. Скорее всего, как и было сказано, небольшие проекты будут переходить на такую разработку, а средний и крупный бизнес будет работать по старому
Так когда на клиенте рендерилось, в этом и приэмущество было, что сервер меньше напрягается, пусть сервер крутится на каком-нибудь говно-vps с гигом памяти, а клиент на свое супер компе со 100500 ядрами рендерит сам себе в браузере страницу. А теперь что, обратно в сервер все тащим?
Пишем большой проект на новом app router и, честно говоря, уже столкнулись с массой проблем.
1. Есть четыре вида кеширования, из всех можно выйти кроме одного, клиентского, что есть большим минусом, а единственное решение это костыль
2. Часто бывают баги при билдинге
3. Документация явно недописана
4. Критически не хватает инициализации сторы на сервере для синхронизации данных со сторой на клиенте, в последствии чего, стора на сервере могла бы удалиться.
5. Проблема уже самого реакта, но все же. Реакт не дает возможность передавать пропсы пропсу children (во вью есть такая фича), что могло бы помочь создавать переиспользуемые компоненты
@@niko.frontend на самом деле очень ограничивает это в создании ui-kit(((
и так пойдет
По 5-ому пункту погляди Slot из Radix UI, мне понравился. Узнал о нём из нашумевшой либы shadcn, там много классных фичей в простом исполнении
Всмысле не дает пропсы чилдрену, как минимум контекст, стейт менеджер)
@@eurodoo а если не хочется контекст?) Если хочется сделать степпер reusable без контекста?)
Нормальная PHPизация NodeJS )) И это здорово !
почему просто не юзать директиву USE CLIENT и не писать серверные ui
Есть клиентская платформа на реакт CPA, которая грузит процессор у КАЖДОГО пользователя около 20%. Всего около 400 работников. Я представляю какой мощности нужен сервер, чтобы все это считать на сервере.
Фронт в последние года сильно усложнился. Да еще и меняется с большой скоростью. Но тоже чувствую тенденцию, что фронтенд разработчики станут фулстэк. Это экономически выгодно.
Может, и устаканятся технологии, можно туда же бэкам залезать
это экономически не выгодно так как тебе нужно платить ему зп за 4х а работу он делает в 2 раз хуже и дольше
@@WERWOLION нет, будешь работать за + 30к к зп, фуллстекам зп платят так же как фронту или бэку
@@Александр-ц4ш8х поправка это платят тупым инвалидам лохам, которые согласились работать за еду
@@Александр-ц4ш8хНо работает он в 4 раза медленнее. Чем связка фронт и бек разраб.
Все возвращается на круги своя! Я еще помню времена, когда никаких стеков вообще не было. Был некий "оператор ЭВМ", который должен был уметь все! Сделать полностью сайт и дизайн к нему, поднять сервер и обеспечить безопасность, настроить все компьютеры в офисе, заправить катриджи в принтерах, починить розетку и кофейный аппарат...
😂😂😂😂
Тогда были не кофейные аппараты, а над было разжечь угли под турочкой и в чашке картофеледавилкой насолить кофе)))
Ага,помню я тот дизайн😂 От слова не было там этого слова вовсе,потому что было все максимально упрощено.
да бэкенд дизайнер это будет пушка
Тогда ПК был медленнее современной кофемашины
Разделение, где будет выполняться кол, на сервере или клиенте, это не в некст14, а раньше было сделано!
я скорее всего ошибаюсь, но это очень похоже на Java EE технологию для серверного рендеринга страниц, которая была представлена в 1999 году. поэтому бегите учите джаву пока не поздно )
Звучит подозрительно похоже на Meteor, крайне инновационный (в свое время да) и популярный (нет) гибридный фреймворк.
Не смотрел презентацию Next 14. Но мне кажется автор что-то не так понял про написание бэка и фронта в одном приложении.. Ага, я уже представляю как огромное бэкенд приложение с туевой хучей микросервисов пишется с фронтом в одном приложении. Забавно наверное разрабу получить такое тз где он будет писать и бэк и фронт:D
Я такой:
У SQL появился брат близнец которого зовут - СИКВЕЛ))))
Какой подход вы считаете самым лучшим? Рендер на сервере? Рендер на клиенте? Гибридный подход ?
рендер на рендере
Если есть бюджет - на сервере. Нет - на клиенте. Гибридный если бюджета хватает на пачку сигарет
Для начала это зависит от задач и требований. Если бы было одно идеальное решение, остальных бы не существовало.
что такое сиквал ? Может кто нибудь правильно написать ? Для гугла
Один из вариантов произнесения SQL.
Забыли добавить, что на Next нет проблем с типизацией
Ну бэкенд не ограничивается только запросами к БД, если это не бэкенд какого-то тудутиста условного.
Если на бэке какая-то сложная логика происходит то тут некст сам не справится имхо.
По-моему 99% проектов именно так и работают. Вследствие не совсем понятно, зачем вообще бекендеру деньги платить, если можно это не делать, просто научив фронтендера писать sql-запросы.
@@Гооол-й4ч , ну не sql-запросами едиными:)
У меня есть свой проект на котором бэк ходит на сторонние сервисы, собирает некоторые данные, обрабатывает их, рассылает пуш-нотификации юзерам в приложение на телефон, отправляет мне некоторую статистику и уведомления и много чего еще, что не ограничивается sql-запросами.
Мобилки уже давно так живут) Ток там наоборот большая часть на клиенте.
Это вообще не новая тенденция по возвращению к истокам. Все началось с htmx
😅🤣👌Сам из фронта перешел на back и уже сам фулл стек разраб
Для меня самый большой минус этого всего , опять надо что-то учить , ну почему я не пошел на data engineer , писал бы сейчас таблички и запросы в sql и python (((
Потому что это дичь и скука смертная
@@ivanschekoldin7315 жизаааа ))))
@@ivanschekoldin7315 у меня друг подобной темой занимается, - говорит, что ненавидит работу
согласен. мне тоже не нравится, что нужно каждый день свои знания актуализировать, т.е мы все по сути обречены быть 50 летними дедами-школьниками которые каждый день после раб отки будут сидеть и смотреть, что же там выпустили нового в вротэнде... боже спаси и сохрани души этих клятых грешников, аминь.
Какой классный канал. Надо запомнить
По пункту что форнты не нужны: я фронтенд разработчик и когда устроился в текущую компанию мне стало плохо от того как коряво, плохо, некачественно, на костылях и с очень сложной возможностью поддерживать приложение написан код в нескольких приложениях. Работодатель хотел сэкономить и нанимал фулл-стек разработчиков в разное время, пришло к тому что сейчас большая чать просто переделывается фронтендиром, бекендиром и девопсом. Выводы делайте сами.
Дык живые приложения всегда переписываются.
Один из самых вменяемых моих клиентов даже после того, как я неоднократно объяснял ему, что после завершения проектирования БД и начала работ, добавить новый функционал будет сложнее, если мы заранее не обговорим эту возможность, через пару месяцев активной разработки внёс несколько серьёзных изменений, которые потребовали от меня отказаться от изначальной почти идеально нормализованной структуры БД в пользу быстрых, но корявых решений.
Корявыми решения были только потому, что изначальная структура проекта не подразумевала гибкости там, где она понадобилась клиенту, а эта самая гибкость аукнулась снижением скорости работы, в результате чего пришлось создавать ненужные кеширующие таблицы с дубликатами данных. Всё в итоге заработало быстро, но внутри там местами такой код, за который мне стыдно.
Собственно, в течение последующих нескольких лет я периодически ломал изначальную структуру проекта для внесения новых фишек, которые изначально считались абсолютно ненужными.
И подобная картина наблюдается практически со всеми проектами, которые живут, эволюционируют и приносят реальную пользу своим владельцам. Так что подобная корявость - это скорее норма. Если вы сталкивались в работе с очень крупными общероссийскими проектами, то должны знать, какой там код )
Для работы с БД есть только возможность писать SQL запросы или можно использовать какую-либо ORM, как в том же Nest?
спокойно юзвить prisma
Конечно можно использовать любую ORM
На реакте теперь можно писать SQL и бекендеры больше не нужны! Да, это именно так и работает))
И все это будет писать chatgpt, так что никто не нужен
что мешает писать на вью и бэк делать на вордпресе?
Где эти фронты, которые делают условные 5 страниц и две формы за много денег?
В корпорате) Я как-то делал одну форму месяц за много денег =) правда там было около 300 различных импутов разделенных табами и аккордеонами, плюс значения одних импутов влияли на валидаторы других.
@@Andro500 так же ерунда, составлял списками зависимостей...
Можете посоветовать курсы для изучения next js , жалательно актуальные данные, заранее спасибо
Изучаю его сейчас. Советую тебе смотреть официальную документацию, делать себе заметки. Лучше, если ты начнешь какой-то проект и будешь спрашивать у чат гпт какие-то моменты по настройке next.js. Когда не у кого спросить, очень помогает
@@nikolaibik а какая версия чата, там вроде 4 версия платная
@@PacoOfficial может помочь и версия 3.5. Там, кажется, сейчас в любом случае бесплатно не зарегистрируешься. Но вообще, в телеграме есть разные боты бесплатные (даже с версией чатгпт 4)
Господа фронтендеры, спешу вас огорчить, описанная технология (по крайней мере, как я понял) принесет просто нереально много проблем. Все хорошо будет работать, если сценариев похода в базу будет 5-10, но когда их станет больше 100, отлаживать это станет просто нереально больно! Для средних и крупных проектов нужны очень строгие правила обработки бизнес транзакции, не представляю как это реализовать на данной штуке. Такие проекты просто будут одноразовыми, так как по мере их роста, поддерживать такое будет нереально =( А бизнесу не объяснить опасность, им главное модно и прикольно (нанять 1 человека вместо 2), правда потом велик шанс все это переписать, но уже понадобятся 5 человек...
Получается что для нас разработчиков вполне рабочая схема, делаешь сам, потом двигаешь в проект еще четырех своих друзей
@@thxtalk запишите, пожалуйста, меня в друзья
Погоди чуть-чуть, они еще непуганные, нестрелянные. Пройдет немного времени, они понапилят этого мусора, потом придут ко мне, а я буду сидеть, как Крестный Отец, с сигарой в зубах и говорить: "Ты просишь меня пойти к тебе бэкендом за 3 ставки от рынка, но делаешь это без уважения".
Крупные проекты и так не слезут с рельс бекенд + фронт. А мелким до 100 к пользователей вполне хватит. Да и вообще на мой взгляд next решила просто убрать bff сервера=)
@@moon.trance ++++++
да все будет как и сейчас, запросы разделятся между некст серваком и основным если есть мобайл аппки то будет ток основной, плохо это или хорошо фиг знает))) но то что бизнесу это очень нравится это факт 23 год вообще хайп словили на этой теме, нанять команду взять nextjs и какой firebase или supabase и разработать среднего размера продукт за пару месяцев с этим не поспоришь) лично мне нравится такое развитие событий
Что то простое и нетребовательное. Как только появляются сложные бизнес требования и требования ACID. То сразу мы вернёмся к истокам.
Я подумал что это у меня в квартире пустой кто-то разговаривает,
А с nosql как быть то?!
А что делать если у меня mongodb на бэке?!
вот вроде база базой, но концовка смазанная, а затем ещё и политота, gg
Да, я в таких ситуациях всегда вспоминаю напряженные лица господ бэкэндеров или же фулстаков от бэкэнда, когда они пытаются понять с чем же употреблять это ваш CSS и его производные. К сожалению обычно это заканчивается доказательствами того, что дизайн аля win2000 style это отличное решение и вообще всё выглядит просто улётно, а главное так же замечательно работает и все свои функции выполняет.
да тут даже все фреймворки морально устарели т.к ложат переменные в инлайн код.
т.е фреймворки сегодня должны объявлять css переменные и работать через них.
так что тут ещё фронту нормальной фреймворк лет 40 делать ...
Такой подход фронта и бека в одном проекте еще есть в Rust фреймворке leptos. Многие его хвалят. Было бы интересно посмотреть твой обзор на него)
Зашёл ради кода на превью, а за все 9 минут есть лишь 3 секунды кода, но всё, далее никаких примеров и никаких схем. о_О
Кто вообще такие бэкэндеры? Что они делают? Фронтендеры пилят всё целиком 😂
Лучше не познавать сторону Бэка, говорят там суровые дворфы копаются😊😊😊
@@mitivil1134 если перевести слово dwarf - карлик, гном - то уже как бы и не страшно
разве что в вебе
@@fngringio есть NodeJS )
Если это не сарказм, напишите на фронте кластерный брокер сообщений хотя бы, ну или почтовый сервер :)
все новое хорошо забытое старое )))) но я рад этому.
Thank you for your expertise ❤
"30-40 открытых вкладок..." Ха! У меня менее 300-500 вообще не бывает 😂
утечки памяти? не не слышал
@@un_defined Chromium уже давно подчищает память.
Я как бэкэндер могу сказать, что фронт для меня лично ад. Ну нет у меня чувства прекрасного и все тут)
Ад даже девопс хотя казалось бы тоже на серверах настроен и выполняется. Про фронт вспоминать страшно. Я иногда захожу на дейлики коллег которые пишут проект с UI и такой: как же хорошо что этогл гемора в моих сервисах и лямбдах нет ❤
За прекрасным к дизайнерам. Для нормального ентерпрайз приложения бутстрапа за глаза хватает.
Да натянул material и хорош.
Я, если честно, всегда думал, что любой фронт-эндер стремится к фулл-стеку, как и бэк-эндер. Вилка больше, понимания больше и все вытекающее.
Часть из тех _офисных бездельников,_ с которыми я сталкивался по работе, стремились скорее к домашнему уюту: любимому креслу, приставке, телевизору, лодке, гамаку, и т.д.
И это не удивительно, ведь когда твои основные финансовые "хотелки" закрыты, а работаешь ты за время, а не на результат, то вполне естественно, что у тебя не будет сильной мотивации к развитию.
Сам помню, что когда торчал в офисе много лет назад, хоть и развивался, но делал это заметно медленнее, чем "на воле". В офисе много отвлекающих от обучения факторов + основная задача - исключительно то, что нужно выполнить по работе. А на вольных хлебах твоя основная задача - быть максимально эффективным и разносторонне развитым, иначе клиент уйдёт к другому специалисту.
Нагромождение фреймворков есть следствием удешевления и ускорения разработки. Я думаю с внедрением и улучшением ИИ, фреймворки просто вымрут. Роботы смогут текстовое описание проекта превращать в нативный высокопроизводительный код html + css + js без паразитных надстроек.
А вы уже пробовали Locofy AI?
Судя по видео и обзорам это весьма неплохая штука. Если будет прогрессировать так же, как и другие инструменты с применением машинного обучения, то через годик-два веб-разработка начнёт замечать грядущие масштабные изменения в IT отрасли...
Еще проблема бекендеры не любят FP. А любят ООП. Фронтенд уйдет в фулстек. Когда говоришь любому беку что его можно легко заменить. То он сильно обижается. А на js очень сильно обижены бекендеры.
Бэкенд это не просто отдать апи на фронтенд, это еще и фоновые задачи, различные базы sql/nosql, кубер, транзакции, саги, микросервисы, и тп. задачу забрать данные из простого хоанилища фулстек заберет не проблема, но то что скрыто под водой айсберга нет
Как фронтендер, со всем согласен❤🎉❤🎉
Такой вопрос, немного не по теме! Было несколько сайтов на укозе. Сейчас все заблокировано. Есть ли бесплатная Западная альтернатива? Чтобы на конструкторе сделать свой сайт и туда загружать свои материалы и чтобы хостинг был бесплатный. Несколько лет подряд укоз навязывал хостинг за 74 доллара....
а кто тебе бесплатно хостинг давать будет? Сервера люди же покупали не что бы бесплатно тебе раздать
А почему на укозе было бесплатно?@@Aleksey-n5h
А вам не кажется, что таких слоев абстракций уже намешали - только ради денег - усложнили тоже ради денег (дай угадаю за поддержку денег берут). Ходят по кругу не знают что еще придумать, ради бабосиков. По моему скромному мнению 90-95% задач решается проверенными технологиями. У нас же в каждом дворе по НЕТФЛИКСУ и АМАЗОН.
Ухты, как в старые добрые времена: - "Ты кем работаешь?" : - "Я работаю вебмастером": - "Ооо, правда что-ли, тогда можешь сделать мне сайт под ключ по-дружески?"
Миш, у тебя макбук 14. Мог бы ты выпустить ролик с обзором, какое разрешение, норм ли влазит контент с открытыми вебтулзами. Вообщем глазами веб-разработчика, чтобы понять подходит 14ый дисплей или нет
Я знаю как минимум 5 ребят которые работают на 13 дюймовых эйрах и им всё ок. Я не могу так работать, мне например и 16 мало. Так что это всё вкусовщина.
Мне 14 терпимо, коллега на 13 работает в кайф, а моя жена (автотесты пишет), так ей 16 дюймовый как минимальное требование. Вкусовщина и восприимчивость глаз. Но по сути, 4к на 14 дюймах уже сложно читаем. Я 2048*1330 использую, но бывает покрупнее делаю.
Чувак 14мау бук про на м2 это лучшее что у меня было за последние время)) это просто топ топчанский я хотел купить один 14, а второй 16 чтобы сравнить их, но после 14 я купил второй 14 потому что 16 слишком большая
14 дюймов идеален для разработки. Веб тулзы для правки стилей каких-то не то чтоб прям супер удобно (супер удобно это когда на разных физических мониторах разнесено), но вполне терпимо, за счет плотности пикселей можно масштабировать изображение и всё равно комфортно работать. 16 точно как рабочая лошадка не пойдет, слишком громадный
теперь нужны более мощные фронтендеры
Лайк + подписка!
На Postgres доку читали? Там куча всего! Бэкапы, версионирование,права, миграции.... Ещё и логики куча. На сервисы всё разбивать? Потом di придумают в компоненты😂.
А если фронтам еще рассказать про транзакции и уровни изоляции, про индексы, про шардирование и партицирование, то у них ваще пена изо рта пойдет)
@@Longmanrus , блин, расскажи, давай проверим. Индексы это у массивов что-то, да? Я в них просто тоже не очень, мы обычно на фронте работаем с такими технологиями, как и , в чём-то большем разбираться не приходится.
Какие же бекендеры в коментах мерзкие, с чего вы вообще решили что чуть ли не все лучше всех могете, чуть ли не каждый высерает что то в духе -'я за секунду выучу все фреймворки + могу еще и свои создать если надо' Кмон в 2023 году живем и фронт уже куда обширнее и сложнее стал, ибо все ударились в оптимизацию, нахуя приводить в пример лендинги одностраничные которые вообще на конструкторе клипают, я не понимаю.? Чел на авторе вообще шизоид и каждый видос у него КАТАСТРОФА для мира фронта. Про алгоритмы на бэке вообще смешно слышать...
та они судят по фрейморку\библиотеке одной, забывая, что фронт - это браузер. Браузеров херова туча, куча версий, говноIE. И вот тут все начинают жрать говно, когда на макос работает норм, а на винде повляется скролл и все едет по п...е)) Так же забывают про адаптив, accessibility. Почему-то все смотрят на реакт в вакууме, а это всего лишь инструмент для работы с любимым DOM)
Только перекатился с Java во фронт - а фронт уже "всё"... )
Подскажите новичку, что нужно учить после React, RTK и TS? Стоит ли начинать Next или до него желательно ещё что-то знать?
angular
@@pawmax1286 Разве это не аналог React?
@@arthurq7843 Даже не близко
Вы же видео смотрели? SQL.
Ищи работу
Мне кажется или Vercel пытается убить Next чтобы люди начали смотреть на SvelteKit?
Как раз перешёл на проект с Nextjs, актуально, спасибо! Но перед этим работал на проекте где заказчик строго разделял бэк и фронт. На каждого свои разработчики. Не думаю что из-за next фронты останутся без работы
а помнитте как вопрес и тильда закончили эпоху фронтенда
@@WERWOLION Я поооомню)
ucoz
@@WERWOLION Можно по подробнее?
Стандартизированый фронтэнд - да, вымрет. Но, уникальные решения и разработка новых интерфейсов, либо сложных анимаций, webgl и прочего смежного с дизайном - нет. Я видел как бэкеры работают с домом, оптимизацией и UX. Мне про вёрстку в 10 году году говорили что я мамонт, в итоге люди не могут папап анимаровать нормально без библиотек. Решаю сложный уникальный интерфейс создавая библиотеку стилей за 5 дней. Кто-то писал про GPT - будете дольше промты писать чем я создам поддерживаемую архитектуру
Только для простых сайтов подойдет
Не страшно. Фронтендеры прогнутся под работадателей и станут оверфулстек
Я так понимаю недовольны все фронтендеры и бэкендеры, кроме фронтов, которые пишут на react
А если бэк на Java и api это бэка кроме вэба ещё и мобильные приложения дёргают?
Да и на серьёзном проекте никто фронтов к бэку не подпустит - имхо чисто для малобюджетных простых проектов с исключительно веб интерфейсом.
Хз почему бэкендеры в комментах радуются. Ты как-то неправильно интерпретировал. Такие фулстэк приложения пишут как раз фронтендеры, обходясь без бэкендеров. По сути они отбрасывают надобность найма командны профессиональных бекендеров, уменьшая затраты компании. Что как раз хорошо для бизнеса. Если мир пойдет по направлению nextjs, проблемы возникнут у большинства бэкендеров. Фронтендеру не трудно перейти с того же реакта на Некст. А вот типам, пишущим на других языках, будет не легко познать джава скрипт
Надо еще в архитектуру уметь, а это даже не все бекендеры умеют. Для большинства фронтендеров это вообще набор непонятных звуков.
Удачи. Пишите SSR приложения и побольше. Потом можно будет переписать за двойной, а то и тройной ценник.
"Такие фулстэк приложения пишут как раз фронтендеры, обходясь без бэкендеров. По сути они отбрасывают надобность найма командны профессиональных бекендеров, уменьшая затраты компании", сразу видно гуманитария) погугли что такое чел/час
Пока существует html, css, фронтендеры никуда не денутся
Вы уже испытали сервис Locofy AI?
Просто у меня есть ощущение, что благодаря развитию подобных сервисов, спрос на фронтендеров начнёт снижаться :/
Угораете бекендеры фронтенд. У меня на работе бекендеры бояться фронтенд как огня.
ну, кроме страниц где нужно SEO есть еще очень много приложений где нужны и фронты и беки, и бек JS'ом не заканчивается, но да, делать сайт на PHP и быть фулстеком проще, чем быть бекендером на Java, Go и т.п. и быть фулстеком сложнее. Мне кажется % бека на Node сейчас все равно еще очень и очень мизерный, чтобы об этом как то серьезно говорить, чтобы фронты двигались в сторону бекенда. Могу ошибаться, но ощущения примерно такие.
Смешно 😂
Я всегда говорил, что реакт не торт, впрочем, как и всё детище лицокниги.
Извинись
SSR как кастыль, впрочем и javascript фреймворки появились от нежелания вчитываться в спецификацию языка.
Javascript воистину самый непонятый ЯП в мире программирования. Даже у php куда лучше дела чем у js.
Очень забавно, что вернулись к проверенной временем парадигме:
«На сервере вычисляем, а на клиенте отрисовываем данные.»
Подрядчик может заблуждаться, но не карман заказчика. Потому благоразумие возьмёт рынок и время верно расставит акценты.
про php кринжанул. да и про "костыль" SSR. Это все логичные действия для seo, по другому никак
Раньше ученые или просто талантливые коллективы создавали языки и технологии.
Прорабатывалась концепция и все работало. А сейчас миром программирования (веб больше всего пострадал от этого) правят "хипстеры" с их "вейпами", "барбершопами", и прочей ересью. А потом случаются разного масштаба "хайпы", которые потом становятся мейнстримом... и попробуй отказаться от мейнстрима.
Да нет, просто сейчас все хотят с минимумом затрат что-то получить. Собрать как конструктор. И что бы один человек им все это сделал.
Поэтому придумывают всякую хрень.
В идеале вообще писать с нуля без всяких фреймворков и лишней лобуды. Она не нужна.Тогда сайт получается легкий, грузится моментально.
Аяксом только динамически изменяемые данные передавать в JSON по минимуму, а не все подряд с огромными кусками html, css.
Все ссылки можно сделать без перезагрузки и т.д.
И тогда при 200 000 уников в сутки и более сайтик может работать на самом простом хостинге за 500 рублей в месяц. И никаких проблем не будет вообще.
У меня такое чувство что эти все разработчики специально создают всякие идиотские геморойные технологии, что бы у людей постоянно возникали с ними проблемы и они вновь и вновь искали пути их решения. Такое чувство, что не упрощают они жизнь людям, а усложняют.
бл, ну тут с первой секунды дропнуть видос только) почему этот чел думает, что такой контент это живо и круто
фронтенд стал простой, ага)
Куда катится этот мир, реакт таким образом заставил сантехника так же строить дом, а эти задачи уже не посильны одному человеку
Да ладно вам, в самом ReactJS нет ничего сложного. Сложности созданы (и продолжают создаваться прямо сейчас) искусственно - это частые обновления мажорных версий и применение React там, где легко можно обойтись простым VanillaJS.
React ведь не привнёс в Web ничего нового. Всё, что можно на нём реализовать, раньше без проблем создавалось на чистом JS.
О каком бекенде может идти речь если ни базы ни апи не сделать? Это лишь подготовка фронта на сервере не более того. Запросы просто идут через прокладку еще одну серверную на нормальный бэк. Без этого полноценного приложения с отправкой и сохранением данных не построить, только статику.
А если допустим cUrl нужен? или еще какая-нибуть библиотека из php тогда что? все пропало?
Я как фронтедер пришедший из бэкэнда могу смело заявить, что фронт никак не проще, а местами даст просраться бэкенду.
Конечно. Фронт куда сложнее. Из за того что там все время все меняется..
А почему решили перейти во фронт? Я вот думаю наоборот свитч сделать
@@sanek1985t я перешел во фронт, когда он только появлялся как отдельное направление, тк мне казался модным, бэк мне больше нравится)
но на нексті в нас є вибір, ми можем зробити щоб всі компоненти були клієнськими
видео чистой воды кликбайт
Почему?
Миша, ты рассуждаешь с точки зрения что использовать JS - это нормально, я тебе скажу как Java dev - это не нормально, это страдание, все на фронте сложно не потому что фронт сложный как сфера, а потому что JS убог как и Meta со своим реактом. Если говорить в общем, то по мнению 95% бэков JS - это полное убожество, не может вся web индустрия вот так вот переползти полностью в JS, хотя-бы потому что он интерпретируемый, не говорят уж про его убогий синтаксис, не будут все жрать кактус и становиться фуллстаками на основе JS фреймворков.
это коммент нейросети? что за дичь и бред? синтаксис js аналогичный со многими языками, бэкэнду бы уже php выкинуть, убогий мусор с его долларом
Да синтаксис это херня все. Сам язык и платформа не проработаны изначально.
да да TypeScript не слышал?
Очередной способ, разрабам убедить бизнес "нам нужны деньги, мы снова будем все переписывать, а все что было написанно ранее, это легаси " Дайте денег))
nuxt быстрее работает чем next
React не куда не делся. Нытик - ещё один типаж, от которого надо держаться подальше.
Полностью согласен, все так и есть, нахрен ты не нужан уже сейчас если ты не умеешь аут и дергать бд с неста или експреса.