Старый ангуляр - это фреймворк. Размер берётся не самого модуля, а тех файлов, которые хранятся на сервере. HMPL - это язык шаблонов. Вы можете создать отдельный файл и писать там дополненную HTML разметку для простой работы с сервером, при это работая также с данными (можно генерировать RequestInit)
"сдел клон, в данном случае React шаблонов и т.п. технологий" - да, клон одного, второго, третьего, пятого и десятого. Телеграм - это клон ватсапа, ватсап - это клон icq, discord - это клон скайпа. Знаю я такой подход. Технологии должны быть основаны, в большинстве случаев, уже на существующих концепциях и методах, придуманных заранее кем-то. Я постараюсь быть самокритичным к себе и проекту, поэтому сделаем нормально. Про "имеет хоть какой-то смысл" - это вообще отдельный разговор в том смысле, что тогда людям вообще не надо ничего делать и просто сидеть и кайфовать. Во всём есть смысл, даже в проектах, которые были изначально плохи. На основе их кода может вырасти что-то более стоящее. Так и в науке, медицине да и вообще в любых сферах.
Типо, нахрена вообще HMPL нужен, я вот сидел, хотел сделать что-то типа языка шаблонов после cample. Я вижу, что с развитием server-side renderingа и вообще сервероориентированной разработкой - это реально будущее создания сайтов. Я вот смотрю модули, которые есть, и вижу, что у HTMX идея как раз классная, но реализация - это просто кринж какой-то. Типо, как я должен всерьёз это в проекте использовать? По началу, HMPL был чем-то похож на HTMX, но потом я просто это всё тестировал и это невероятно просто неудобным оказалось. Мне вообще это не нравилось, поэтому теперь сделано то, что я действительно хотел. Я не знаю, но по мне вот это:
в идее сервероориентированности ну прям максимально удобно. Типо, хочешь отдельным файлом и не с javascript - пожалуйста - подключай лоадер для вебпака и кайфуй. Нужно настроить нормально RequestInit? Так вот, фигачишь функцию, получаешь конкретный элемент и делай что хочешь. Могу даже вспомнить работу с Яндекс картами, типо когда с api их работаешь, то там вообще кайф идёт от того, что всё контролируешь. Ну, типо я сделал просто язык шаблонов вот как хотел, реально мечта в разработке, что прям мне лично нравится при работе с модулями. Хочешь, подключай к любому фреймворку, библиотеке и др. там всё через javascript удобно настроить. Хочешь, делай 1000 узлов с серверным HTML в цикле. Вообще, супергибко, никакой нахер alpine.js или ещё 100 пакетов в дополнение просто не нужны. С микрофронтендами - да вообще без проблем. Каждый instance - это отдельная сущность, независимая, просто хоть во Vue компонент пихай, хоть в тесты - вообще по барабану.
Ладно, я понял, я просто не шарю за "нормализацию" XMLHTTPRequest в 2024 году. Сколько бы не было рассуждений на тему HTMX, но видно же код. Да, это удобно - я не спорю, да новый подход, тут тоже не спорю, да только вот не гибко, и то, что выдают за "IE13 совместимость", на практике же просто завлекалово. Это всё равно что выпускать программу на макбуки последние и хвастаться, что на мак ос пантере запуститься программа. Добавили бы хоть булеву функцию, чтобы поддерживать "новый" стандарт. Даже 2.0.3 версия, и то на XMLHTTPRequest. В fetch там кучу новых методов работы с сервером в новых EcmaScript введут, а мне что делать с этим как клиенту? Радоваться до усрачки, что я выбрал расхайпленный инструмент и теперь сижу придумываю, миксую там пакеты, чтобы хоть как-то заработало нормально? Ладно, пускай даже так, но всё таки если мы берём маломальски бизнесовый сайт, то как это вообще внедрять нормально? Про микрофронтенды я молчу, типо как это реализовать, когда direct DOM только? Как вот настраивать я сервер должен, если у него для одной части одни настройки расширенные, а на другой мне простоту наводить спецом для htmx?
Мне просто всё это не нравится. Я вижу, что идея классная и, на самом деле, прорывная, но как это реализовано, типо лол, в 2024 году стандарт с 2000 года используем. Ща ещё Object.assign и defineProperty вместо спред оператора и прокси будем использовать, вот красота. Либо, функцию конструктор вместо класса, тоже вот круто.
Поправил примеры с HTMX - спасибо! По поводу того, что не знаю, зачем HTMX использовать, может оно и так. Если работать с сервером, то иногда требуются дополнительные настройки, современные функци, идующие с fetch, и ещё плюшки работы с javascript и DOM деревом. HTMX упрощает в этом смысле работу с сервером, что всего по минимуму, но на практике, когда хочется чего-то большего, то библиотека выдаёт свой потолок вот этими упрощениями.
Для сокращения размеров файлов, скачиваемых на клиенте. От этого всё идёт. Условно, скачать 1 мб HTML и потом 20 мб с css и html с сервера быстрее, чем 21 мб сразу качать.
Да, вы правы. Надо поработать над лендингом. Кнопка Demo Sandbox вроде есть на главной для примера, но, этого конечно мало + бенчмарков таких я не делал, но можно конечно сделать, но это всё таки не фреймворк, ну, тоже можно энивей. Side by side делаю тут - https://hmpl-lang.github.io/blog/blog/2024/08/09/how-to-reduce-javascript-file-size-on-client.html, но это инфа внутри блога находится, так что не факт, что это кто-то увидит из потенциальных юзеров
Спасибо за отзыв! На мои задачи уже всё равно, строчка в резюме мне ничего не даст, учитывая опыт работы. На скиллы и прочее тоже уже всё равно. Я не рассматриваю уже данный проект как "для образовательных целей", потому что и так много таких проектов сделал. На ютубе их воз и маленькая тележка.
Однако серьезно тянуть это в одиночку, шлифовать, документировать для остальных юзеров при условии конкурентов с большим коммьюнити и инфраструктурой довольно бесполезно будет
Да пофиг на конкурентов. Сделаем крутой язык шаблонов и будет красиво. Ща, ишьюзы создам и, если хотите, то можете взять и помочь, проблем в этом вроде как нету. Если что, сам сделаю функционал. Это не фреймворк, где миллион функционала (буквально), так что это вполне возможно.
HMPL пока не поддерживает кеширование UI (в будущих версиях это 100% будет). То-есть, когда вы будете кликать по кнопке, тот элемент, где располагается объект запроса, будет перерисовываться, даже если HTML один и тот же. То-есть, если с сервера придёт <div></div>два раза, то это будет два разных узла. Родительский элемент не будет перерисовываться заново. По скорости отрисовки - почти моментальная. Там из алгоритма просто цикл по элементам и добавление их в DOM. Это немного другое, если мы берём алгоритм, который используется в циклах по элементам, связанным данными (когда рендерится список и указываются ему ключи), там алгоритм в 100 раз сложнее, но он к языку шаблонов не относится. Его пока не нужно делать, но даже если понадобиться, то можете быть уверены, что это будет одна из самых быстрых реализаций!
Можно сказать в двух словах, конечно, по поводу ключей. Я в старой статье как раз так и рассказал, но, потом подумал, что данная тема чуть интереснее и можно рассказать побольше. Благо там есть что рассказать.
В таблице располагается кнопка "Which frameworks?" нажав на которую вы сможете сравнить фреймворк с любыми фреймворком или библиотекой, располагающимися там.
Старый ангуляр - это фреймворк. Размер берётся не самого модуля, а тех файлов, которые хранятся на сервере. HMPL - это язык шаблонов. Вы можете создать отдельный файл и писать там дополненную HTML разметку для простой работы с сервером, при это работая также с данными (можно генерировать RequestInit)
Он не совсем решает, потому что запросы идут на клиенте. Это язык шаблонов, а то - фреймворк.
"просто хотелось как то себя проявить.))" - я не знаю, типо к чему вообще эти скобочки, если в любой профессии люди хотят сделать что-то.
"сдел клон, в данном случае React шаблонов и т.п. технологий" - да, клон одного, второго, третьего, пятого и десятого. Телеграм - это клон ватсапа, ватсап - это клон icq, discord - это клон скайпа. Знаю я такой подход. Технологии должны быть основаны, в большинстве случаев, уже на существующих концепциях и методах, придуманных заранее кем-то. Я постараюсь быть самокритичным к себе и проекту, поэтому сделаем нормально. Про "имеет хоть какой-то смысл" - это вообще отдельный разговор в том смысле, что тогда людям вообще не надо ничего делать и просто сидеть и кайфовать. Во всём есть смысл, даже в проектах, которые были изначально плохи. На основе их кода может вырасти что-то более стоящее. Так и в науке, медицине да и вообще в любых сферах.
Хорошо. Надо будет ещё с мемасиками ознакомиться
*Булеву переменную, какую функцию
Типо, нахрена вообще HMPL нужен, я вот сидел, хотел сделать что-то типа языка шаблонов после cample. Я вижу, что с развитием server-side renderingа и вообще сервероориентированной разработкой - это реально будущее создания сайтов. Я вот смотрю модули, которые есть, и вижу, что у HTMX идея как раз классная, но реализация - это просто кринж какой-то. Типо, как я должен всерьёз это в проекте использовать? По началу, HMPL был чем-то похож на HTMX, но потом я просто это всё тестировал и это невероятно просто неудобным оказалось. Мне вообще это не нравилось, поэтому теперь сделано то, что я действительно хотел. Я не знаю, но по мне вот это:
в идее сервероориентированности ну прям максимально удобно. Типо, хочешь отдельным файлом и не с javascript - пожалуйста - подключай лоадер для вебпака и кайфуй. Нужно настроить нормально RequestInit? Так вот, фигачишь функцию, получаешь конкретный элемент и делай что хочешь. Могу даже вспомнить работу с Яндекс картами, типо когда с api их работаешь, то там вообще кайф идёт от того, что всё контролируешь. Ну, типо я сделал просто язык шаблонов вот как хотел, реально мечта в разработке, что прям мне лично нравится при работе с модулями. Хочешь, подключай к любому фреймворку, библиотеке и др. там всё через javascript удобно настроить. Хочешь, делай 1000 узлов с серверным HTML в цикле. Вообще, супергибко, никакой нахер alpine.js или ещё 100 пакетов в дополнение просто не нужны. С микрофронтендами - да вообще без проблем. Каждый instance - это отдельная сущность, независимая, просто хоть во Vue компонент пихай, хоть в тесты - вообще по барабану.
Ладно, я понял, я просто не шарю за "нормализацию" XMLHTTPRequest в 2024 году. Сколько бы не было рассуждений на тему HTMX, но видно же код. Да, это удобно - я не спорю, да новый подход, тут тоже не спорю, да только вот не гибко, и то, что выдают за "IE13 совместимость", на практике же просто завлекалово. Это всё равно что выпускать программу на макбуки последние и хвастаться, что на мак ос пантере запуститься программа. Добавили бы хоть булеву функцию, чтобы поддерживать "новый" стандарт. Даже 2.0.3 версия, и то на XMLHTTPRequest. В fetch там кучу новых методов работы с сервером в новых EcmaScript введут, а мне что делать с этим как клиенту? Радоваться до усрачки, что я выбрал расхайпленный инструмент и теперь сижу придумываю, миксую там пакеты, чтобы хоть как-то заработало нормально? Ладно, пускай даже так, но всё таки если мы берём маломальски бизнесовый сайт, то как это вообще внедрять нормально? Про микрофронтенды я молчу, типо как это реализовать, когда direct DOM только? Как вот настраивать я сервер должен, если у него для одной части одни настройки расширенные, а на другой мне простоту наводить спецом для htmx?
Мне просто всё это не нравится. Я вижу, что идея классная и, на самом деле, прорывная, но как это реализовано, типо лол, в 2024 году стандарт с 2000 года используем. Ща ещё Object.assign и defineProperty вместо спред оператора и прокси будем использовать, вот красота. Либо, функцию конструктор вместо класса, тоже вот круто.
Поправил примеры с HTMX - спасибо! По поводу того, что не знаю, зачем HTMX использовать, может оно и так. Если работать с сервером, то иногда требуются дополнительные настройки, современные функци, идующие с fetch, и ещё плюшки работы с javascript и DOM деревом. HTMX упрощает в этом смысле работу с сервером, что всего по минимуму, но на практике, когда хочется чего-то большего, то библиотека выдаёт свой потолок вот этими упрощениями.
Но, есть много ньюансов с кешированием, клиентскими данными, быстротой разработки и другим. Это просто быстрый ответ на вопрос.
Для сокращения размеров файлов, скачиваемых на клиенте. От этого всё идёт. Условно, скачать 1 мб HTML и потом 20 мб с css и html с сервера быстрее, чем 21 мб сразу качать.
Спасибо! Пошла жара). Если что, разбирал вот тут https://hmpl-lang.github.io/blog/blog/2024/08/10/differences-between-hmpl-and-htmx.html
Да, вы правы. Надо поработать над лендингом. Кнопка Demo Sandbox вроде есть на главной для примера, но, этого конечно мало + бенчмарков таких я не делал, но можно конечно сделать, но это всё таки не фреймворк, ну, тоже можно энивей. Side by side делаю тут - https://hmpl-lang.github.io/blog/blog/2024/08/09/how-to-reduce-javascript-file-size-on-client.html, но это инфа внутри блога находится, так что не факт, что это кто-то увидит из потенциальных юзеров
Спасибо за отзыв! На мои задачи уже всё равно, строчка в резюме мне ничего не даст, учитывая опыт работы. На скиллы и прочее тоже уже всё равно. Я не рассматриваю уже данный проект как "для образовательных целей", потому что и так много таких проектов сделал. На ютубе их воз и маленькая тележка.
Да пофиг на конкурентов. Сделаем крутой язык шаблонов и будет красиво. Ща, ишьюзы создам и, если хотите, то можете взять и помочь, проблем в этом вроде как нету. Если что, сам сделаю функционал. Это не фреймворк, где миллион функционала (буквально), так что это вполне возможно.
https://github.com/hmpl-lang/hmpl/issues/1 - добавил в issue проблему кеширования
HMPL пока не поддерживает кеширование UI (в будущих версиях это 100% будет). То-есть, когда вы будете кликать по кнопке, тот элемент, где располагается объект запроса, будет перерисовываться, даже если HTML один и тот же. То-есть, если с сервера придёт
<div></div>два раза, то это будет два разных узла. Родительский элемент не будет перерисовываться заново. По скорости отрисовки - почти моментальная. Там из алгоритма просто цикл по элементам и добавление их в DOM. Это немного другое, если мы берём алгоритм, который используется в циклах по элементам, связанным данными (когда рендерится список и указываются ему ключи), там алгоритм в 100 раз сложнее, но он к языку шаблонов не относится. Его пока не нужно делать, но даже если понадобиться, то можете быть уверены, что это будет одна из самых быстрых реализаций!Можно сказать в двух словах, конечно, по поводу ключей. Я в старой статье как раз так и рассказал, но, потом подумал, что данная тема чуть интереснее и можно рассказать побольше. Благо там есть что рассказать.
Да, это текстовая версия 20 минутного ролика
Исправляю ошибки в тексте.
В таблице располагается кнопка "Which frameworks?" нажав на которую вы сможете сравнить фреймворк с любыми фреймворком или библиотекой, располагающимися там.