Вход в комьюнити (обязательно подписывайтесь): t.me/howToLearnIT ******************* 0:00 Проблематика 01:45 БЕСПЛАТНЫЙ вход в комьюнити 02:35 Что такое HTMX? 03:25 Первый пример: свэппинг и запросы 05:55 Второй пример: пагинация 06:35 Третий пример: lazy-loading на кастомных событиях 07:23 Четвертый пример: Hyperscript 09:21 На что еще способен HTMX? 10:13 Плюсы HTMX 11:12 Минусы HTMX ********************** Документация: htmx.org/examples/ Как переписали большое приложение с React на Джанго + HTMX kzfaq.info/get/bejne/aa1_lcxqmNrOin0.html #html #js #css #react #frontend

"...Теперь для разработки фронта не нужен JS, только HTMX..." Шаг №1 - Подключаем JS библиотеку в head ...

Программисты HTML никак не сдаются и доказывают, что они существуют!

Требуется HTMX-программист с опытом от 3 лет

Если это заменит фронт, то CSS способен заменить бек

Забавная технология, но не более. Жизнеспособным такой подход к написанию приложений сложнее hello world назвать язык не повернется

Много фактических ошибок в первой части ролика. Например, первый сырой Laravel вышел только в 2011 году, а JQuery, который по словам автора появился позже, вышел напротив, ещё в 2006-м, когда пошла массовая мода на AJAX и манипуляцию DOM-элементами страницы. Сайты «полностью рендерились на сервере» только в конце девяностых - уже ВКонтакте был динамичным на JS, хотя запустился ещё в 2006, а про Gmail, GoogleMaps и Яндекс.Карты даже начинать не буду. Насчёт «в ту пору писали на PHP» - так на нём до сих пор работает добрая треть интернета, включая таких монстров, как Facebook, VK и Wikipedia 😅

Сомневаюсь, что это приживётся, усложнение html-ки логикой обработки не понятно для чего, когда лучше разделить эти сущности и отдать это на обработку в js, который можно маштабировать и разделять на модули. Тут говорят, что это проще, но с виду это сильное усложнение, те кто хочет верстать лендинги и говносайтики без внутрненний или минимальной логикой, при том, что их устраивает, что в конце получится простыня кода, то удачи вам в коммерции, лучше сразу идите изучать NoCoding)

Я так понял челы, которые это изобрели, были в коме в то время, когда появился ajax

Очередной убийца React, который помрет раньше чем выйдет в альфу :D

У меня болит голова от новых фреймворках каждую неделю

Для senior html программистов

Эх ностальгия нахлынула, я подобную библиотеку 10 лет назад написал, все идет по кругу.

Удобно, что на страницах с примерами внизу показывается число запросов к серверу при каждом взаимодействии с интерактивными элементами - сразу видно, из каких мест оно будет дидосить сервер и как лучше не использовать HTMX.

В 98м году всё так и работало, вот это супер технологи, я в восторге! Кажется разработчики в дореактные времена под стол пешком ходили и не помнят как мы все получали кусочки html и втыкали их куда-то в dom. Вы еще аякс за турботехнологию выдайте )) Ну и да, не до смеха когда я гиперскрипт вижу, это же читать невозможно, чем это лучше js-то? (я уже молчу что на js он и работает) 😂 😂 Разработчики молодцы, что пытаются придумать что-то новое конечно, но выглядит это всё катастрофически ужасно и написать что-то продуктовое на этом очевидно невозможно.

Все работает ровно до тех пор пока тебе не становится нужным написать инпут с автодополнением, изменение стейта которого определяет появление других инпутов в сложной форме)

Тот момент когда html стал языком программирования😂

Еее спасибо за новое видео! Заждались уже🔥🔥

Вместо нормальной типизации - обычный текст на ХАЙПерСкрипт😅 Вместо всем известного хтмл и жс - учим новый хтмл и новый язык скриптов😊 Даже при полном не знании фронта я бы не рекомендовал бэкам трогать это даже самой длинной палкой)

дааа, давайте ещё к этому посмешищу добавим tailwind и получим километровые нечитаемые куски -дерьма- HTML, где чёрт ногу сломит 👍

Да-да, плавали, знаем. Сложнее примеров из видоса на этом говне ничего не написать, ибо проще научить слона играть в покер, чем на этом "убийце react" накодить хотя бы средних размеров фронт

Ух ты, кто-то придумал еще один фреймворк для фронта! Никогда такого не было и вот опять.

HTML и JS ссыпали в одну коробку и назвали это новой технологией... Вопрос зачем ? Какие проблемы она решает... кроме создания нового синтаксиса написания кода.

Я правильно понял? в html юзеру при нажатии на кнопку отправляется новая страница, а в htmx та же страница пересобирается?

т. е. с бека ожидаются не данные а уже готовый html с данными?

мертворежденный. усложнение бэка за счет упрощения фронта: это даже для пет проектов не выглядит сексуальным. особенно в современном мире, где клиентом может быть любой тостер с рантаймом на несуществующем языке.

Чем это отличается от AJAX запроса на сервер, который возвращает HTML, который мы подставляем в нужное место? Тупо проще писать, но зачем? Backend отдает данные, frontend их рисует как нужно. Всё

Всё на строках, нормальных переменных и т.п. нет. Получается переиспользование кода стремится к нулю, дублирование кода, да и поддерживать такое не очень удобно, а ну и ещё смешивание с атрибутами самого HTML, из-за чего всё становится более громоздким, когда хочется наоборот. Если всё это исправить, то получится фронтенд-фреймворк HTMX = React/Vue/Angular

Дебажить это чудо будет сплошным удовольствием

Я не понял, если было в планах изучать React, то лучше вместо этого начать с того что в видео? Или всё же не заморачиваться и всё равно react изначально?

Подскажите не пойму где храниться код формы которая приходит по get-запросу(((

Для embedded типа openwrt пойднет?

Классное нововведение которое ещё в 2008 преподавали в виде создания формы и привязки параметра submit на button. Именно потому что кнопка выполняла клиент-сервер функции, её заменили тегом с рамкой в последующих этапах развития разметки. Абсолютно не понимаю кипиша по этому поводу.

Интересно, как они гиперскрипт заимплементили. Полноценный АСТ строят и транслируют в жс, или как-то по другому, например, микровм для интерпретации на жс написали и на ней исполняют.

fetch и xmlhttprequest спокойно решают данную проблему, Сия чудо можно назвать просто фреймворком, но никак не новой технологией. Это, наверное, будет удобно, не спорю, но скорее всего, если будет интерес, просто добавят в спецификацию html

ураааааа новая копна уязвимостей!

Какой Laravel в 2008?

Чем это отличается от vue cdn?

Как всегда круто)

Наконец-то русскоязычные айти-ютуберы дошли до HTMX

Спасибо ❤

Чел, я работая фронтом в 23-м году использую jQuery , и не потому что очень этого хочу, а потому что проект так сделан. Я нихрена не шарю в этом древнем г*вне, но приходится потому что оно используется на проекте. А вы тут про какой-то серверный рендеринг, какие-то реакты, динамика. Большим дядям все вот эти новомодные штучки вообще не нужны. Им нужно , условно говоря, старый проверенный временем и десятками проектов инструмент, который работает как часы. Под это подходит реакт, ангуляр и прочие гиганты, но никак ни вот этот "новаторский подход", ты скажешь такое шефу, он пальцем у виска покрутит и все ... С другой стороны, это тоже понять можно, ведь на кой хрен выдумывать что-то новое, если старое и так все работает. Тем более это новое не протестировано и , скорее всего, чтобы пересесть на него понадобится время, а время, как и в любом другом бизнесе - деньги. Очередная мертворожденная херня

Не заменит эта технология фронтов) Для Верстальщиков будет крутая технология, но у фронтов есть Angular, React, Vue, смысл вообще камбекаться в html

Привет, Друг 🤝 Впервые от тебя только это узнал 🔥👍👍👍

Из Ajax'са звонили, свою идею назад просили. Если нормально, концепт пока натянут немного, но если развивать в правильном направлении и с умом, то может что-то выйти

Это с одной к примеру кнопкой хорошо, а что если есть список товаров и кнопка добавить в корзину, это что, на каждую кнопку этри абуты циплять? Размер нтмл кода будет огромный в результате, на сложных сайтах.

а что насчет сео? я в нем не силен, но подозреваю, что это может повредить продвижению сайта?

Мне интересно, сколько фронтендеров в комментах пишут сложные SPA-интерфейсы, а не CRUD со свистоперделками, говоря о том, что htmx не жизнесопособен?

Ну а, банально, состоянием приложения как управлять?

Я вам больше скажу: на современном html5, css3 и es6+ легко можно писать точно такие же сложные интерактивные приложения, как на любом фреймворке, причём без единой библиотеки. Даже работать быстрее будет и меньше говнокода плодить. Только для этого нужно хорошо знать основы и паттерны проектирования.

Super)

Я люблю использовать htmx, но сталкнулся с проблемой - при загрузке части страницы с помощью htmx, где содержится swiper, он перестает работать, но если загрузить всю страницу, то все работает нормально. может кто-нибудь подскажет, как решить проблему?

4:45 мм, хочу найти бекендера который на серьезных щах будет слать верстку на клиент

Хм, ну то есть вместо JavaScript и JSX получаем HyperScript и HTMX, а те вещи, которые обеспечивает фронтэнд-фреймворк, либо не имеем вовсе, либо пишем самостоятельно. Не вполне понял, в чём тут улучшение.

А чем react или vue стал плох?

Очень интересно, но не понятно, я же все могу это сделать в js, ты говоришь условно не нужен js, но по сути этот htxm и есть js.

Для HTMX не нужен JS! нужно всего лишь подключить мааааааленькую JS библиотеку... т.е. JS всё же нужен, получается HTMX просто какая-то кастомная JS библиотека. В ролике же наваливают, как будто это сам HTML эволюционировал в новый формат HTMX! Моё мнение - HTMX выглядит как говно и пользоваться им будут энтузиасты, которые просто хотят пощекотать нервы.

