🔗 Ссылки: Qwik: qwik.builder.io/ ⚡Курс по React и Next с SSR: purpleschool.ru/course/nextjs Мои курсы по разработке: purpleschool.ru Telegram канал с полезными советами: t.me/purple_code_channel
Nice coverage, still had to point out a little detail that devs at Qwik made clear about the SSR: because of Qwik's design, its components can be rendered in parallel, making the server side rendering even faster than that of comparable libraries and frameworks.
А где нытье «новая версия джавы! Перестаньте их клепать». Фронт развивается, меняются задачи, появляются новые идеи как эффективнее решать старые. А вы, видимо, были бы счастливы если бы мы на перфокартах остановились
А если немного переработать график загрузки АПП как в начале. Встроить весь js, css и данные (что бы не делать запрос к апи после инициализации АПП) в сам html? Скорость по сравнению с ССР будет практически идентична и интерфейс сразу интерактивный т. к. ненужна догрузка бандла
Спасибо за видео! Это выглядит интересно, странно, не надёжно (нажимать обычную кнопку и надеяться что сервер, интернет не подведёт). 1. В чём его преимущество перед nextjs? Снижение нагрузки на сервер по объёму, но увеличение количества запросов многократно? 2. Интересно было бы посмотреть как он обработает всплытие модального окна (mui + frame motion), неужели не будет заметной задержки. Если смогу сам попробую
Кэширование конечно поможет, но UX для пользователей, которые посещают сайт (или взаимодействуют с какой-то его частью) в первый раз, может быть не самым лучшим. С другой стороны, возможно (я точно не знаю, не смотрел еще) в Qwik есть возможность принудительно подгрузить чанки, когда определенное действие пользователя только ожидается, например при ховере на кнопку. Было бы здорово, если такое есть
@@СамирАбасов Ну NextJS там не получается, это все-таки совсем другой фреймворк. И если честно, ваш комментарий выглядит, как претензия к Qwik, что он не поддерживает React библиотеки (может быть я ошибаюсь конечно, поправьте, если это не так). Да, не поддерживает, что в этом такого? Вы же не ожидаете, чтобы Angular или Vue будет поддерживать React библиотеки, верно?
видео зашло, смотрел второй раз на счет архитектуры fullstack когда делаешь маленький проект, то лучше fullstack если делаешь один, то лучше fullstack конечно когда приложение будет рости, то можно все переделать, ведь важно получить MVP как можно быстрее и вроде здесь нет vendor lock можно деплоить на разные сервера. сейчас для России это особо актуально
Видео понравилось, а сам фреймворк не очень. Идея запрашивать на каждый чих маленькие кусочки кода с сервера - так себе на мой взгляд.)) Мне пока нравится больше, когда толстый клиент и тонкий сервер (а ещё лучше, когда клиент работает автономно без сервера, а с серверном иногда синхронизируется по желанию пользователя :).
Толстый клиент дает нагрузку на слабые устройства, это минус. Да и бизнес логику валидировать все равно можно только на бэке, так как клиент полностью доступен для модификации. Я больше за SSR, но загрузка на каждый чих тоже имеет свои недостатки.
@@PurpleSchool Да, я всё это понимаю. Просто у меня сидит внутреннее желание, чтобы что-то было придумано так, чтобы всё максимально было автономно и работало без сервера (в тех случаях, когда это возможно). А вот по поводу того, что толстый клиент даёт нагрузку на слабые устройства. Если устройство слабое, то чаще всего и интернет соединение оно поддерживает слабое (например, мобилки с 3G). Я просто часто замечаю, что на моей старой мобилке всех больше тормозов происходит именно тогда, когда идут запросы к серверу, приходится ждать по 10-15 секунд ответа на каждый запрос со слабым интернетом и любоваться лоудером или скелетонами. А приложения, которые все данные разом загружают на клиент, работают на ней, ну, раз в 10 быстрее тех, которые часто обращаются на сервер за получением данных.
А не будет ли глюченный интерфейс из за того что на каждый чих загружаются микробандлы? Отзывчивость интерфейса сильно страдает из за этого... Не кажется ли что лучше пускай на несколько миллисекунд дольше грузится апликейшен, зато потом все летает и интерфейс супер отзывчивый ?
@@PurpleSchool по идеи обычных компонентов с динамическим импортом должно хватить. А грузить каждую мелочь это как то дико... Особенно это нахрен не нужно если делать десктоп приложения
@@PurpleSchool которое бывает случается очень часто… Я вот пожил с херовым интернетом полгода и понял, как важна оптимизация и минимизация всего, чего только можно. С плохим интернетом с некоторыми сайтами работать становится просто невозможно. Пока жил с хорошим интернетом, даже не задумывался об этом.
Пишешь ты такое приложение, которое грузит все что нужно только по требованию, а потом приходит бизнес и говорит: "чего-то у нас долго отклик в интерфейсе при первом нажатии, клиенты недовольны" и начинается... надо значит префетчить все, что используется и вот уже приложение на qwick ничем не отличается от аналогичного на реакте или на ангулар.
класс! спасибо за introduction в новую прорывную фронт-энд технологию. вопросы: 1. есть ли смысл использовать qwik вместе с htmx 2. когда ожидается ознакомительное видео о next.js 14?
@@PurpleSchool 1. можно пожалуйста поподробнее (буквально одним - двумя предложениями) о разнице, в чем она? 2. спасибо, ждем-с ) 3. можешь пожалуйста запилить ознакомительное видео о qwik, в том числе о его разнице (в подходах и технологии) с next 14?
Вы очень хорошо обьясняете, видел ваши курсы по бэку на ноде, хотел спросить, некоторые говорят, что по ноде js nest express для джунов мало вакансий, реально ли для джуна найти работу бэкенд на ноде? И как вы считаете, за 6 месяцев интенсивной учебы реально отучится на juna?
Спасибо! Да, nodejs используется по многих компаниях. А насколько можно отучиться, очень зависит от вашего желания и упорства. В курсах и в профессии даётся в целом всё необходимое: purpleschool.ru/profession/backend
зачем Qwik, когда это всё уже есть, либо появится с ближайшими релизами в Next и его поддерживает команда фэйсбука? Зачем учить то, что ещё не популярно и на него нету вакансий на рынке, но за ознакомление спасибо.
Хотелось бы совета. Я работаю в большом проекте уже 3 года, используем реакт. И как то я засиделся. Вдруг пришло осознание что я ужасно отстал от новых технологий. Какой фреймворк можете посоветовать, чтобы начать его изучать на своих пет-проектах? Пока глаз упал на Некст жс.
Имхо, спорное решение. Да, сэкономили на бандле (не так уж и много). Но бандл - один запрос, один хендшейк, один ответ. Если клиент с 3g или нестабильным интернетом - он сможет загрузить бандл в 500 КБ (пусть не с первого раза) и пользоваться приложением (в целом), а если на каждый клик будет запрос и рандом - нервы только испортит. Ну да ладно, если интернет хороший, то ок. Но у многих ли он хороший? В отдалённых от цивилизации местах до сих пор рулит спутниковый интернет с пингом 400-500 мс. Как при таком пинге работать с квиком? На каждый тык мышью придётся ждать ответа. При этом, противопоставлю фреймворки - пинг 500 мс ты подождёшь один раз, а потом с отличной скоростью тебе залетит всё, что надо для SPA. Принимая это во внимание, получается, что QWIK не такой уж и QUICK и очень зависим от качества соединения клиента. А если клиент, который не знает, что там под капотом, ткнул кнопку раз/два/три - он с 90% вероятностью обновит всю страницу целиком. Что-то из кэша будет, но всё равно тут мы выигрыша от квика не получаем.
Мысли в текст: если они решили пойти таким путем, то почему бы не организовать под капотом транспорт на по http а через ws между своим клиент-сервером? Так задержки на загрузку фрагментов были бы заметно ниже, а если разорвалось соединение это можно было бы обработать и отобразить что-то пользователю, сообщить, что с интернетом проблемы.
Спасибо, замечания справедливые. Если соединение не очень, то мы получаем возможную просадку в отзывчивости и иногда race condition, что может быть проблемой. Думаю что можно было бы решить постепенной загрузкой всех компонентов на странице в фоне, при этом так же частями.
@@PurpleSchool Да, хорошая идея. Приоритезация (+ управление ей) и неспешная загрузка в фоне - было бы хорошим решением. Разработчик вполне может предположить, что в каком порядке загружать. Обработчики какой-нибудь формы контактов в футере можно в последнюю очередь загружать.
Зачем выполнять фронт на бэке? А если будет выводиться таблица на 100 строк по 3 кнопки в строке, то на каждой кнопке будет запрос на бэк чтобы получить JS клика по кнопке? Тоесть мы грузим JS, в котором код запроса к REST API, его выполняем, снова идет запрос.... А если на ответ от рест АПИ нужно обновить стейт и срендерить блок, то снова запрос?
Хотелось бы увидеть в реальном мире, все же один из плюсов который мы получили по сравнению с дедовским подходом - быстрый отклик, потому что все приложение загружается сразу, если каждый клик будет грузить пару строчек кода, не будет ли это минусом. Размер скриптов после solidjs великоват, раз в 8 больше, еще и не все сразу грузится.
абсолютно верная догадка, полностью с ней согласен. Пререндер наше всё. Браузеры уже прекрасно доработаны под толстые клиенты. Я за тонкие клиенты, но это полная клиника. А если сеть у человека упадёт? А если она просто херовая? А что с состоянием? Я на каждый обработчик лоудер должен вешать, чтоб дать человеку понять в случае тупняка что что-то происходит? А откуда лоудер появится? Его тоже грузить? А не проще один запрос на всё с клиента послать, чем забивать втупую канал передачи кучей мелких запросов, да там одних метаданных будет больше чем самих данных. Короче очередной бесполезный фарш, ещё и на vite, боже, уберите с глаз долой и закопайте в цинковом гробу
@@oWeRQ666 да, он очень быстро выкидывает ошибки сборки, не успеваешь понять почему, а он уже сообщает о весёлом вечере. Особенно весело когда сборка прошла, а доступы к объектам в браузере говорят об обратном. Тогда время не то что на кофе, на пассать сходить покажется роскошью. И у тебя явно что-то не так с компьютером, если вебпак собирает тебе бандл дольше, чем ты хотя бы налить себе кофе успеваешь. Ну минута это край, для очень жиного клиента. Никто кроме дибилов страдать от неполноценности vite ради мнимой экономии минуты не будет
@@nickythecasper4314 Не сталкивался с проблемами доступа к объектам, хотя микс esbuild и rollup конечно выглядит не очень надёжно. Что касается времени на сборку, судить надо не по компу, а по проектам, внезапно у некоторых они большие и время сборки приличное.
Этот "новый" подход возвращает старые как мир проблемы от которых вроде бы только недавно избавились когда всё приложение скачивается одним бандлом. Помню ещё лет 10 назад встречалось что жмёшь на кнопку в приложении а реакции нет, это потому что скрипт который содержит обработчик ещё не докачался и не навесился. Это просто ужасный UX который потенциально ведёт к огромному количеству отвалов у клиентов с нестабильным подключением. Получается что эта проблема UX как раз та самая основа на чём построен этот "не очередной" фреймворк, да и идея не нова если вспомнить code-splitting вебпака и react.lazy, но тут в чанк кладётся даже 1 функция, и это в век гигабитных подключений)))) А вот на медленном 3G приложение на Qwik скорее превратится в настолько Slov что приведёт к огромному количеству негативных отзывов.
Замечание верное, поведение с нестабильным подключением действительно будет не очень. Но думаю это не последний их шаг и можно улучшить концепцию и грузить в фоне кусочки.
Если нужно что-то серьёзнее туду приложения то 100% не стоит тащить туда логику бэка. Но вот выполнять в серверных функциях всякие расчёты, сериализации для бэка по моему самое то. Считай прямое разделение бизнес логиики и ui. Мне кажется это норм
@@PurpleSchool а если будут нужны чпу-url, при этом часть из них должна формироваться динамически? Это ж прям любимая тема сеошников и боль для разрабов. А вот с таким "удобным" подходом похоже что никак.
Очень даже работает, так как я сам любитель SEO, много раз делал. Динамические сегменты реализуются через [name]/index.tsx. В name как раз будет динамический сегмент, который можно получить в коде и описать варианты принимаемые.
Да хватит уже этого зоопарка, не ну серьезно, у нас и так есть 3 основных для фронта которые более менее стабилизировались, на бэке все начинает прояснятся… а тут снова началось: то svelt, то solid, то еще там какой очередной новый фреймворк…. А вы говорите еще этот quick вводить в продакшен, будто и без него голова не кругом Лучше как мне кажется совершенствовать существующие фреймворки а не клепать и плодить стек
Каждый новый фреймворк - это шаг в развитии Frontend. Если его идеи буду эффектными, их могут к себе затащить и крутые игроки, как например стало с Signal.
@@PurpleSchool так может лучше именно развивать все существующие? Signals добавили в Angular-16 это круто, можно ведь и дальше развивать существующие платформы это и будет шагами вперед, то что вы предлагаете это плодить хаус и головную боль. На счет технологий фронта - все сегодняшние основные столпы (angular react vue) основаны и берут начало из angularJS и неплохо продвигались… Новое это хорошо(!) развитие это тоже хорошо(!) но нужна разумная интеграция а не создание зоопарка
@@VS-nq1ro Наоборот, зоопарк нужен. Всякие новые решения во фронтенде развивают и стабильные продакшн решения, спустя время самые нужные и рабочие фишки будут протекать в большие фрейиворки и тем самым улучшать их. Например, solidjs сделали сигналы, всем понравилось и теперь все хотят сигналы во вью и реакт, завтра qwik сделает какую то супер удобную фишку и все захотят её в реакт, вью, ангуляр. И т.д. Так что весь зоопарк фреймворков и библиотек это наоборот круто. Все с друг другом конкурируют и заставляют развивать и улучшать свои инструменты. По этому фронтенд современный и разный, на любой вкус и цвет
@@izzy7541 то что вы описали условно разделяет стек на два вида: Для прода и для пет проектов и им подобного. Тогда полностью согласен, есть стек который улучшается, который стабильный и на котором держится прод и есть испытательный стек из которого лучшие фичи выстраиваются в первый. Такой подход хорош, я же имел ввиду что не нужно стек второго типа превращать в стек первого (пилить прод на нем)
@@PurpleSchool одни заблуждения, csr индексируется, клиентский рендеринг быстрее серверного т.к. выполняется все на устройстве и нет задержки от сервера, современные устройства, особенно мобильные обладают более высокой производительностью js, чем пк и соответственно в несколько раз быстрее, чем серверные процессоры.
@@PurpleSchool csr может подгружаться частично (только требуемая часть приложения). Загруженный бандл храниться в кеше и очень редко приходится загружать его повторно.
@@PurpleSchool ну и забыл добавить, что ssr это очень дорого. js не отличается высокой эффективностью поэтому нам нужны тысячи нод и даже десятки тысяч. В CSR достаточно cdn и высокопроизводительного сервера с api
@@PurpleSchool рынок может идти куда угодно, нужно просто видеть будущее. А тут все явно не на стороне ssr, сео - пофиксят. Мобильные чипы с производительностью десктопных - появятся во всех устройствах и нижнего сегмента.
🔗 Ссылки:
Qwik: qwik.builder.io/
⚡Курс по React и Next с SSR: purpleschool.ru/course/nextjs
Мои курсы по разработке: purpleschool.ru
Telegram канал с полезными советами: t.me/purple_code_channel
Такое впечатление, что где-то есть нейронная сеть, которая клепает фреимворки и заливает их на npm каждые 2-3 дня😅
А это идея для стартапа 😂
нравится твой спокойный стиль повествования )
Спасибо!
@@PurpleSchool пару аудио-сказок "детям на ночь" начитай. отлично получится =))
Nice coverage, still had to point out a little detail that devs at Qwik made clear about the SSR: because of Qwik's design, its components can be rendered in parallel, making the server side rendering even faster than that of comparable libraries and frameworks.
Очередной фреймворк... Перестаньте их клепать 😮😢
Тут отличие больше есть от других фреймворках.
Это очередное говнище, как и реакт
Ахахахаз))
Лично я ни одного не сделал 🤣
А где нытье «новая версия джавы! Перестаньте их клепать». Фронт развивается, меняются задачи, появляются новые идеи как эффективнее решать старые. А вы, видимо, были бы счастливы если бы мы на перфокартах остановились
А если немного переработать график загрузки АПП как в начале. Встроить весь js, css и данные (что бы не делать запрос к апи после инициализации АПП) в сам html? Скорость по сравнению с ССР будет практически идентична и интерфейс сразу интерактивный т. к. ненужна догрузка бандла
если речь про inline, то такое кешировать не будет
Спасибо за видео! Это выглядит интересно, странно, не надёжно (нажимать обычную кнопку и надеяться что сервер, интернет не подведёт). 1. В чём его преимущество перед nextjs? Снижение нагрузки на сервер по объёму, но увеличение количества запросов многократно? 2. Интересно было бы посмотреть как он обработает всплытие модального окна (mui + frame motion), неужели не будет заметной задержки. Если смогу сам попробую
Я так понимаю - чанки можно закешировать на уровне nginx/traefik
Да, можно кэшировать для скорости. Я бы брал его для экспериментов на сайт где нужен SSR и быстрый рендеринг.
Кэширование конечно поможет, но UX для пользователей, которые посещают сайт (или взаимодействуют с какой-то его частью) в первый раз, может быть не самым лучшим. С другой стороны, возможно (я точно не знаю, не смотрел еще) в Qwik есть возможность принудительно подгрузить чанки, когда определенное действие пользователя только ожидается, например при ховере на кнопку. Было бы здорово, если такое есть
@@fadilmamedov2844 Если подгружать заранее какие то чанки, то это получается nextjs, который в отличии от qwik поддерживает все библиотеки для react
@@СамирАбасов Ну NextJS там не получается, это все-таки совсем другой фреймворк. И если честно, ваш комментарий выглядит, как претензия к Qwik, что он не поддерживает React библиотеки (может быть я ошибаюсь конечно, поправьте, если это не так). Да, не поддерживает, что в этом такого? Вы же не ожидаете, чтобы Angular или Vue будет поддерживать React библиотеки, верно?
видео зашло, смотрел второй раз
на счет архитектуры fullstack
когда делаешь маленький проект, то лучше fullstack
если делаешь один, то лучше fullstack
конечно когда приложение будет рости, то можно все переделать,
ведь важно получить MVP как можно быстрее
и вроде здесь нет vendor lock
можно деплоить на разные сервера. сейчас для России это особо актуально
Спасибо
@@PurpleSchool ua-cam.com/video/dc6mUwXnyqE/v-deo.html автор поясняет решения
Видео понравилось, а сам фреймворк не очень. Идея запрашивать на каждый чих маленькие кусочки кода с сервера - так себе на мой взгляд.))
Мне пока нравится больше, когда толстый клиент и тонкий сервер (а ещё лучше, когда клиент работает автономно без сервера, а с серверном иногда синхронизируется по желанию пользователя :).
Толстый клиент дает нагрузку на слабые устройства, это минус. Да и бизнес логику валидировать все равно можно только на бэке, так как клиент полностью доступен для модификации. Я больше за SSR, но загрузка на каждый чих тоже имеет свои недостатки.
@@PurpleSchool Да, я всё это понимаю. Просто у меня сидит внутреннее желание, чтобы что-то было придумано так, чтобы всё максимально было автономно и работало без сервера (в тех случаях, когда это возможно).
А вот по поводу того, что толстый клиент даёт нагрузку на слабые устройства. Если устройство слабое, то чаще всего и интернет соединение оно поддерживает слабое (например, мобилки с 3G). Я просто часто замечаю, что на моей старой мобилке всех больше тормозов происходит именно тогда, когда идут запросы к серверу, приходится ждать по 10-15 секунд ответа на каждый запрос со слабым интернетом и любоваться лоудером или скелетонами.
А приложения, которые все данные разом загружают на клиент, работают на ней, ну, раз в 10 быстрее тех, которые часто обращаются на сервер за получением данных.
А не будет ли глюченный интерфейс из за того что на каждый чих загружаются микробандлы? Отзывчивость интерфейса сильно страдает из за этого... Не кажется ли что лучше пускай на несколько миллисекунд дольше грузится апликейшен, зато потом все летает и интерфейс супер отзывчивый ?
Может быть при плохом соединении
@@PurpleSchool по идеи обычных компонентов с динамическим импортом должно хватить. А грузить каждую мелочь это как то дико... Особенно это нахрен не нужно если делать десктоп приложения
@@PurpleSchool которое бывает случается очень часто… Я вот пожил с херовым интернетом полгода и понял, как важна оптимизация и минимизация всего, чего только можно. С плохим интернетом с некоторыми сайтами работать становится просто невозможно. Пока жил с хорошим интернетом, даже не задумывался об этом.
Новый способ устроить DDos. Нажать на все кнопки разом
😂😂😂
ну прикольно.. посмотрим через годик .
Пишешь ты такое приложение, которое грузит все что нужно только по требованию, а потом приходит бизнес и говорит: "чего-то у нас долго отклик в интерфейсе при первом нажатии, клиенты недовольны" и начинается... надо значит префетчить все, что используется и вот уже приложение на qwick ничем не отличается от аналогичного на реакте или на ангулар.
класс! спасибо за introduction в новую прорывную фронт-энд технологию. вопросы:
1. есть ли смысл использовать qwik вместе с htmx
2. когда ожидается ознакомительное видео о next.js 14?
Спасибо
1. Нет, это два разных подходов
2. В течение 1-2 Надаль
@@PurpleSchool 1. можно пожалуйста поподробнее (буквально одним - двумя предложениями) о разнице, в чем она?
2. спасибо, ждем-с )
3. можешь пожалуйста запилить ознакомительное видео о qwik, в том числе о его разнице (в подходах и технологии) с next 14?
@@ashimov1970 они оба фреймворка, каждый из которых работает по своему.
Вы очень хорошо обьясняете, видел ваши курсы по бэку на ноде, хотел спросить, некоторые говорят, что по ноде js nest express для джунов мало вакансий, реально ли для джуна найти работу бэкенд на ноде? И как вы считаете, за 6 месяцев интенсивной учебы реально отучится на juna?
Спасибо! Да, nodejs используется по многих компаниях. А насколько можно отучиться, очень зависит от вашего желания и упорства. В курсах и в профессии даётся в целом всё необходимое: purpleschool.ru/profession/backend
Можно использовать с апи, доступ к которому осуществляется по ключу, который не хочется светить. Интересно
Хороший пример, спасибо.
Чем это отличается от старых приложений MVC?
спасибо, 👍
Пожалуйста!
зачем Qwik, когда это всё уже есть, либо появится с ближайшими релизами в Next и его поддерживает команда фэйсбука? Зачем учить то, что ещё не популярно и на него нету вакансий на рынке, но за ознакомление спасибо.
Хотелось бы совета. Я работаю в большом проекте уже 3 года, используем реакт. И как то я засиделся. Вдруг пришло осознание что я ужасно отстал от новых технологий. Какой фреймворк можете посоветовать, чтобы начать его изучать на своих пет-проектах? Пока глаз упал на Некст жс.
Next крайне рекомендую, но это тот же React. В целом можно посмотреть на любой свежий фреймворк
Прод передаст привет столько рендерить
Выглядит очень странным, в итоге видим не долгую первую загрузку, а тормоза при каждом клике. Чем от лэзилоадинга отличается?
Lazy грузит отдельные модули, а тут каждую функцию
Имхо, спорное решение. Да, сэкономили на бандле (не так уж и много). Но бандл - один запрос, один хендшейк, один ответ. Если клиент с 3g или нестабильным интернетом - он сможет загрузить бандл в 500 КБ (пусть не с первого раза) и пользоваться приложением (в целом), а если на каждый клик будет запрос и рандом - нервы только испортит. Ну да ладно, если интернет хороший, то ок. Но у многих ли он хороший? В отдалённых от цивилизации местах до сих пор рулит спутниковый интернет с пингом 400-500 мс. Как при таком пинге работать с квиком? На каждый тык мышью придётся ждать ответа. При этом, противопоставлю фреймворки - пинг 500 мс ты подождёшь один раз, а потом с отличной скоростью тебе залетит всё, что надо для SPA. Принимая это во внимание, получается, что QWIK не такой уж и QUICK и очень зависим от качества соединения клиента. А если клиент, который не знает, что там под капотом, ткнул кнопку раз/два/три - он с 90% вероятностью обновит всю страницу целиком. Что-то из кэша будет, но всё равно тут мы выигрыша от квика не получаем.
Мысли в текст: если они решили пойти таким путем, то почему бы не организовать под капотом транспорт на по http а через ws между своим клиент-сервером? Так задержки на загрузку фрагментов были бы заметно ниже, а если разорвалось соединение это можно было бы обработать и отобразить что-то пользователю, сообщить, что с интернетом проблемы.
Спасибо, замечания справедливые. Если соединение не очень, то мы получаем возможную просадку в отзывчивости и иногда race condition, что может быть проблемой. Думаю что можно было бы решить постепенной загрузкой всех компонентов на странице в фоне, при этом так же частями.
@@PurpleSchool Да, хорошая идея. Приоритезация (+ управление ей) и неспешная загрузка в фоне - было бы хорошим решением. Разработчик вполне может предположить, что в каком порядке загружать. Обработчики какой-нибудь формы контактов в футере можно в последнюю очередь загружать.
Зачем выполнять фронт на бэке? А если будет выводиться таблица на 100 строк по 3 кнопки в строке, то на каждой кнопке будет запрос на бэк чтобы получить JS клика по кнопке? Тоесть мы грузим JS, в котором код запроса к REST API, его выполняем, снова идет запрос.... А если на ответ от рест АПИ нужно обновить стейт и срендерить блок, то снова запрос?
Если это таблица, то после нажатия на первую кнопку, обработчик загрузится и будет работать для всех аналогичных обработчиков.
Что насчет state managment'a? Какие можно использовать с ним?
Как и у любых новый фреймворков - плохая инфраструктура. Можно использовать встроенный useStore.
В принципе если развернуть это все дело с QUIC http/2 or http/3 то работать наверно будет очень быстро
Да, если будет стабильное подключение, то производительность будет на высоте.
@@PurpleSchool все равно тратится время на Коннект с сервером, это скажется на отзывчивости.
Как бесит то что все ссылаются на реакт… все смотрят на него… перехайпленный… спасибо за видео обзор🙏👍
Пожалуйста) В индустрии реакт стал почти стандартом, поэтому многие смотрят на него.
Да, фреймворк тоже говно, что и реакт. До Vue 3 и Nuxt 3 им совсем далеко.
@@виртуоз_ру сравнил тоже легкий самолет где штурвал и три рычага(Vue) с боингом)
qwik, qwik и в продакшен)
😂
так это ооп как и ангулар ?
Нет, это функциональный подход, как и React.
Сигналы уже и в ангуляр запихнули в 16ую версию. Да и в свелте кажется уже они были. Не нужны нам новые фреймворки ))
Хотелось бы увидеть в реальном мире, все же один из плюсов который мы получили по сравнению с дедовским подходом - быстрый отклик, потому что все приложение загружается сразу, если каждый клик будет грузить пару строчек кода, не будет ли это минусом. Размер скриптов после solidjs великоват, раз в 8 больше, еще и не все сразу грузится.
Да, он пока больше (core), чем тот же solid, но думаю есть потенциал
абсолютно верная догадка, полностью с ней согласен. Пререндер наше всё. Браузеры уже прекрасно доработаны под толстые клиенты. Я за тонкие клиенты, но это полная клиника. А если сеть у человека упадёт? А если она просто херовая? А что с состоянием? Я на каждый обработчик лоудер должен вешать, чтоб дать человеку понять в случае тупняка что что-то происходит? А откуда лоудер появится? Его тоже грузить? А не проще один запрос на всё с клиента послать, чем забивать втупую канал передачи кучей мелких запросов, да там одних метаданных будет больше чем самих данных.
Короче очередной бесполезный фарш, ещё и на vite, боже, уберите с глаз долой и закопайте в цинковом гробу
@@nickythecasper4314 За что такая ненависть к vite? С ним нет времени на кофе пока идет пересборка?
@@oWeRQ666 да, он очень быстро выкидывает ошибки сборки, не успеваешь понять почему, а он уже сообщает о весёлом вечере.
Особенно весело когда сборка прошла, а доступы к объектам в браузере говорят об обратном.
Тогда время не то что на кофе, на пассать сходить покажется роскошью.
И у тебя явно что-то не так с компьютером, если вебпак собирает тебе бандл дольше, чем ты хотя бы налить себе кофе успеваешь. Ну минута это край, для очень жиного клиента. Никто кроме дибилов страдать от неполноценности vite ради мнимой экономии минуты не будет
@@nickythecasper4314 Не сталкивался с проблемами доступа к объектам, хотя микс esbuild и rollup конечно выглядит не очень надёжно. Что касается времени на сборку, судить надо не по компу, а по проектам, внезапно у некоторых они большие и время сборки приличное.
Этот "новый" подход возвращает старые как мир проблемы от которых вроде бы только недавно избавились когда всё приложение скачивается одним бандлом. Помню ещё лет 10 назад встречалось что жмёшь на кнопку в приложении а реакции нет, это потому что скрипт который содержит обработчик ещё не докачался и не навесился.
Это просто ужасный UX который потенциально ведёт к огромному количеству отвалов у клиентов с нестабильным подключением.
Получается что эта проблема UX как раз та самая основа на чём построен этот "не очередной" фреймворк, да и идея не нова если вспомнить code-splitting вебпака и react.lazy, но тут в чанк кладётся даже 1 функция, и это в век гигабитных подключений))))
А вот на медленном 3G приложение на Qwik скорее превратится в настолько Slov что приведёт к огромному количеству негативных отзывов.
Замечание верное, поведение с нестабильным подключением действительно будет не очень. Но думаю это не последний их шаг и можно улучшить концепцию и грузить в фоне кусочки.
Это какой-то клон Astro - та же островная архитектура. Но у Astro уже вторая стабильная версия. Qwik уже устарел.
Astro медленнее, так как вынужден тащить рантайм островков и активировать его целиком. Но общее есть. Тут просто более точечно работает.
Дкмаю, что $ помечают observables:)
Ну там нет под капотом RxJS, так что в данном случае думаю нет.
Спасибо за видео! Совместимости Квика с существующими библиотеками реакт-компонентов вроде Material UI нет? Нужно писать с нуля самому?
К сожалению совместимости с React библиотеками нет.
Ни кто не запрещает использовать react внутри qwik. Судя по доке
молю, сделай на сайте нормальный скролл, дефолтные браузеровские стили так вырвиглазно смотрятся с хорошим дизайном сайта
Подумаю над этим
React к этому и развивается. Так что не парьтесь.
Да, есть что позаимствовать у Qwik.
Можно обложки видео делать не такими вызывающими?👍
😆
Не впечатлил. Можно поспорить о его преимуществах. Пока лучше ангуляра нет ничего.
Если нужно что-то серьёзнее туду приложения то 100% не стоит тащить туда логику бэка. Но вот выполнять в серверных функциях всякие расчёты, сериализации для бэка по моему самое то. Считай прямое разделение бизнес логиики и ui. Мне кажется это норм
Хорошее замечание. Действительно можно отдать на Backend бизнес логику или тяжелые вычисления. Как кейс - согласен.
Чет роутинг на папках по-моему так себе архитектурное решение.
Наоборот, достаточно удобно. По такому пути пошли Next, Remix и куча других фреймворках.
@@PurpleSchool а если будут нужны чпу-url, при этом часть из них должна формироваться динамически? Это ж прям любимая тема сеошников и боль для разрабов.
А вот с таким "удобным" подходом похоже что никак.
Очень даже работает, так как я сам любитель SEO, много раз делал. Динамические сегменты реализуются через [name]/index.tsx. В name как раз будет динамический сегмент, который можно получить в коде и описать варианты принимаемые.
VUE react solid next в одной коробке ♥️.
Жаль только слоты не полностью затащили
Ага)
А ч о за сигналы? Хайп мимо меня прошел. Это в реакте хук чтоли?
ua-cam.com/video/Gjdtl3vygHs/v-deo.html
очередной мертворожденный, к сожалению
Посмотрим как будет двигаться. Да, конкуренция большая.
Людям с 3г интернетом лучше не попадать на такие сайты 🤭
😂
Да хватит уже этого зоопарка, не ну серьезно, у нас и так есть 3 основных для фронта которые более менее стабилизировались, на бэке все начинает прояснятся… а тут снова началось: то svelt, то solid, то еще там какой очередной новый фреймворк….
А вы говорите еще этот quick вводить в продакшен, будто и без него голова не кругом
Лучше как мне кажется совершенствовать существующие фреймворки а не клепать и плодить стек
Каждый новый фреймворк - это шаг в развитии Frontend. Если его идеи буду эффектными, их могут к себе затащить и крутые игроки, как например стало с Signal.
@@PurpleSchool так может лучше именно развивать все существующие? Signals добавили в Angular-16 это круто, можно ведь и дальше развивать существующие платформы это и будет шагами вперед, то что вы предлагаете это плодить хаус и головную боль.
На счет технологий фронта - все сегодняшние основные столпы (angular react vue) основаны и берут начало из angularJS и неплохо продвигались…
Новое это хорошо(!) развитие это тоже хорошо(!) но нужна разумная интеграция а не создание зоопарка
@@VS-nq1ro Наоборот, зоопарк нужен. Всякие новые решения во фронтенде развивают и стабильные продакшн решения, спустя время самые нужные и рабочие фишки будут протекать в большие фрейиворки и тем самым улучшать их. Например, solidjs сделали сигналы, всем понравилось и теперь все хотят сигналы во вью и реакт, завтра qwik сделает какую то супер удобную фишку и все захотят её в реакт, вью, ангуляр. И т.д.
Так что весь зоопарк фреймворков и библиотек это наоборот круто. Все с друг другом конкурируют и заставляют развивать и улучшать свои инструменты. По этому фронтенд современный и разный, на любой вкус и цвет
@@izzy7541 то что вы описали условно разделяет стек на два вида:
Для прода и для пет проектов и им подобного.
Тогда полностью согласен, есть стек который улучшается, который стабильный и на котором держится прод и есть испытательный стек из которого лучшие фичи выстраиваются в первый.
Такой подход хорош, я же имел ввиду что не нужно стек второго типа превращать в стек первого (пилить прод на нем)
Легенды умирают
Какие?
Интересно, научится ли автор не вставлять кринжовое превью?
Ну нет, это слишком сложно)
гидрАтация.
какой-то трешняк, csr это маст хев и всегда останется, все эти ssr вымрут
Наоборот, весь рынок идёт с SSR, так клиентский рендеринг медленный, увеличивает нагрузку на устройства и недоступен для поисковиков.
@@PurpleSchool одни заблуждения, csr индексируется, клиентский рендеринг быстрее серверного т.к. выполняется все на устройстве и нет задержки от сервера, современные устройства, особенно мобильные обладают более высокой производительностью js, чем пк и соответственно в несколько раз быстрее, чем серверные процессоры.
@@PurpleSchool csr может подгружаться частично (только требуемая часть приложения). Загруженный бандл храниться в кеше и очень редко приходится загружать его повторно.
@@PurpleSchool ну и забыл добавить, что ssr это очень дорого. js не отличается высокой эффективностью поэтому нам нужны тысячи нод и даже десятки тысяч. В CSR достаточно cdn и высокопроизводительного сервера с api
@@PurpleSchool рынок может идти куда угодно, нужно просто видеть будущее. А тут все явно не на стороне ssr, сео - пофиксят. Мобильные чипы с производительностью десктопных - появятся во всех устройствах и нижнего сегмента.
Такое же говно, как и реакт. До Nuxt 3 им ещё далеко.
Хорошая шутка