Type-sicheres HTML-Templating in Zig
Type-safe HTML templating in Zig
Der Entwickler Lukas Lalinsky stellt zt vor, eine an Templ für Go angelehnte Template-Engine für Zig. Templates werden zur Build-Zeit in Zig-Code transpiliert, wodurch alle Parameter typgeprüft sind und Fehler bereits beim Kompilieren auffallen. Dynamische Werte werden standardmäßig HTML-escaped, gefährliche URL-Schemata blockiert. Die Ausgabe erfolgt direkt in einen std.Io.Writer – ohne Allokationen. Ein Syntaxdetail ist noch offen.
Was mir am besten gefällt, ist, dass Template-Fehler einfach Zig-Compiler-Fehler sind.
- solatic
Ich liebe dieses Design, besonders weil es die Zig-Build-Chain nutzt; ich erwarte, dass Re-Builds schnell genug sein werden, dass man im Entwicklungszyklus im Grunde JS-artiges Hot Reloading bekommt. Jetzt brauchen wir nur noch https://github.com/air-verse/air für Zig (Ziex hat eines in seine CLI eingebaut, aber das ist nur für Ziex)...
Ich freue mich darauf, ein paar Benchmarks zu sehen!
- pjmlp
> Vor zwei Jahren habe ich Zig angefangen, und ich hätte mir nie vorstellen können, dass ich Webentwicklung in einer so low-level Sprache in Betracht ziehen würde.
Das ist eine ziemlich lustige Bemerkung, wenn man bedenkt, dass der Autor im Jahr 2000 mit Webentwicklung angefangen hat, und zwar mit PHP 3.0.
Ich habe 1997 angefangen, unser Kurs für verteilte Systeme hatte Übungen zum Schreiben von CGIs in Perl und C.
Zwischen 1999 und 2001 war der Großteil der Webentwicklung bei meinem Arbeitgeber in Tcl und C, ASP war natürlich eine Mischung aus VB und C++ COM-Komponenten, und es machte auch Spaß, all diese mod_something Apache-Erweiterungen und IIS ISAPI-Module zu schreiben, natürlich in C und C++.
Ah, Microsoft lieferte auch ATLServer aus, denn wer würde nicht ATL für die Webentwicklung nutzen wollen, während Borland/Inprise ähnliches Zeug für Delphi und C++ Builder auslieferte.
PHP selbst hatte in 3.0 noch die Zeit, in der es kaum viel eingebaute Funktionalität hatte, also war es ziemlich üblich, Erweiterungsmodule in C zu schreiben.
Es ist also irgendwie ironisch zu lesen, dass die Rückkehr zu der Art und Weise, wie es früher war, bevor die langsamen Skriptsprachen in den 2010ern die Übernahme starteten, etwas ist, worüber niemand nachgedacht hat.
- stefs
ich benutze auch eine „typsichere“ Template-Engine (für Kotlin, als Gradle-Plugin) nach meinem eigenen Design, die den umgekehrten Weg geht – statt eine Model-Klasse in das Template einzubetten, wird eine Template-Klasse generiert, die alle Werte als Parameter entgegennimmt.
d.h. MyTemplate.tpl.html
{if $foo}hello world, {$myname}!{else}goodbye, world.{/if}
wodurch eine Kotlin-Klasse erzeugt wird, die so verwendet werden kann:
MyTemplate(
foo = true,
myname = "bar"
).toString()
der größte Vorteil für mich ist, dass es so volle, kostenlose IDE-Unterstützung gibt, ich keine zusätzlichen View-Models schreiben muss, wenn das Mapping nicht 1:1 ist, und die Performance ziemlich gut ist, weil am Ende kein Runtime-Parsing/Compiling/Interpreting außer dem Baseline-JDK-Zeug stattfindet (obwohl es sogar noch schnellere Engines gibt).
https://codeberg.org/h34tnet/tempolin
Warnung: bisher bin ich der einzige Nutzer, also nicht in Produktion verwenden. außerdem arbeite ich gerade an einigen Verbesserungen, die noch nicht gepusht wurden.
- fergie
W3C: Warum können wir nicht einfach <includes src="./header.html"> haben und fertig?
- weitzj
Danke für den Artikel. Ich erinnere mich, dass ich vor etwa 10 Jahren Google Soy Templates benutzt habe. Ich denke, das ist ähnlich zu dem, was heute verwendet wird, wenn man zum Beispiel Helm-Templates oder Go Templates erstellt.
Es hat das HTML-Escaping, JavaScript-Escaping usw. eingebaut.
Gibt es vielleicht einen Zig-Wrapper für Google Soy?