Так, это все хорошо, но как поиск будет обрабатывать страницу такую, если урла не меняется?) Теперь ждём 5 лет, когда они это внедрят?) Или есть вариант отдачи роботу страницы со всем везде прожатым ?)

нужно еще 100500 фреймворков и языков чтоб никогда не устроиться в соседнюю контору

А я ещё пару недель назад увидел на англоютубе обзор на эту игрушку) выглядит интересно, но использовать никто не будет вероятно)

Звучит как неплохая штука, чтобы писать чисто админки и дашборды для внутренних инструментов

Плюсы: быстро, всем управляет команда бэкендеров (сервер) Минусы: тонна строчных триггеров и идентификаторов (а главный ад как раз кроется в компонентах - где какой идентификатор компонента появится, будет ли перекрытие и т.д.)

👍

Использую для форм и фильтров . Если нужно что сложнее, то alpine. Если ещё сложнее и не нужно сео (админка например), то vue

где роутинг, Билли? решается бекендом?

Пробовал делать админку на нём. Довольно комфортная штука

на каждый чих слать реквест, спасибо, не нужно))

"Эйч икс СвЭп" -- так в видео. Посмотрите, пожалуйста, в словарь, как правильно это произносится! "submit" -- а ударение на какую букву здесь должно быть?

3:10 каво? Нынче легче найти сайт, в котором бэкенд просто жсончик отправляет, а клиент в соответствии с ним уже имеющуюся страницу перерендеривает, нежели сайт, в котором "бэкенд отправляет новую страницу"

В Rails 7 такой подход. Turbo + Hotwire + Stimulus.

Прикольно но как в htmx работать с сервером

Теперь осталось понять, чем это лучше пыхи ) и как декларативно описать логику страницы и возможно ли это 😂

ochen interesno

Для backend'еров будет нормально, простые админки делать по быстрому

Плюс - низкий порог вхождения для фулл стека. Минус - что бы сделать красивый интерфейс с анимациями нужно знание js выше чем при внедрении js-фрейморков. Применимо только там где не нужен красивый ui

Почему просто не перекласть больше простых задач на HTML, а сложные оставить JS-су?

Ну прям Compose!

HyperCss не завезли ?

о, я такой же велосипед лет 10 назад писал )

подключаем библиотеку на js @ теперь не нужен javascript....

Вау, они изобрели еще одну обертку над fetch'ами, необычно, да

Полезно знать, для общего развития) Но до использования чет мне кажется далеко

Идея не плохая! Только отстала минимум на 10 лет😂 Насчёт того что идея не плохая я кстати не пошутил. Когда работал в одном из проектов в котором был JQuery сам лично реализовывал подобную штуку, сильно ускоряло разработку интерактива. Я её тогда свою библиотечку назвал ajaxhelper.

не буду использовать так как сервак спамиться мелкими запросами. Сейчас у меня штмл шаблоны хранятся в ява константах который вшивается из другого штмл файла заранее. Но как фреймворк довольно свежо.

Что то типа livewire в Laravel. Проблема в том, что за каждой маленькой хренью надо будет посылать целый запрос и обрабатывать его.

О, велосипед придумали! Молодцы!

hyperscript... посмеялся спасибо =)

Привет из 2020 от hotwire и turbo мира Ruby On Rails, сам подход ок, при проектировании большого количества достаточно простых интерфейсов - админок и около них позволит избавиться от большого количества реактовского бойлерплейта при управлении состоянием, а так же добавить удобной интерактивности

Уж сильно напоминает историю jQuery. Лёгкий вход, несложный синтаксис, но что-то серьезное на этом написать будет сложно и не разумно

Штука интересная, но скорее всего приживется в набросках макетов или в конструкторах сайтов

Старый добрый ajax тоже может притащить с сервера отрендеренный кусок html. Alpine JS без проблем обогащает код своими атрибутами. В чём прорывность данной технологии? Почему её все пиарят?

Как раз для моего сайта по температуре воды в Ыссык-куле

Livewire нет ?)

А шо с анимациями?

Попытка создать еще один фронтенд фреймворк. Как по мне, говнореакта с его танками и редаксами уже более чем достаточно. Даешь С++ и железки!

Swap - своп Карл, своп! All - ол, also - олсо

У нас уже давно внедрен, и прекрасно работает, спим крепко теперь. Фронт стейтлесс, все прекрасно

Табы можно и на чистом html и css написать🙂

Так сам же говоришь, полноценного приложения не напишешь, придётся подключать JS и фреймворки. Усложняют простой язык, когда есть уже рабочие инструменты, которые работают лучше и проверены временем. Тут нужны прямо серьёзные или качественные улучшения, чтобы отказаться от уже используемых. Бэкендерам и так и так приходится учить основы фронтэнда, может всё же в штате иметь одного сотрудника фронтэнд-разработчика?

"Laravel's first beta release was made available on June 9, 2011, followed by the Laravel 1 release later in the same month."