Расскажу свой опты, не так давно увидел HTMX, и сразу захотел его притащить в проект (благо есть возможность), был уже аякс, решил поглядеть, что будет. Итог выпилил очень быстро, как раз столкнувшись с проблемой распределениям полученного кода по странице. Пробовал изучать документацию, есть варианты решения но с доп. скриптами, кажется, что смысл теряется. По задаче, написал на JS небольшой скрипт который сам все делает. Инструмент норм до первого усложнения. Могу быть не прав опыта работы с HTMX не сильно больше, чем у автора.
Ну, та проблема которая описана автором, в принципе, как раз несложно решается тем же самым броадкастом. Хотя с логикой суждения согласен. Приходится сталкиваться с ситуациями когда ответ с бекенда может быть связан с перестроением dom элементов. Кроме того, бизнес логика бывает такой сложной что я не представляю как ее можно описать в тегах. Я уже не говорю о безопасности такого подхода. Что мешает переписать атрибуты и сформировать вредоносный код?
Видео ради видео, я тоже когда-то писал SSR (20 лет ИТ-разработки), так-же когда-то пытался в атомарность, тоже делаю кодген для построения микросервисов (хороший с AST), все это было, есть и будет, SSR? - ReactServerComponents, атомарность? - TailwindCSS, другой вопрос в том, что js сейчас это разработка тяп-ляп, куча модулей, куча подходов, все проекты постоянно разные, даже если не надо на проекте js - его тащат, при том тащат не только его а банально лэндинг с якорями с бандлом под 2мб, и исходниками в 3Гб. Написать карусель для разработчика сейчас сродни написания прошивки для лопатки ускорителя ракетоносителя, поэтому просто берут то, что валяется в npm, даже если это избыточно, в итоге каждый модуль имеет свою систему сборки css, либо пре-процессингом, лио пост-процессингом и все это барахло собирается по часу на пайплайнах. Htmx я использую и имею достаточно опыта, чтобы сказать, что он имеет место быть, но применять его нужно по месту. Если проект нагружен функционалом, присущим фронтенду, то я предпочту SolidJS реакту, просто потому что первый утомляет не разработкой, а тем что ты постоянно его пытаешься тюнить, он то в ререндеры уходит там где не следует, то косяки при ssr.. Лично я просто устал принимать те же самые проблемы в работу как задачу бизнеса, я за подход - "бритвы Оккама", зачем усложнять и без того не простые вещи, можно: во-первых принципам обобщенного программирования следовать и использовать кодген, во- вторых если для того чтобы отобразить список я должен его куда-то в STM засунуть пройдя 5 абстракций, то это выглядит как расфокус от решения основной задачи - показать список. для чего я должени думать каждый раз над архитектурой этих абстракций, где запросить, как обновить, куда положить, как сделать нотификацию, как предупредить ререндер, что будет если не придут данные? Htmx для меня стал понятным витком, да, очередного SSR, но это лежит на поверхности, да, с ограничениями, но логичными, это НЕ ЗАМЕНА js, это тот случай когда ради похода в магазин через дорогу человек прогревает 10-литровый дизель в своей машине чтобы поехать, и находит самокат. как-то так. всему нужна экспертиза и не на уровне "книгу не читал, но не одобряю", а хотябы понять что может дать технология, если она дает мне РАЗГРУЗКУ, то я определенно на нее обращу внимание и попробую, а так ли это как говорят. Автору удачи и не думать, что скорое видео лучше чем видео по фактам, свои просмотры ты соберешь, если дашь полезную информацию.
👎👎👎 а почему тут JS при рендеренге? при получении HTML Фреймворк проверяет в нём атрибуты и на основании атрибутов делает его живым. для этого не нужно ещё раз грузить JS
По вашему вопросу угадывается некоторый недостаток исторического контекста и опыта решения задач в широком круге проектов. Просто пользуйтесь тем, чем хотите. Однажды поймете при чем тут JS при рендеринге и о чем я рассуждаю. А если не поймете, то и не надо, значит вам не попадались подходящие кейсы. Успехов в работе!
@@iam-the-teacher Возможно Вы правы. Но мне так же кажется что Вы сравниваете Приору с Ламбордини. У Приоры своя ниша. И сравнивать HTMX с React`ом не справедливо. На реакте можно писать порталы типа ВК. а на HTMX писать маленькие магазины или сайты для Зубных поликлиник, где нужно зарезервировать место. В своей нише HTMX будет золотым. Или Вы предлагаете писать сайт для зубной поликлиники на React? Так же надо понимать что сайтов зубных поликлиник в 1000 раз больше чем сайтов таких как ВК. Т.е. простых сайтов с легкой реактивностью на порядок больше чем сайтов с глубокой реактивностью. И те и другие сайты нужны клиентам и посетителям этих сайтов.
ну хватает же наглости у людей, вот изучи технологию, разберись, а потом пиши что прям вот понял, вот вижу, знаю. А то выходит что просто что -то краем уха услышал, сам не работал, книгу не прочел, даже мини проект какой для вида не сделал, а уже какие-то выводы. ОПЫТ ЖЕ, АВТОРИТЕТ!. просто зря потраченное время...
Профессиональный опыт и понимание концепции инструмента позволяет мгновенно находить слабые стороны и озвучивать самые важные моменты, не затаскивая слабый инструмент в продакшн. Желаю вам профессиональных успехов и роста!
Расскажу свой опты, не так давно увидел HTMX, и сразу захотел его притащить в проект (благо есть возможность), был уже аякс, решил поглядеть, что будет. Итог выпилил очень быстро, как раз столкнувшись с проблемой распределениям полученного кода по странице. Пробовал изучать документацию, есть варианты решения но с доп. скриптами, кажется, что смысл теряется. По задаче, написал на JS небольшой скрипт который сам все делает. Инструмент норм до первого усложнения.
Могу быть не прав опыта работы с HTMX не сильно больше, чем у автора.
Ну, та проблема которая описана автором, в принципе, как раз несложно решается тем же самым броадкастом. Хотя с логикой суждения согласен. Приходится сталкиваться с ситуациями когда ответ с бекенда может быть связан с перестроением dom элементов. Кроме того, бизнес логика бывает такой сложной что я не представляю как ее можно описать в тегах. Я уже не говорю о безопасности такого подхода. Что мешает переписать атрибуты и сформировать вредоносный код?
Видео ради видео, я тоже когда-то писал SSR (20 лет ИТ-разработки), так-же когда-то пытался в атомарность, тоже делаю кодген для построения микросервисов (хороший с AST), все это было, есть и будет, SSR? - ReactServerComponents, атомарность? - TailwindCSS, другой вопрос в том, что js сейчас это разработка тяп-ляп, куча модулей, куча подходов, все проекты постоянно разные, даже если не надо на проекте js - его тащат, при том тащат не только его а банально лэндинг с якорями с бандлом под 2мб, и исходниками в 3Гб. Написать карусель для разработчика сейчас сродни написания прошивки для лопатки ускорителя ракетоносителя, поэтому просто берут то, что валяется в npm, даже если это избыточно, в итоге каждый модуль имеет свою систему сборки css, либо пре-процессингом, лио пост-процессингом и все это барахло собирается по часу на пайплайнах. Htmx я использую и имею достаточно опыта, чтобы сказать, что он имеет место быть, но применять его нужно по месту. Если проект нагружен функционалом, присущим фронтенду, то я предпочту SolidJS реакту, просто потому что первый утомляет не разработкой, а тем что ты постоянно его пытаешься тюнить, он то в ререндеры уходит там где не следует, то косяки при ssr.. Лично я просто устал принимать те же самые проблемы в работу как задачу бизнеса, я за подход - "бритвы Оккама", зачем усложнять и без того не простые вещи, можно: во-первых принципам обобщенного программирования следовать и использовать кодген, во- вторых если для того чтобы отобразить список я должен его куда-то в STM засунуть пройдя 5 абстракций, то это выглядит как расфокус от решения основной задачи - показать список. для чего я должени думать каждый раз над архитектурой этих абстракций, где запросить, как обновить, куда положить, как сделать нотификацию, как предупредить ререндер, что будет если не придут данные? Htmx для меня стал понятным витком, да, очередного SSR, но это лежит на поверхности, да, с ограничениями, но логичными, это НЕ ЗАМЕНА js, это тот случай когда ради похода в магазин через дорогу человек прогревает 10-литровый дизель в своей машине чтобы поехать, и находит самокат. как-то так. всему нужна экспертиза и не на уровне "книгу не читал, но не одобряю", а хотябы понять что может дать технология, если она дает мне РАЗГРУЗКУ, то я определенно на нее обращу внимание и попробую, а так ли это как говорят. Автору удачи и не думать, что скорое видео лучше чем видео по фактам, свои просмотры ты соберешь, если дашь полезную информацию.
За комментарий спасибо. Успехов в разработке!
Реакт отправляет разметку в виде джсон, то ли уже, то ли в скором будущем.
В целом, ничего особо нового тут нет
А рубишный Hot Ware, stimulus решает проблемы описанные автором ролика?
аналогичный вопрос
👎👎👎 а почему тут JS при рендеренге? при получении HTML Фреймворк проверяет в нём атрибуты и на основании атрибутов делает его живым. для этого не нужно ещё раз грузить JS
где тут обмазывание JS , если загружаемый html становится живым сразу на основе атрибут ов без js.
По вашему вопросу угадывается некоторый недостаток исторического контекста и опыта решения задач в широком круге проектов. Просто пользуйтесь тем, чем хотите. Однажды поймете при чем тут JS при рендеринге и о чем я рассуждаю. А если не поймете, то и не надо, значит вам не попадались подходящие кейсы. Успехов в работе!
@@iam-the-teacher Возможно Вы правы. Но мне так же кажется что Вы сравниваете Приору с Ламбордини. У Приоры своя ниша. И сравнивать HTMX с React`ом не справедливо. На реакте можно писать порталы типа ВК. а на HTMX писать маленькие магазины или сайты для Зубных поликлиник, где нужно зарезервировать место.
В своей нише HTMX будет золотым. Или Вы предлагаете писать сайт для зубной поликлиники на React?
Так же надо понимать что сайтов зубных поликлиник в 1000 раз больше чем сайтов таких как ВК. Т.е. простых сайтов с легкой реактивностью на порядок больше чем сайтов с глубокой реактивностью. И те и другие сайты нужны клиентам и посетителям этих сайтов.
ну хватает же наглости у людей, вот изучи технологию, разберись, а потом пиши что прям вот понял, вот вижу, знаю. А то выходит что просто что -то краем уха услышал, сам не работал, книгу не прочел, даже мини проект какой для вида не сделал, а уже какие-то выводы. ОПЫТ ЖЕ, АВТОРИТЕТ!. просто зря потраченное время...
Спасибо за комментарий! Удачи в профессии.
Дааа... Не смотрел, но не понравилось.
Профессиональный опыт и понимание концепции инструмента позволяет мгновенно находить слабые стороны и озвучивать самые важные моменты, не затаскивая слабый инструмент в продакшн.
Желаю вам профессиональных успехов и роста!