> Two years ago, I picked up Zig, and I’d never have imagined I’d be considering web development in such a low-level language.
This is kind of funny remark, given that the author started in 2000 in Web development, and with PHP 3.0.
I started in 1997, our distributed systems class had exercises to write CGIs in Perl and C.
Between 1999 and 2001, most Web development at my employer was in Tcl and C, ASP was naturally a mix of VB and C++ COM components, and there was also the fun to write all those mod_something Apache extensions, and IIS ISAPI modules, naturally in C and C++.
Ah, Microsoft was also shipping ATLServer, because who wouldn't want to use ATL for Web development, while Borland/Inprise was shipping similar stuff for Delphi and C++ Builder.
PHP itself, in 3.0, it was still the time that it hardly had much functionality builtin, so it was quite common to write extension modules in C.
So it is kind of ironic to read coming back to the way things were, before the slow scripting languages takevover in the 2010's, is something no one thought about.
hermitdev 1 days ago [-]
I interned at a Fortune 500 starting in 2000.
Most of my work was on an intranet page used for tracking internal servers, apps and databases. One of cool (at the time) features I implemented was a server-rendered ping of the servers shown on the dashboard. We're talking usually a few hundred at a time. The site ran on IIS & NT 4, written in VBS & ASP. (I think my first server was actually a dual Alpha chip, wasn't even x86, sure as hell was way before x64).
To implement the ping functionality (yes, we're talking just a straight ICMP ping), I ended up doing a COM server, written in C++, called into it from the VBS side. Eventually, .Net came out, and once .Net Framework 1.1 was released, I was able to convince my boss to let me rewrite the whole site in ASP.Net. I ditched the C++ COM object and was able to do it in C# with raw sockets (and appropriate permissions, which was a bit of a pain to get right at the time, before google and stackoverflow were around to help). Getting the C++ COM object working was actually easier because at least the MSDN library (the entire stack of CDs & DVDs it was on) had extensive documentation. The .Net side was good initially, but it just did not have the same depth as the C++ side already had at that point.
lukaslalinsky 2 days ago [-]
For me web was always about these scripting languages. Even in the CGI days, I learned to use Perl just enough to do a simple web form. I kind of associated the domain with GC languages, as this kind of work usually involves many temporary strings and dictionaries. In fact, the first compiled language I ever used for a web project was Go, and even that was due to the fact that it has garbage collector.
pjmlp 2 days ago [-]
Fair enough, different life experience then.
kccqzy 1 days ago [-]
Google probably still has a large chunk of web development happening in C++. Probably less than Java but still lots of code.
flossly 1 days ago [-]
I kinda like kotlinx.html in Kotlin; it's an eDSL for writing HTML in actual Kotlin. So I can put break points in my template code. It's a tiny bit slower than string-with-some-interpolation type of template libraries; but it's so little that it's a price I'm willing to pay. Also there's more impact on compile times than with string-with-some-interpolation type of template libraries.
The typesafety you get is what you already have in Kotlin, and there a little extra in that you cannot nest certain HTML-elements in certain other elements (adhering to the HTML spec). You can come up with your own elements and attributes, but the ones that are in the HMTL-spec are usually available in kotlinx.html as well (and thus can be auto-completed).
A large part of this library is generated from the actual HTML spec.
Claude Code seems to have not problem writing it (I barely write templates myself these days).
I wish Kotlin was given more attention by JetBrains than the AI nonsense they keep trying to build into, its clear they are going to lose in the AI space at this rate, but Kotlin has so much more potential and its nearly ten years old at this point? Oh its 15 whoops!
solatic 2 days ago [-]
I love this design, especially as it takes advantage of the Zig build chain; I expect re-builds will be fast enough that you essentially get JS-style hot reloading in the dev cycle. Now we just need https://github.com/air-verse/air for Zig (Ziex has one built into its CLI, but that's only for Ziex)...
Looking forward to seeing some benchmarks!
fergie 2 days ago [-]
W3C: Why can't we just have <includes src="./header.html"> and be done with it?
tannhaeuser 2 days ago [-]
SGML (ISO 8879), the markup meta-language on which HTML is based, has that, as well as many other things, such as type-checked templating.
Hence HTML as a mere vocabulary making use of SGML's facilities didn't need to define its own ad-hoc mechanism.
Btw the <?php ...> construct is also derived from SGML. In SGML terms it's a "processing instruction" rather than an "entity reference", the latter being the basic means for content inclusion.
I say tragically, because XSLT was indeed the only sort-of workaround that was available for templating in the browser, even if it was limited to v1 rather than the much more useful v2 and v3.
Yes, partial refresh strategies are interesting, but its an adjacent problem.
icedchai 1 days ago [-]
In the old days, we used to emulate this with a <script> tag that did a document.write ... yes, very hacky.
fergie 15 hours ago [-]
mate, I've been a full time web developer for 26 years, plus the time I spent at uni :)
geoffmunn 2 days ago [-]
Can I introduce you to iframes? Clunky but they do exactly what you are asking for.
fergie 15 hours ago [-]
They embed webpages into other webpages and definitely have their place, and could arguably be used more, but they are definitely not a way to consolidate a single piece of HTML from constituent pieces.
SSIs are not widely supported any more, and were never a part of the HTML standard
(but yes- I used these a lot like 25 years ago)
jonatron 2 days ago [-]
From what I can tell, apache mod_include and nginx SSI are still included by default?
fergie 2 days ago [-]
Yes, but then you need php
Why is there no direct support for templating in HTML itself?
everforward 1 days ago [-]
It would tie in an additional feature with potential future incompatibilities, and it moves insecurities in templates to the client runtime where they’re more dangerous than compile/interpret time.
Eg some template feature creates a security issue and has to be disabled, which invalidates all the old HTML that used it.
There’s also just not a super great reason to do it. It’s not all that different from pre-templating like Hugo or doing it server-side like Django. You get to offload some compute, but HTML templating isn’t usually the bottleneck.
fergie 15 hours ago [-]
> It would tie in an additional feature with potential future incompatibilities
No offense but this is a bit of a non-argument that could be applied to just about any development in HTML.
> There’s also just not a super great reason to do it.
Most web dev frameworks exist in large part to solve the problem of templating. (yes, they do other stuff, but templating is the central problem that they are solving)
everforward 9 hours ago [-]
It does apply to all HTML dev, my point is more the idea that more features means more changes and more incompatible versions (and thus more strife).
HTML is actually shockingly backwards compatible. I very rarely see pages so old they won’t render. The main exception is basically exactly what I’m talking about: Flash and ActiveX, that had to be abandoned for security (and some poorly advised iframe stuff).
> Most web dev frameworks exist in large part to solve the problem of templating.
This might be an agree to disagree area. Most web dev frameworks I’ve seen exist to make dealing with state easier. They do templating because you have to put the state somewhere, but the magic is all in the state.
There are some that only do templating, but they’re pretty rare. Hugo or Jekyll come to mind, though “web dev framework” is probably overselling them.
There are also web components, which sound vaguely like what you’re talking about. They’re not crazy popular, but they exist and work. The security boundaries make it kind of a nightmare, I remember having to do something weird to inject Tailwind into them because they’re isolated from global CSS. The kind of things you have to do when securing templates at runtime instead of compile time.
alternatex 2 days ago [-]
It's a markup language for documents. If you enable templating devs are then going to ask for more. Eventually it will end up turing complete. Such is the development arc of a lot of languages.
williamdclt 1 days ago [-]
> If you enable templating devs are then going to ask for more
This might be the worst argument for anything I've read this week, there's got to be a name for this logical fallacy
spartanatreyu 19 hours ago [-]
No
It's a repeated observation that keeps coming true. DSLs have a tendency to become turing complete over time.
- It happened to wikipedia's templating language
- It happened to PHP
- It happened to mod_rewrite
- It happened to server-side includes
- etc...
It just keeps happening.
In fact it's such a problem with infrastructure teams that use yaml/json configs that you see a lack of turing-completeness being advertised as a feature (see Dhall configuration language).
williamdclt 10 hours ago [-]
I don't disagree with "DSLs have a tendency to become turing complete over time", it's a well known fact.
But "we can't give something to users because otherwise they'll ask for other stuff" is not an argument. They're _already_ asking for stuff (templating) anyway. No one is suggesting that shutting users up is a reason to implement templating, it's the trade-offs of this feature that are debated. And if it gets implement then yes, users will certainly ask for more features, the trade-offs of which can be debated.
If you think that the line for HTML features is where we already are, you can present your arguments for why (tbh I'll probably agree). But "if you enable templating devs are then going to ask for more" isn't one.
drupe 1 days ago [-]
A "slippery slope" fallacy might be what you're thinking of.
vulcan01 1 days ago [-]
It's almost a meta-slippery-slope fallacy, in that the specific slope is not specified; only the existence of the slope and its slipperiness is asserted.
preg_match 22 hours ago [-]
The slope we've observed over the decades is PHP. Which went from "basic HTML templating language" to "dotnet but you write $ everywhere". PHP has grown so much in complexity and feature-set that Symphony and the likes are legitimately dotnet-type. They make Go backends look low-level and primitive.
stefs 2 days ago [-]
i'm also using a "type safe" templating engine (for kotlin, as a gradle plugin) of my own design that goes the other way - instead of embedding a model class into the template, a template class is generated that takes all the values as parameters.
the biggest upside for me is that this way there's full, free IDE support, i don't need to write extra view models if the mapping isn't 1:1 and performance is pretty good because in the end there's no runtime parsing/compiling/interpreting except for the baseline JDK stuff (though there are even faster engines).
warning: so far i'm the only user though, so don't use it in production. also, i'm working on some improvements right now which haven't been pushed yet.
EddieRingle 23 hours ago [-]
Very neat. Almost reminds me of Android's databinding era (i.e. type-safe generated interfaces to XML Views). Though Android development quickly moved on to Compose UI, since Kotlin is expressive enough to cover all of the bases, I guess. And ever since then, I've personally grown annoyed with how much other ecosystems rely on templating. (In fact, I'm doubly annoyed that JetBrains picked YAML for Amper/Kotlin Toolchain. Since they had to add special templating to it anyway, why wouldn't they just use Kotlin or some subset?)
kitd 2 days ago [-]
Nice work. This is a good approach IMHO, and (if you need validation) also the one adopted by Templ in Go, which has a 'generate' command to do this.
codethief 1 days ago [-]
> Then I saw Ziex and I was amazed. It never occurred to me that the JSX approach could be done outside of JavaScript.
It never occurred to me, either! This is really neat! How does it work?
EDIT: Never mind, seems like it's a custom file format that gets compiled to Zig code. Still quite neat but unfortunately you lose all the IDE support.
nicoburns 1 days ago [-]
There are `rsx` macros in Rust that work with a regular `cargo build` and retain IDE support.
tancop 1 days ago [-]
That's because Zig explicitly doesn't want any kind of Rust or C style macros, so anything like this has to live in a build script most IDEs won't run. Maybe one day there will be a Zig IDE that takes advantage of the fast compiler.
I think there is a way to do syntax extensions cleanly, with a special block type like `'{ }` that gets tokenized and passed to a comptime function skipping the parser. But one of Zig's main selling points is no hidden control flow and they want to keep it that way.
christophilus 1 days ago [-]
LLMs are decent at building LSPs so, shouldn’t be a problem if this becomes popular.
nurulhudaapon 6 hours ago [-]
[dead]
fitsumbelay 1 days ago [-]
In the spirit of the author's own experienced Ch-ch-changes: I wouldn't even be reading a post like this if it weren't for agentic-coding
Sure I hack a 'Sup World in C every 100 years just to get that feeling you get when you stumble into semi-accomplishment but to consider a low-level lang executable as a product that I produce, maintain and develop expertise/taste with?
Regarding web dev in any low-level lang: once you get that there's a parenthetical "services" between the words "web" and "development", the quest for the languages that offer speed, reliability, etc becomes inevitable
seletz 12 hours ago [-]
C rrverevrrl I’ll colorectalrooo vötvötlbtvllttbp pvpbtp
weitzj 2 days ago [-]
Thank you for the article. I remember using Google Soy templates roughly 10 years ago. I think this is similar to what is used now when you make Helm templates for example or Go Templates.
It has the html escaping, JavaScript escaping etc built in.
Is there maybe a Zig wrapper for Google soy around?
lukaslalinsky 2 days ago [-]
Fun fact, I actually also had a fork of the Google Closure Templates that added support for Python. I used it briefly. I completely forgot about it, but I remember now I did enjoy using it back then. https://pythonhosted.org/Flask-Soy/
infogulch 1 days ago [-]
How does zt compare to zmpl, another popular zig templating engine?
Zmpl wants you to build up a JSON-like data tree, and templates work using those values. That unfortunately means you are back to dealing with runtime errors. Minor thing, but they also want to render the template into an allocated string, rather than writing it to std.Io.Writer directly. And then there is the syntax, I prefer the Go Templ approach.
seletz 12 hours ago [-]
Liililk scwlewsusiusk leaa as slf e e.
Humphrey 2 days ago [-]
I love the idea! I could imagine something similar created for other languages too. Perhaps written in a way that a template could be reused in, let's say Django, and a JS React frontend. With all the type-safety that tsx provides.
marcle 2 days ago [-]
I always thought that the type-safe XML/HTML in Ur/Web was elegant.
I recently built some templating language (rather an intermediary language for documents) for solving an accumulated frustration over the years. Already added into four or five of my projects (for templating html, emails, dashboards, chatbots messages, and some configs).
There was a brief period where everyone and their dog implemented mustache[0] as a template system, but it died quickly because cross-language templating is not that useful in the end, you seldom need to switch host language but keep the templates.
As for Django... well.. Django only has text formatting, you can write any garbage and broken html and lots of invalid templates with silent failures there unfortunately.
pelme 2 days ago [-]
We created https://htpy.dev to solve this for our Django app. Has been using it in production for multiple years. Works great with Django (or any Python web framework).
Humphrey 24 hours ago [-]
Oh that looks cool :)
insin 2 days ago [-]
This had me checking if anyone has implemented first-class support for Python JSX components in Django yet, and it could be... sort of... maybe viable with PyJSX? [1]
It looks like you'd have to implement something equivalent to provider/context functionality yourself if you want it, as well as a simple render()-like helper to render a component tree. I've not tried their VS Code plugin, but it's a good sign that they have one.
This is sort of halfway between tsx and Elixir's EEx
zelcon 17 hours ago [-]
Why are people trying to implement PHP in 2026?
A much better exercise I’d like to see is using C++26 reflection to accomplish the same thing. Because that will actually be used while Zig will not.
jaxxzi 2 days ago [-]
I've never quite got the deal with 'template engines'. I have always just done normal programming - in whatever language I'm using - and interspersed outputting raw string literals to create the html.
chii 2 days ago [-]
and this leads to html injection attacks when there are small errors in your escaping.
Using a template engine means you systematically ensure that values are escaped (at least, that's one of the reasons i would choose an engine over raw dogging the html).
goalieca 24 hours ago [-]
You can have a safe library that does this and then enforce its usage with a linter or something. Template engines print strings and escape them under the hood.
NamlchakKhandro 2 days ago [-]
eww gross.
_kidlike 2 days ago [-]
sounds very similar to jte.gg for Java
vogelke 2 days ago [-]
If you can suppress your gag reflex, M4 can do some of what you want.
sinclude(...) will include a file and be silent in case of failure.
I did something like this for user-login history because I couldn't use
PHP or Perl:
The linked thread here[1] is… illuminating. The Zig stdlib seems pretty buggy, and the much applauded IO interfaces seem to be struggling with cancellation. The BDFL doesn’t seem to have much to say other than “brush your teeth”
No, that's not the best description. The Io interface is actually one of the best cancellation stories out there. If you combine it with defer/errdefer, you get safer cancellation guarantees than you have in async Rust (you can do async "drop" for example). The only problematic part is the interaction between the Reader/Writer interface and the Io interface, with regards to error handling.
ioasuncvinvaer 2 days ago [-]
> The only problematic part is the interaction between the Reader/Writer interface and the Io interface, with regards to error handling.
The fact that error handling suffers when combining two of the base interfaces of the standard library is pretty rough though? I don't think rust has that particular problem.
lukaslalinsky 2 days ago [-]
It's a different approach to Rust. There, if you cancel a future, it stops polling and runs the Drop interface. You don't get to do more complex cleanup. But, at the same time, because cancellation is not an error that all functions have to propagate, it's structurally not possible to ignore it. Zig, like many other languages, uses a specific error to indicate cancellation. The application can decide what to do with it, it has some benefits. But unlike Python/Java where exceptions can he thrown from anywhere, Zig errors need to be named and that's where to issues comes from, because the Reader/Writer interfaces no longer are generic, they can't pass the concrete errors returned from the implementations, and cancellation is one of the errors that get hidden that way. It's a comprise either way, Zig would need to have first class support for comptime interfaces/traits to solve it better, but that's not going to happen. So in the meantime, there is a dilema how to handle it, but I'm sure it will get solved, or at least best practices will get developed.
ioasuncvinvaer 2 days ago [-]
I am not really convinced that new best practices will be developed or in included in the standard library because andrew thinks that there isn't an issue.
lukaslalinsky 2 days ago [-]
I have a partially written blog post in my head, as I've spent a lot of time thinking about the problem. I'd have preferred if there was a change to the reader/writer interfaces, but even without it, I'm starting to see patterns that work and can be applied to any code to make it safe. People just need to be aware of the problem and that's my goal, although I'm probably failing if my tone is creating the drama, so I'm learning how to communicate it better.
ioasuncvinvaer 2 days ago [-]
I don't think you are creating any drama to be honest. I understand how frustrating it must be.
There is a similar issue in kotlin where a cancellation is marked via a CancellationException but that extends IllegalStateException and thus Exception. Because of that it gets caught and swallowed all the time. This is a constant source of bugs for me at work and google has resorted to a bunch of linting to get around this design mistake.
bvrmn 1 days ago [-]
The most frustrating part about it for me it's Andrew's argument: just write correct code. I have C at home.
1 days ago [-]
dnautics 1 days ago [-]
In the future, tooling can run those checks statically on IR.
lukaslalinsky 1 days ago [-]
Unfortunately, it you want to handle errors right, it's overly verbose, so no one really does it. That's my problem really. Even in the blog post snippet, I could have show well behaved code, because I'm well aware of it, but then the error handling would be more code than the part I'm trying to showcase. Static analysis will not help there.
orf 1 days ago [-]
In the future, it would be good to not need to require that unwritten tooling
jeltz 1 days ago [-]
Yeah, I feel Andrew's tooth brushing argument is quite weak here. It is basically the same as the defence of C's error handling, which Zig fixed.
2 days ago [-]
jeltz 2 days ago [-]
Cancellation in Rust is problematic too but for other reasons than cancellation in Zig is problematic. Maybe there is just no free lunch here, but hopefully it can be fixed in Zig and Rust.
brodo 2 days ago [-]
The answer from Andrew sounds like that because there is a history between people from the core team and lalinsky.
hitekker 1 days ago [-]
Yeah, sounds like they're on good terms. The top replier to the GP disagrees with the GP's mischaracterization.
ptsneves 2 days ago [-]
Not a zig person, but the post you linked has a good counter example on why the proposal for adding cancellation to the interface is bad: You would be forcing cancellation semantics on interfaces that might not want nor be able to provide one. Forcing a new method because the libraries are not well designed does not seem right for me. Maybe another solutions is available, but that is not one.
I get the pain, but the answer from Scott Redig totally makes sense. I am not sure what is worse: Libraries swallowing cancelled() or libraries lying that they support cancelled.
bvrmn 1 days ago [-]
The point is libraries are agnostic. You as a library user provide io transport and loop implementation which supports/not supports cancelation. And you as as library user handle cancelation.
> Libraries swallowing cancelled() or libraries lying that they support cancelled.
For me former is obviously worse.
arbor-group 1 days ago [-]
[flagged]
latencyharbor 1 days ago [-]
[flagged]
mococa 1 days ago [-]
[flagged]
slopinthebag 2 days ago [-]
one thing i love about rust's macros is that you can accomplish this without needing a separate file type or inventing syntax
#[component]
pub fn HomePage(user: Option<User>) -> Element {
rsx! {
Layout {
title: "Home",
if let Some(u) = user {
h1 { "Welcome back, {u.name}!" }
a { href: "/users/{u.id}", "Your profile" }
} else {
h1 { "Welcome, guest!" }
a { href: "/login", "Log in" }
}
}
}
}
dnautics 2 days ago [-]
> you can accomplish this
That's not HTML though, you have to learn a whole new dsl that must conform to rust parser rules. So, not the same thing at all.
josephg 2 days ago [-]
You can do actual html. This is Leptos, a Solidjs like rust library:
does it still work if you remove that space before the tag's closing character in this line?
on:click=move |_| set_count.set(3) >
slopinthebag 2 days ago [-]
i prefer it, but you can also get html if you want
eg
html! {
<div onclick=|_ev: web_sys::MouseEvent| {}>
You can type text right into the elements
{ component }
{ text_var }
</div>
};
skavi 2 days ago [-]
but you have invented syntax
asimovDev 2 days ago [-]
This is just Twig templates, crazy. It's cool that Rust can do this out of a box
slopinthebag 2 days ago [-]
yep and you get rust's lsp support too, autoformatting, etc.
this is rsx, but there are other macros that look just like html. i prefer this though, it's much more compact and readable imo
lukaslalinsky 2 days ago [-]
I'm not a fan of Rust, the overly flexible macros are actually one reason for it, but if you can indeed get LSP support in a custom syntax like this, that's really awesome. Thank you for the example.
terca 2 days ago [-]
do you think that when compiler internals 'settle down' it will (gradually) be exposed through some interfaces (like compiler plugins in jai) so that we can more easily develop LSP for quasi-zig formats like this ?
That would be great, I really like openness and ~plugin interfaces of jai compiler internals ...
sroerick 2 days ago [-]
That is super cool actually
eggsandbeer 2 days ago [-]
[dead]
thetexaslawdog 2 days ago [-]
[flagged]
Rendered at 22:51:33 GMT+0000 (Coordinated Universal Time) with Vercel.
This is kind of funny remark, given that the author started in 2000 in Web development, and with PHP 3.0.
I started in 1997, our distributed systems class had exercises to write CGIs in Perl and C.
Between 1999 and 2001, most Web development at my employer was in Tcl and C, ASP was naturally a mix of VB and C++ COM components, and there was also the fun to write all those mod_something Apache extensions, and IIS ISAPI modules, naturally in C and C++.
Ah, Microsoft was also shipping ATLServer, because who wouldn't want to use ATL for Web development, while Borland/Inprise was shipping similar stuff for Delphi and C++ Builder.
PHP itself, in 3.0, it was still the time that it hardly had much functionality builtin, so it was quite common to write extension modules in C.
So it is kind of ironic to read coming back to the way things were, before the slow scripting languages takevover in the 2010's, is something no one thought about.
Most of my work was on an intranet page used for tracking internal servers, apps and databases. One of cool (at the time) features I implemented was a server-rendered ping of the servers shown on the dashboard. We're talking usually a few hundred at a time. The site ran on IIS & NT 4, written in VBS & ASP. (I think my first server was actually a dual Alpha chip, wasn't even x86, sure as hell was way before x64).
To implement the ping functionality (yes, we're talking just a straight ICMP ping), I ended up doing a COM server, written in C++, called into it from the VBS side. Eventually, .Net came out, and once .Net Framework 1.1 was released, I was able to convince my boss to let me rewrite the whole site in ASP.Net. I ditched the C++ COM object and was able to do it in C# with raw sockets (and appropriate permissions, which was a bit of a pain to get right at the time, before google and stackoverflow were around to help). Getting the C++ COM object working was actually easier because at least the MSDN library (the entire stack of CDs & DVDs it was on) had extensive documentation. The .Net side was good initially, but it just did not have the same depth as the C++ side already had at that point.
The typesafety you get is what you already have in Kotlin, and there a little extra in that you cannot nest certain HTML-elements in certain other elements (adhering to the HTML spec). You can come up with your own elements and attributes, but the ones that are in the HMTL-spec are usually available in kotlinx.html as well (and thus can be auto-completed).
A large part of this library is generated from the actual HTML spec.
Claude Code seems to have not problem writing it (I barely write templates myself these days).
https://github.com/kotlin/kotlinx.html
https://dzone.com/articles/modern-type-safe-template-engines...
Looking forward to seeing some benchmarks!
Hence HTML as a mere vocabulary making use of SGML's facilities didn't need to define its own ad-hoc mechanism.
Btw the <?php ...> construct is also derived from SGML. In SGML terms it's a "processing instruction" rather than an "entity reference", the latter being the basic means for content inclusion.
https://www.w3.org/TR/xinclude/
https://www.w3.org/TR/xinclude-11/
I say tragically, because XSLT was indeed the only sort-of workaround that was available for templating in the browser, even if it was limited to v1 rather than the much more useful v2 and v3.
https://web.dev/articles/imports
Been there, tried that.
Introduced in 2014 (Chrome 36) Deprecated 2018 (Chrome 70) Retired 2019 (Chrome 73)
(but yes- I used these a lot like 25 years ago)
Why is there no direct support for templating in HTML itself?
Eg some template feature creates a security issue and has to be disabled, which invalidates all the old HTML that used it.
There’s also just not a super great reason to do it. It’s not all that different from pre-templating like Hugo or doing it server-side like Django. You get to offload some compute, but HTML templating isn’t usually the bottleneck.
No offense but this is a bit of a non-argument that could be applied to just about any development in HTML.
> There’s also just not a super great reason to do it.
Most web dev frameworks exist in large part to solve the problem of templating. (yes, they do other stuff, but templating is the central problem that they are solving)
HTML is actually shockingly backwards compatible. I very rarely see pages so old they won’t render. The main exception is basically exactly what I’m talking about: Flash and ActiveX, that had to be abandoned for security (and some poorly advised iframe stuff).
> Most web dev frameworks exist in large part to solve the problem of templating.
This might be an agree to disagree area. Most web dev frameworks I’ve seen exist to make dealing with state easier. They do templating because you have to put the state somewhere, but the magic is all in the state.
There are some that only do templating, but they’re pretty rare. Hugo or Jekyll come to mind, though “web dev framework” is probably overselling them.
There are also web components, which sound vaguely like what you’re talking about. They’re not crazy popular, but they exist and work. The security boundaries make it kind of a nightmare, I remember having to do something weird to inject Tailwind into them because they’re isolated from global CSS. The kind of things you have to do when securing templates at runtime instead of compile time.
This might be the worst argument for anything I've read this week, there's got to be a name for this logical fallacy
It's a repeated observation that keeps coming true. DSLs have a tendency to become turing complete over time.
- It happened to wikipedia's templating language
- It happened to PHP
- It happened to mod_rewrite
- It happened to server-side includes
- etc...
It just keeps happening.
In fact it's such a problem with infrastructure teams that use yaml/json configs that you see a lack of turing-completeness being advertised as a feature (see Dhall configuration language).
But "we can't give something to users because otherwise they'll ask for other stuff" is not an argument. They're _already_ asking for stuff (templating) anyway. No one is suggesting that shutting users up is a reason to implement templating, it's the trade-offs of this feature that are debated. And if it gets implement then yes, users will certainly ask for more features, the trade-offs of which can be debated.
If you think that the line for HTML features is where we already are, you can present your arguments for why (tbh I'll probably agree). But "if you enable templating devs are then going to ask for more" isn't one.
i.e. MyTemplate.tpl.html
which creates a kotlin class that can be used like this: the biggest upside for me is that this way there's full, free IDE support, i don't need to write extra view models if the mapping isn't 1:1 and performance is pretty good because in the end there's no runtime parsing/compiling/interpreting except for the baseline JDK stuff (though there are even faster engines).https://codeberg.org/h34tnet/tempolin
warning: so far i'm the only user though, so don't use it in production. also, i'm working on some improvements right now which haven't been pushed yet.
It never occurred to me, either! This is really neat! How does it work?
EDIT: Never mind, seems like it's a custom file format that gets compiled to Zig code. Still quite neat but unfortunately you lose all the IDE support.
I think there is a way to do syntax extensions cleanly, with a special block type like `'{ }` that gets tokenized and passed to a comptime function skipping the parser. But one of Zig's main selling points is no hidden control flow and they want to keep it that way.
Sure I hack a 'Sup World in C every 100 years just to get that feeling you get when you stumble into semi-accomplishment but to consider a low-level lang executable as a product that I produce, maintain and develop expertise/taste with?
Regarding web dev in any low-level lang: once you get that there's a parenthetical "services" between the words "web" and "development", the quest for the languages that offer speed, reliability, etc becomes inevitable
Is there maybe a Zig wrapper for Google soy around?
https://github.com/jetzig-framework/zmpl
For examples, see http://www.impredicative.com/ur/demo/
The design point "deterministic, hostable, with enough to make hooks from the templates" is what makes it special: https://lucasdicioccio.github.io/tramaj/ .
0: https://en.wikipedia.org/wiki/Mustache_(template_system)
https://kotlinlang.org/docs/type-safe-builders.html
As for Django... well.. Django only has text formatting, you can write any garbage and broken html and lots of invalid templates with silent failures there unfortunately.
It looks like you'd have to implement something equivalent to provider/context functionality yourself if you want it, as well as a simple render()-like helper to render a component tree. I've not tried their VS Code plugin, but it's a good sign that they have one.
[1] https://github.com/tomasr8/pyjsx
A much better exercise I’d like to see is using C++26 reflection to accomplish the same thing. Because that will actually be used while Zig will not.
Using a template engine means you systematically ensure that values are escaped (at least, that's one of the reasons i would choose an engine over raw dogging the html).
1. https://ziggit.dev/t/making-it-harder-to-swallow-error-cance...
The fact that error handling suffers when combining two of the base interfaces of the standard library is pretty rough though? I don't think rust has that particular problem.
There is a similar issue in kotlin where a cancellation is marked via a CancellationException but that extends IllegalStateException and thus Exception. Because of that it gets caught and swallowed all the time. This is a constant source of bugs for me at work and google has resorted to a bunch of linting to get around this design mistake.
I get the pain, but the answer from Scott Redig totally makes sense. I am not sure what is worse: Libraries swallowing cancelled() or libraries lying that they support cancelled.
> Libraries swallowing cancelled() or libraries lying that they support cancelled.
For me former is obviously worse.
That's not HTML though, you have to learn a whole new dsl that must conform to rust parser rules. So, not the same thing at all.
eg
this is rsx, but there are other macros that look just like html. i prefer this though, it's much more compact and readable imo
That would be great, I really like openness and ~plugin interfaces of jai compiler internals ...