Есть небольшой JS-шаблонизатор для HTML. Он является, так сказать, рантаймовым, т.е. работает на лету у юзера в браузере.
В какой-то момент захотелось сделать дизайн-таймовую версию для встраивания в пайплайн. Оптимально — в виде утилиты командной строки, которую натравливаешь на файлы, а она генерирует другие файлы. Смысл в том, чтобы избежать ненужного дёрганья интерфейса после загрузки. (Для этого ещё используют плейсхолдеры, но я не хочу).
На самом же деле, я хочу позже научить шаблонизатор исполнять ряд фокусов, которые в рантайме просто не сделаешь. (Например, когда нужен доступ к shadow DOM, а он не предусмотрен, как и режим управления этим доступом. Это и iframe, и даже некоторые тонкости при работе с SVG).
Шаблонизация, по сути, это когда в строке находится подстрока, маркированная как шаблон, в ней заменяются фрагменты, маркированные как переменные, и затем результат вставляется вместо подстрок, маркированных как заглушки. Казалось бы, string.replace и дело в шляпе.
Однако мой шаблонизатор работает на селекторах. Что означает, что нужно по исходной строке с HTML воссоздать DOM и отобрать нужный узел по классам/атрибутам/позиции в дереве, а потом уже превратить его в подстроку и уже дальше её обрабатывать. В браузере это делать легко: браузер строит DOM за меня, а мне даёт browser API на JS. А что делать в утилите командной строки?
Можно взять библиотеку на C++. Но какие-то они все старые. У одной из рекомендованных на SO дата последнего коммита — 20 лет назад. То есть, о всяких :has() и :is() можно не мечтать, гы-гы.
Можно взять библиотеку на JS, и запускать код через QuickJS. Одну из них написал Резиг для jQuery. Но с тех пор все перешли на нативную реализацию в querySelector(), и проект, я так понимаю, заглох. Только не надо забывать, что построение DOM, которое умеет браузер, в стандарт EcmaScript не входит.
Можно взять Хромиум (CEF) и встроить в утилиту командной строки. Будет классическое "Две метров грузят текста триста байт". Но вай бы и нот. Тогда хоть можно будет периодически обновлять Хромиум и получать новый синтаксис селекторов.
Можно воспользоваться WebView2. И получить в комплекте зависимость от Windows 11. Хотя сама утилита будет маленькая.
Почему-то мне не нравится ни один из этих вариантов.
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
Re: Чем строить DOM на C++ или pure JS (без браузера)?
Здравствуйте, Alekzander, Вы писали:
A>Почему-то мне не нравится ни один из этих вариантов.
IMHO ты занимаешься какой-то самобытной херней.
По виду твоя "шаблонизация" похожа на банальный server-side rendering (compile-time rendering), теперь это умеют вообще все генераторы статики.
Я сам использую astro в основном.
Но независимо от этого можешь попробовать посмотреть на tauri это такой электрон, но в 20 раз меньше, на встроенном WebView2 (web view WebKit для linux)
Здравствуйте, bnk, Вы писали:
bnk>IMHO ты занимаешься какой-то самобытной херней. bnk>По виду твоя "шаблонизация" похожа на банальный server-side rendering (compile-time rendering), теперь это умеют вообще все генераторы статики.
Пользователи не хотят из командной строки ставить пакеты и настраивать среду сначала на своём компьютере, а потом и на сервере. Пользователи хотят расширение в браузер, которое позволило бы сразу отображать результат, и ещё программу, которой можно было бы зафиксировать результат в виде файлов для последующего копирования (на сервер, например).
Просто я, как инженер, сразу подумал, что неплохо было бы дополнительно накидать фичей. Типа, всё равно же половина продвинутых юзеров пользуется каким-нибудь Мусташем, который на самом деле не нужен, и который можно было бы заодно круто оптимизировать. Отсюда и вопрос. Но я пока ещё даже не решил, насколько эти хотелки востребованы у тех юзеров, которые тихо-мирно педалят какую-нибудь HTML-справку (даже не всегда онлайновую).
Я бы и сам нашёл применение. Вот, например, как профессионал профессионалу.
Как лучше всего делать векторную библиотеку? Чтобы 1) хранить в одном месте, 2) брать только используемое, 3) подставлять в вёрстку естественным образом, 4) можно было использовать в интерфейсах. Я пробовал, наверно, всё. Шрифты. Data URI. Фонт-сабсеттинг
. Набор <symbols>. И как ни крути, везде или дудочка, или кувшинчик. Чего-нибудь, да не хватает. Вот, например, ты знал, что <use> может ссылаться на элемент внешнего файла (оформленный как <symbol>)? Т.е. <use href="lib.svg#icon1">. Казалось бы, вот оно, счастье: ты раскладываешь вектор по библиотекам, библиотеки по файлам (интересно, кстати: визивижные редакторы такое поддерживают вообще? и что они покажут?), а в результате у тебя одна библиотека на все файлы с разметкой, удобная подстановка по идентификатору элемента, элемент можно дополнительно стилизовать (обводки, подчёркивания и т.п.) через CSS, и ещё получается естественное кеширование (файлы же). Однако, если бы всё было так просто, было бы неинтересно. Оказывается, что viewBox отдельных элементов не определяет intrinsic aspect ratio этого элемента. Его вообще нельзя определить! Понимаешь, что это значит? Ты после этого не можешь написать класс .inline { height: 1em; }, чтобы вставлять символы в текст (вопросы accessibility для упрощения мы тут не рассматриваем), потому что ширина не будет рассчитываться из пропорций. И это возвращает нас в 1995 год, когда надо было указывать атрибуты width и height для каждого <img>.
Разные вумные дядьки с 100К+ плюсов на стековерфлоу думали-думали, и пришли к единому мнению: придётся копировать viewBox внутрь <use>, только тогда он начнёт определять пропорции. Я спросил: а ничего, что для <svg> не существует аналога shadowrootmode="open" (как у <template>), и, следовательно, способа программно доступиться до этого самого viewBox? Дядьки ещё подумали и сказали: пиши парсер. А ты говоришь: не пиши парсер. Кому верить?
И это, на самом деле, далеко не первый случай, когда парсер и построение DOM'а ДО загрузки в браузер круто выручило бы. Это если посмотреть на реальные задачи. Даже если у тебя есть сервер, и генератор статики, как ты бы ими воспользовался для именно этой задачи?
bnk>Но независимо от этого можешь попробовать посмотреть на tauri это такой электрон, но в 20 раз меньше, но на встроенном WebView2 (и WebView для linux)
bnk>У них есть, в том числе, headless webdriver который можно использовать как CLI в том числе bnk>https://tauri.app/develop/tests/webdriver/
Вот это интересно. Только сразу задам вопрос: это всё можно вкомпилировать в один исполняемый файл, который под вынь цепляется к WebView2, а под линь к WebView? Я хреновый линуксоид, даже не знал, что под linux (не Андроид) вообще есть какой-то универсальный WebView.
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
Здесь я не уверен, видимо у тебя задача специфическая, и трудные времена требуют трудных решений
bnk>>Но независимо от этого можешь попробовать посмотреть на tauri это такой электрон, но в 20 раз меньше, но на встроенном WebView2 (и WebView для linux) bnk>>У них есть, в том числе, headless webdriver который можно использовать как CLI в том числе bnk>>https://tauri.app/develop/tests/webdriver/
A>Вот это интересно. Только сразу задам вопрос: это всё можно вкомпилировать в один исполняемый файл, который под вынь цепляется к WebView2, а под линь к WebView? Я хреновый линуксоид, даже не знал, что под linux (не Андроид) вообще есть какой-то универсальный WebView.
Вообще оно для того, чтобы заворачивать сайт кроссплатформенно (ну т.е. чтобы в результате был "EXE/MSI/DEB", но без оверхеда CEF, т.е. используется системный web view).
На linux используется WebKitGTK насколько я понимаю (устанавливается как пакет), на винде WebView2 (по умолчанию он только на Win11, до этого все равно ставить)
В смысле оно делает инсатллятор, который при необходимости ставит WebView2 или что там надо. Не так надежно как CEF/электрон, но сильно меньше по размеру.
Насчет того чтобы тул для обработки шаблонов сделать и он крросплатформенно работал я не знаю. Ну в один файл точно не получится, файла будет как минимум два.
