Ну то есть перенесли всю сложность с фронтенда на бэкэнд и теперь на каждый чих надо отправлять запрос? Думаю, пользователи в каких-нибудь ебенях с паршивым 3g который работает через раз - оценят.
@@lmnk js закешируется при первой загрузке. Например по wifi Чтобы долбаный счетчик уменьшить или увеличить на 1 больше не нужно будет ждать ответа от сервера при потери сети или смены на 2g или 3g.
Тут же больше вопрос в легкости сайта. Например, для какой-нибудь форума , блога или магазина выбирать реакт - оверкил. Взять тот же ВордПресс, почему он популярный? Потому что на php сайты быстрее и легче. Так же будет и с htmx. Я бы htmx больше рассматривал как замену php на JavaScript, чем как замену реакта
Признаюсь, никогда не работал над проектами с HTMX. Но честно говоря, с точки зрения стороннего наблюдателя, вопросы к оригинальной статье имеются. В вебе в целом многие идеи и предложения изначально залетают хорошо, но когда погружаешься глубже, то довольно часто бьешься об подводные камни лбом, и в данной ситуации кажется, что автор о некоторых вещах умолчал как раз для таких случаев. Начать, вероятно, стоит с того, что пример на Реакте не совсем отражает реальность. Классовые компоненты, конечно, имеет смысл использовать в некоторых ситуациях, в таких как ErrorBoundaries или нужно отловить пропсы перед ререндером, допустим, но вот в этом конкретном примере это лишено всякого смысла. В функциональной компоненте кода на самом деле было бы меньше. Что касаемо серверной логики, то это Реакта, как библиотеки для создания интерфейса, не касается вовсе. Инкремент в целом вообще может быть создан сознательно только для работы на клиенте, в таком случае HTMX с ее постоянными запросами на сервер выглядит странно. Вероятно это предстоит обойти встраиванием ванильного js в документ, но картина уже в целом не такая радужная становится и в таком случае на клиенте js понадобится достаточно много. Если же элемент действительно нуждается в серверном взаимодействий, то да, в Реакте придется использовать вероятнее всего стороннюю библиотеку в виде RTK, но и здесь имеются вопросы. HTMX предоставляет ли возможности для улучшения UI опыта в виде optimistic updates, кеширования и прочего? А если нам нужно добавить возможности офлайн работы как в PWA? И конкретно данный момент можно раскручивать дальше в глубину. И молчу про вопросы касаемо бэка, такого типа как насколько сильно увеличится нагрузка и прочее. Что касаемо множества зависимостей библиотек и прочего, то точно такая же проблема существует и на бэкенде. И я более чем уверен, что при HTMX действительно на клиенте зависимостей в разы меньше, но их становится больше на бэкенде. Это все равно, что переложить вещи с дивана на стол. Написал эту стену из-за заключения в оригинальной статье, где передается посыл, дескать хайповость и трендовость Реакта послужили причиной высокой требовательности в подобного рода разработчиков, а так HTMX не хуже. Нет, это не совсем так. HTMX крут, но только в конкретных условиях, а так фича имеет ограниченные возможности в использовании и потому в нем нуждаются гораздо реже.
Можно только позавидовать серьезности вашего комментария, у меня, как разработчика заставшего эру jQuery, когда было нормой подгружать куски html, все эти рассуждения на на тему замены реакта не вызывают ощущения адекватности.
@@oWeRQ666 Времена jQuery, как мне кажется, были достаточно темными в истории веба. Всем приходилось его использовать, выбора то особо не было. Ванильный JS тогда был топорным, поскольку функционала было меньше. Но эти изменения DOM через AJAX запросы, конечно, было отличной возможностью выстрелить себе в ногу, если не отладить все по десять раз убив много часов. И то, если интернет слабый, а тогда он у многих как раз был таким, то пользователь вообще ничего не получал из этих запросов. И молчу про синтаксис с цепочками chaining вызовов - это лично меня заставляло пускать кровавые слезы, глядя на код jQuery. В общем да, некоторая аналогия прослеживается. С появлением React-а ситуация в Вебе изменилась в лучшую сторону. Я когда в первый раз его пощупал, то у меня случился взрыв мозга. Создавать проекты стало проще. Хотя вспоминая старый реакт в связке со старым редаксом... приходилось писать очень много бойлерплейта, прокидывать компоненты в Hoc, связывая с connect, прописывать mapStateToProps, писать константы для экшенов в свиче. Да и сами классовые компоненты заставляли писать много шаблона, поскольку хуков тогда еще не придумали для использования логики определенного функционала повторно. А ведь до сих пор ходит бугурт на тему того, что переход на функциональный подход стало ошибкой! Но в целом, даже учитывая этот недостаток, все равно это было лучше, чем писать код на jQuery. React универсальный инструмент, который еще долго будет жить. Но мне лично не совсем нравятся последние изменения в ее экосистеме. То разрабы Remix добавят кучу ненужного функционала в react-router-dom, то разрабы Next упарываются по добавлению бэкенд фичей на фронт. Не спорю, что добавленные ими возможности имеют право на существование в некоторых ситуациях, но все же в большинстве случаев это все можно было отыграть как-то иначе - фичи для роутинга, например, как аддон отдельно в пакет погрузить, а не пихать в общую либу. И в целом стоило бы больше сосредоточиться на фронте. Я вдобавок к тому же немного устал бороться с механизмом Reconciliation в реакте, потому недавно начал пытаться щупать другие фреймворки, чтобы освежиться так сказать. Пока колупаю Astro, тоже довольно нишевый инструмент и React не заменит (React в целом еще долгое время не смогут заменить ), но выглядит свежо и интересно.
На мониторе 27'' код еле видно, что у вас за дизайнподход такой? Т.е. людей с планшетами и телефонами вы отсеиваете за не надобностью? Вы открывали свой видос на планшете?
На телефоне и планшете можно зум сделать. На мониторе смотрел - вроде было все видно неплохо. Но учту на будущее, буду пробовать крупнее делать, где получится, спасибо
@@ListenIT_channelЗдравствуйте! При качестве видео 360 текст нечитаемый даже при масштабировании. Небольшое увеличение размера шрифта пошло бы на пользу
Ну, thymeleaf и ftl файлы - это обычные HTML странички, контент которых просто подставляется от сервера. Но они не заменяют SPA функциональность JS. А тут прям что-то сильно другое. Хотя по цели (облегчить жизнь бэкендирам) они действительно похожи
0:09 - Скиллбокс - категорически осуждаю! :) Точно также, как и скиллфэктори, гигбрейнс, и прочие лохотроны. Такое, должно быть на законодательном уровне запрещено, с соответствующими тюремными наказаниями для главных владельцев)
Здравствуйте. Огорчены вашей позицией, но не можем не спросить, чем вызвано осуждение? Эффективность наших курсов подтверждают студенты. Например, согласно исследованию НИУ ВШЭ, 84% пользователей, завершивших обучение, находят работу по специальности, которую изучали в Skillbox.
Та не. Это же уже проходили. MS что-то такое продвигали в конце двухтысячных. Можно было делать контролы, которые обновлялись без перезагрузки страницы. Но беда там была в управлении состоянием. Серваку нужно знать состояние клиента, а значит его надо каждый раз пересылать. Это приводило к довольно большим запросам в дополнение к ожидаемо большим ответам. И вся это обработка загружает бэкенд, который расширять будет стоить денех. Ну и главное - зачем тогда клиенту все эти гигабайты оперативы, если не для того чтобы держать там мою spa?
Майки до сих пор не потеряли надежду, Blazor имя ему, с хранением состояния на сервере и общением через вебсокет, я был крайне удивлен, что это поделие хоть и умеет выполняться на клиенте в одном из вариантов сборки в wasm, но не смотря на общую кодовую базу не умеет само общаться с беком, т.е. нет чего-то вроде trpc.
Я пока что то не как не вижу как он выместит React и остальные фрейм/библиотеки, по факту серверный рендеринг нужен если проект нуждается в seo оптимизации,для поисковых машин, если в конкретном проекте это не нужно то вы просто так будете выкидывать не маленькие деньги на трафик сервера и на его поддержку, ssr приложение всегда кушает больше трафика чем обычный spa, потом синтаксис и методы разработки чем то напоминают мне подход view который заставляет разрабов учить сам view и забывать про js, плюс всю логику которую front end привыкли писать теперь нужно будет писать backend разработчикам? Ну такое себе.....
Сколько бы не пытались, но реакт не только на этом строится. Самая основная его фишка это возможность легко смешать в одном месте и JS и разметку для любой фигни которую попросит этот не определившийся заказчик
Очередная поделка, которая не взлетела. Бесполезна чуть более, чем полностью. - куцый синтаксис позволит сделать только базовые вещи, а его еще учить - генерация кусков html на бэкенде и подгрузка аяксом чем это меньше json с чистыми данными?
Если вы про комментарии про замену Реакта и маленький шрифт, то они есть и отображаются, всё нормально. Если какие-то другие, то тут вопрос. Никто ваши комментарии не стирал, в спам-фильтр они не попадали.
Очень странное сравнение. Ну допустим, многое из перечисленного применимо и к Next, хотя с его SSG и кешированием уже половина поинтов отвалилось бы с производительностью, нагрузкой и первым рендером. Но есть, например, Astro. И он уже не даст в сравнении таких преимуществ, даже в сложности кода. А использовать React для хайлоуда и говорить, как стало хорошо, когда его убрали - смешно. Зачем вы вообще его тянули в чистом виде?))
Ну и как уже говорили, бизнес логика не дематериализуется в пустоту, она просто выносится на бэк. Невероятные архитектурные достижения, очень просто все, ага
Ничего серьезного на нем не сделать. В с запросами хожит так же много метаданных. И если на каждый чих ддосить сервер, то компания скорее обанкротится отдавать столько денег за сервера
Классы в реакте не юзают уже как лет 5, дружище, что это вообще за пример кода? А то, что ты рассказал в своем видео называется SSR, с которым React, Angular и Vue успешно взаимодействуют. И ты, конечно же прав в том, что подключить миллион библиотек с разных сайтов, вместо того чтобы использовать условный npm, где все в одном месте, контролировать кучу файлов вручную и использовать устаревшие технологии намного удобнее, чем воспользоваться сборщиком.
Даже если каким-то чудом часть рынка перейдет на это посмешище, ты действительно считаешь, что люди вернутся в блокнот и будут писать код там, отказавшись от сборщиков?
В начале года все хайпили эту библиотеку, но вроде уже давно все успокоились, вернулись к своим основным инструментам и забыли про нее. Есть ли за ней будущее?
Htmx вроде лет 15 уже Автор почему-то заявляет, что htmx противопоставляет себя реакту и другим мастодонтам, но создатели говорят, что во многих случаях нет необходимости в логике на клиенте, и если надо добавить минимальную реактивность, может быть имеет смысл посмотреть в сторону htmx
Мне нравится использовать htmx в комбинации с golang и библиотекой templ для него. Для CSS можно tailwind накинуть Не думаю что в ближайшее время такая комбинация инструментов приживется на рынке, хотя мне кажется она точно может закрыть процентов 90 потребностей, но как минимум для себя попробовать стоит
С одной стороны NextJS, в который мы подтягиваем бэкэнд и можем написать небольшую апишку, а с другой HTMX, который подтягивается уже В бэкэнд. Шо то, шо то несёт так себе. Нужно писать всё на php, ребята, и не париться.
Очень интересно. Пойду посмотрю пару туториалов по htmx.
Ну то есть перенесли всю сложность с фронтенда на бэкэнд и теперь на каждый чих надо отправлять запрос? Думаю, пользователи в каких-нибудь ебенях с паршивым 3g который работает через раз - оценят.
Отправляя скомпилированный в JS код react/vue, вы трафика не сэкономите особо, если не больше будет потребляться
@@lmnk js закешируется при первой загрузке. Например по wifi Чтобы долбаный счетчик уменьшить или увеличить на 1 больше не нужно будет ждать ответа от сервера при потери сети или смены на 2g или 3g.
Смотря как много таких запросов будет. Сильно от того что за сайт зависит.
Тут же больше вопрос в легкости сайта. Например, для какой-нибудь форума , блога или магазина выбирать реакт - оверкил. Взять тот же ВордПресс, почему он популярный? Потому что на php сайты быстрее и легче. Так же будет и с htmx.
Я бы htmx больше рассматривал как замену php на JavaScript, чем как замену реакта
Признаюсь, никогда не работал над проектами с HTMX. Но честно говоря, с точки зрения стороннего наблюдателя, вопросы к оригинальной статье имеются. В вебе в целом многие идеи и предложения изначально залетают хорошо, но когда погружаешься глубже, то довольно часто бьешься об подводные камни лбом, и в данной ситуации кажется, что автор о некоторых вещах умолчал как раз для таких случаев.
Начать, вероятно, стоит с того, что пример на Реакте не совсем отражает реальность. Классовые компоненты, конечно, имеет смысл использовать в некоторых ситуациях, в таких как ErrorBoundaries или нужно отловить пропсы перед ререндером, допустим, но вот в этом конкретном примере это лишено всякого смысла. В функциональной компоненте кода на самом деле было бы меньше. Что касаемо серверной логики, то это Реакта, как библиотеки для создания интерфейса, не касается вовсе. Инкремент в целом вообще может быть создан сознательно только для работы на клиенте, в таком случае HTMX с ее постоянными запросами на сервер выглядит странно. Вероятно это предстоит обойти встраиванием ванильного js в документ, но картина уже в целом не такая радужная становится и в таком случае на клиенте js понадобится достаточно много. Если же элемент действительно нуждается в серверном взаимодействий, то да, в Реакте придется использовать вероятнее всего стороннюю библиотеку в виде RTK, но и здесь имеются вопросы. HTMX предоставляет ли возможности для улучшения UI опыта в виде optimistic updates, кеширования и прочего? А если нам нужно добавить возможности офлайн работы как в PWA? И конкретно данный момент можно раскручивать дальше в глубину. И молчу про вопросы касаемо бэка, такого типа как насколько сильно увеличится нагрузка и прочее.
Что касаемо множества зависимостей библиотек и прочего, то точно такая же проблема существует и на бэкенде. И я более чем уверен, что при HTMX действительно на клиенте зависимостей в разы меньше, но их становится больше на бэкенде. Это все равно, что переложить вещи с дивана на стол.
Написал эту стену из-за заключения в оригинальной статье, где передается посыл, дескать хайповость и трендовость Реакта послужили причиной высокой требовательности в подобного рода разработчиков, а так HTMX не хуже. Нет, это не совсем так. HTMX крут, но только в конкретных условиях, а так фича имеет ограниченные возможности в использовании и потому в нем нуждаются гораздо реже.
Можно только позавидовать серьезности вашего комментария, у меня, как разработчика заставшего эру jQuery, когда было нормой подгружать куски html, все эти рассуждения на на тему замены реакта не вызывают ощущения адекватности.
@@oWeRQ666
Времена jQuery, как мне кажется, были достаточно темными в истории веба. Всем приходилось его использовать, выбора то особо не было. Ванильный JS тогда был топорным, поскольку функционала было меньше. Но эти изменения DOM через AJAX запросы, конечно, было отличной возможностью выстрелить себе в ногу, если не отладить все по десять раз убив много часов. И то, если интернет слабый, а тогда он у многих как раз был таким, то пользователь вообще ничего не получал из этих запросов. И молчу про синтаксис с цепочками chaining вызовов - это лично меня заставляло пускать кровавые слезы, глядя на код jQuery. В общем да, некоторая аналогия прослеживается.
С появлением React-а ситуация в Вебе изменилась в лучшую сторону. Я когда в первый раз его пощупал, то у меня случился взрыв мозга. Создавать проекты стало проще. Хотя вспоминая старый реакт в связке со старым редаксом... приходилось писать очень много бойлерплейта, прокидывать компоненты в Hoc, связывая с connect, прописывать mapStateToProps, писать константы для экшенов в свиче. Да и сами классовые компоненты заставляли писать много шаблона, поскольку хуков тогда еще не придумали для использования логики определенного функционала повторно. А ведь до сих пор ходит бугурт на тему того, что переход на функциональный подход стало ошибкой! Но в целом, даже учитывая этот недостаток, все равно это было лучше, чем писать код на jQuery.
React универсальный инструмент, который еще долго будет жить. Но мне лично не совсем нравятся последние изменения в ее экосистеме. То разрабы Remix добавят кучу ненужного функционала в react-router-dom, то разрабы Next упарываются по добавлению бэкенд фичей на фронт. Не спорю, что добавленные ими возможности имеют право на существование в некоторых ситуациях, но все же в большинстве случаев это все можно было отыграть как-то иначе - фичи для роутинга, например, как аддон отдельно в пакет погрузить, а не пихать в общую либу. И в целом стоило бы больше сосредоточиться на фронте.
Я вдобавок к тому же немного устал бороться с механизмом Reconciliation в реакте, потому недавно начал пытаться щупать другие фреймворки, чтобы освежиться так сказать. Пока колупаю Astro, тоже довольно нишевый инструмент и React не заменит (React в целом еще долгое время не смогут заменить ), но выглядит свежо и интересно.
Спасибо! Классное видео
Хотелось бы видео про веб компоненты теперь
Примерно как вынести унитаз на улицу. В доме не воняет, но все вокруг тонет в говне.
4:04 Кого автор пытается обмануть? Классовые компоненты на React уже очень-очень давно никто не использует
Вы только этот бред заметили?😂
Итого: Используй HTMX если ты бекендер и тебе нужно в соло написать средней сложности сайт.
И наоборот: используй Express, если ты фронтендер и тебе нужно в соло... Или даже если умеешь в фуллстек и нужно по-быстрому выкатить прототип.
@@Ardolynk хмм а что если htmx + express
Не средней, а уровня Hello World, потому что на любом реальном проекте моментально придется строить костыли.
Было бы интересно вообще про современные легковесные фреймворки типа AlpineJS.
На мониторе 27'' код еле видно, что у вас за дизайнподход такой? Т.е. людей с планшетами и телефонами вы отсеиваете за не надобностью? Вы открывали свой видос на планшете?
На телефоне и планшете можно зум сделать. На мониторе смотрел - вроде было все видно неплохо. Но учту на будущее, буду пробовать крупнее делать, где получится, спасибо
@@ListenIT_channelЗдравствуйте! При качестве видео 360 текст нечитаемый даже при масштабировании. Небольшое увеличение размера шрифта пошло бы на пользу
В смысле htmx будет работать в браузере с отключенным js
AJAX через яваскрипт работает, не?
аякс запрос джейквери - это обычный fetch js-овский под капотом.
Похоже на улучшенный Thymeleaf который также можно встраивать в HTML код
Ну, thymeleaf и ftl файлы - это обычные HTML странички, контент которых просто подставляется от сервера. Но они не заменяют SPA функциональность JS.
А тут прям что-то сильно другое.
Хотя по цели (облегчить жизнь бэкендирам) они действительно похожи
0:09 - Скиллбокс - категорически осуждаю! :)
Точно также, как и скиллфэктори, гигбрейнс, и прочие лохотроны. Такое, должно быть на законодательном уровне запрещено, с соответствующими тюремными наказаниями для главных владельцев)
Здравствуйте. Огорчены вашей позицией, но не можем не спросить, чем вызвано осуждение? Эффективность наших курсов подтверждают студенты. Например, согласно исследованию НИУ ВШЭ, 84% пользователей, завершивших обучение, находят работу по специальности, которую изучали в Skillbox.
в чем смысл комментария? перечисленные школы имеют гос. лицензии на обучение и выдают дипломы повышения квалификации гос. образца.
Та не. Это же уже проходили. MS что-то такое продвигали в конце двухтысячных. Можно было делать контролы, которые обновлялись без перезагрузки страницы. Но беда там была в управлении состоянием. Серваку нужно знать состояние клиента, а значит его надо каждый раз пересылать. Это приводило к довольно большим запросам в дополнение к ожидаемо большим ответам. И вся это обработка загружает бэкенд, который расширять будет стоить денех. Ну и главное - зачем тогда клиенту все эти гигабайты оперативы, если не для того чтобы держать там мою spa?
Майки до сих пор не потеряли надежду, Blazor имя ему, с хранением состояния на сервере и общением через вебсокет, я был крайне удивлен, что это поделие хоть и умеет выполняться на клиенте в одном из вариантов сборки в wasm, но не смотря на общую кодовую базу не умеет само общаться с беком, т.е. нет чего-то вроде trpc.
Начали за здравие, закончили за упокой. Если HTMX не заменяет React на больших проектах, нахер он там тогда нужен?!
в вопросе уже содержится ответ
для небольших проектов самое то
Я пока что то не как не вижу как он выместит React и остальные фрейм/библиотеки, по факту серверный рендеринг нужен если проект нуждается в seo оптимизации,для поисковых машин, если в конкретном проекте это не нужно то вы просто так будете выкидывать не маленькие деньги на трафик сервера и на его поддержку, ssr приложение всегда кушает больше трафика чем обычный spa, потом синтаксис и методы разработки чем то напоминают мне подход view который заставляет разрабов учить сам view и забывать про js, плюс всю логику которую front end привыкли писать теперь нужно будет писать backend разработчикам? Ну такое себе.....
Сколько бы не пытались, но реакт не только на этом строится. Самая основная его фишка это возможность легко смешать в одном месте и JS и разметку для любой фигни которую попросит этот не определившийся заказчик
Ну все - HTML программисты все таки доказали свое существование😂
Да, теперь фронтендеры будут зарабатывать 20к, а бекендеры 600к 😄
@@godai_official и только фулстек программисты спокойно смотрят на эту суету. Для фулстека нет технологий - есть только лишь путь!
Очередная поделка, которая не взлетела. Бесполезна чуть более, чем полностью.
- куцый синтаксис позволит сделать только базовые вещи, а его еще учить
- генерация кусков html на бэкенде и подгрузка аяксом чем это меньше json с чистыми данными?
Где мои комментарии, почему стерты? По какой причине?
Если вы про комментарии про замену Реакта и маленький шрифт, то они есть и отображаются, всё нормально. Если какие-то другие, то тут вопрос. Никто ваши комментарии не стирал, в спам-фильтр они не попадали.
Очень странное сравнение. Ну допустим, многое из перечисленного применимо и к Next, хотя с его SSG и кешированием уже половина поинтов отвалилось бы с производительностью, нагрузкой и первым рендером. Но есть, например, Astro. И он уже не даст в сравнении таких преимуществ, даже в сложности кода.
А использовать React для хайлоуда и говорить, как стало хорошо, когда его убрали - смешно. Зачем вы вообще его тянули в чистом виде?))
Ну и как уже говорили, бизнес логика не дематериализуется в пустоту, она просто выносится на бэк. Невероятные архитектурные достижения, очень просто все, ага
Зумеры придумали razor pages с jquery
Ничего серьезного на нем не сделать. В с запросами хожит так же много метаданных. И если на каждый чих ддосить сервер, то компания скорее обанкротится отдавать столько денег за сервера
Классы в реакте не юзают уже как лет 5, дружище, что это вообще за пример кода? А то, что ты рассказал в своем видео называется SSR, с которым React, Angular и Vue успешно взаимодействуют. И ты, конечно же прав в том, что подключить миллион библиотек с разных сайтов, вместо того чтобы использовать условный npm, где все в одном месте, контролировать кучу файлов вручную и использовать устаревшие технологии намного удобнее, чем воспользоваться сборщиком.
Даже если каким-то чудом часть рынка перейдет на это посмешище, ты действительно считаешь, что люди вернутся в блокнот и будут писать код там, отказавшись от сборщиков?
В начале года все хайпили эту библиотеку, но вроде уже давно все успокоились, вернулись к своим основным инструментам и забыли про нее. Есть ли за ней будущее?
Htmx вроде лет 15 уже
Автор почему-то заявляет, что htmx противопоставляет себя реакту и другим мастодонтам, но создатели говорят, что во многих случаях нет необходимости в логике на клиенте, и если надо добавить минимальную реактивность, может быть имеет смысл посмотреть в сторону htmx
Да, для бекендера и небольших проектов смотрится, как минимум, интересно )
надо попробовать.
Очереднной бесполезный фреймворк, который пытается выехать на аббревиатуре.
Существующий код вы куда денете? Перепишете?
Понятно, снова тот же велосипед с другими катафотами пытаются втюхать.
Мне нравится использовать htmx в комбинации с golang и библиотекой templ для него. Для CSS можно tailwind накинуть
Не думаю что в ближайшее время такая комбинация инструментов приживется на рынке, хотя мне кажется она точно может закрыть процентов 90 потребностей, но как минимум для себя попробовать стоит
Не так сложны первые 90% проекта, как вторые 90% проекта.
Боже, просто возвращайтесь на чистый html + jquery я честно не вижу смысла если хотите легкости и минимум кода
С одной стороны NextJS, в который мы подтягиваем бэкэнд и можем написать небольшую апишку, а с другой HTMX, который подтягивается уже В бэкэнд.
Шо то, шо то несёт так себе. Нужно писать всё на php, ребята, и не париться.
Серверные компоненты намного интереснее чем кажется на первый взгляд, это далеко не то же самое, что гонять html.