Автор zt: типизированные HTML-шаблоны на Zig ловят опечатки ещё на компиляции
Type-safe HTML templating in Zig
Лукаш Лалински, автор библиотек zio и Dusty, представил zt — порт подхода Templ на Zig. Шаблоны транспилируются в Zig-код во время zig build, поэтому все параметры типизированы, значения экранируются по умолчанию, а ошибки вроде {u.nmae} становятся ошибками компилятора. Генерация идёт напрямую в std.Io.Writer без аллокаций, поддерживаются компоненты, @children и управляющие конструкции на чистом Zig.
Что мне нравится больше всего — ошибки шаблонов это просто ошибки компилятора Zig.
- solatic
Обожаю такой дизайн, особенно потому что он использует преимущества сборочной цепочки Zig; думаю, пересборки будут достаточно быстрыми, чтобы по сути получить горячую перезагрузку в стиле JS в цикле разработки. Теперь нам просто нужен https://github.com/air-verse/air для Zig (в Ziex есть встроенный в его CLI, но это только для Ziex)...
С нетерпением жду бенчмарков!
- pjmlp
> Два года назад я взялся за Zig и никогда бы не подумал, что буду рассматривать веб-разработку на таком низкоуровневом языке.
Это забавное замечание, учитывая, что автор начинал в 2000 году в веб-разработке и с PHP 3.0.
Я начал в 1997 году, у нас на курсе по распределённым системам были упражнения по написанию CGI на Perl и C.
С 1999 по 2001 год большая часть веб-разработки у моего работодателя велась на Tcl и C, ASP, естественно, был смесью VB и C++ COM-компонентов, и было ещё весело писать все эти расширения mod_something для Apache и модули IIS ISAPI, естественно, на C и C++.
Ах да, Microsoft также выпускала ATLServer, потому что кто бы не захотел использовать ATL для веб-разработки, в то время как Borland/Inprise выпускала похожие штуки для Delphi и C++ Builder.
Сам PHP в версии 3.0 — это было ещё время, когда в нём почти не было встроенной функциональности, так что было вполне обычным писать расширения на C.
Так что довольно иронично читать, что возвращение к тому, как всё было, до того как медленные скриптовые языки захватили всё в 2010-х, — это то, о чём никто не думал.
- stefs
я также использую «типобезопасный» шаблонизатор (для Kotlin, в виде плагина Gradle) собственной разработки, который работает наоборот — вместо внедрения класса модели в шаблон генерируется класс шаблона, принимающий все значения как параметры.
то есть MyTemplate.tpl.html
{if $foo}hello world, {$myname}!{else}goodbye, world.{/if}
создаёт класс Kotlin, который можно использовать так:
MyTemplate(
foo = true,
myname = "bar"
).toString()
самый большой плюс для меня в том, что таким образом есть полная, бесплатная поддержка IDE, мне не нужно писать дополнительные view models, если маппинг не 1:1, и производительность довольно хорошая, потому что в итоге нет парсинга/компиляции/интерпретации во время выполнения, кроме базовых вещей JDK (хотя есть и более быстрые движки).
https://codeberg.org/h34tnet/tempolin
предупреждение: пока что я единственный пользователь, так что не используйте это в продакшене. также я сейчас работаю над некоторыми улучшениями, которые ещё не запушены.
- fergie
W3C: Почему мы не можем просто иметь <includes src="./header.html"> и на этом закончить?
- weitzj
Спасибо за статью. Я помню, как использовал шаблоны Google Soy примерно 10 лет назад. Думаю, это похоже на то, что используется сейчас, например, когда вы делаете шаблоны Helm или Go Templates.
Там встроено экранирование HTML, экранирование JavaScript и т.д.
Может, есть обёртка для Zig вокруг Google soy?
Требования: