Inja: A Template Engine for Modern C++ | Hacker News Reader

Inja: A Template Engine for Modern C++

github.com

44 pointsEntICOnc30 comments

What are the compelling use cases for template languages that don’t support the full host language?

Or: what do I gain from intentionally limiting myself to a bespoke language that lacks many of the constructs of the language I’m writing the rest of my project in?

If I can’t be trusted to responsibly and successfully use that full language in templates, how can I be trusted to use it in all the rest of the code base?

There are many uses for templates, not all of them need you to use advanced language constructs in the template language. Personally, I'd rather have templates be relatively dumb, and use something like {{mustache}} (https://mustache.github.io/).

True, but then why not limit oneself to exactly that subset of the language that one considers non-advanced and relatively dumb, rather than let someone else make that call?

Who said it's about trusting you?

It's very common for templates to be written by people who are not full developers. The HTML might be written by a designer, email-templates may be written by marketing etc.

By limiting the power of the template language to only data display and simple conditionals and loops, you can those people to write templates far easier and you can let them upload new versions whenever they want with much less worries and you don't have to go through your full code review process just to update an email template.

Well, you can’t trust anyone! :)

Template languages are still languages, and it’s easy for even seasoned developers to make errors that have to be corrected between ‘upload’ and whatever deployment looks like in this scenario. Forget to double-up the closing curly-brackets? Blammo.

I wonder how common it is in practice. Are there existing frameworks or (non-no/low code) CMSes that support that workflow? I.e. letting non-admins modify templates, ‘compiling’ them if necessary, running them over some sample input, and allowing iteration - before potentially breaking things in production?

Limiting the language to avoid having to do a full security audit - that’s a good point.

In this specific case supporting the full host language would mean implementing a whole C++ compiler which might be a bit overkill.

I would imagine a preprocessor (not the C++ one) would be used before re-implementing C++. :)

Not having to use one could be a use case, though IMO I don’t know if that’s compelling enough…

Syntax for loops and conditionals introducing scopes to your document may work fine for plain text documents, but in my experience it turns structured documents like HTML in unreadable mess very fast. I don't know why it's a de facto standard for template engines to make it this way. I came up with the idea of attaching conditions and loop specifications directly to XML tags, and in my opinion it significantly improves readability. I couldn't find any alternative with similar syntax, so I've implemented it myself. It's also in C++, although it works as a transpiler, and templates are needed to be compiled. It can be found here: https://github.com/kamchatka-volcano/hypertextcpp

I'm agreeing with everything you said, but still I don't know why it's a defacto standard for template "engines" targetting HTML or other markup to invent ad-hoc syntax rules involving Unix shell-like $s and/or curly-braces and/or dotted paths ;)

When SGML, since the begin of times, has entities/entity references (plus CDATA/RCDATA marked sections) for exactly that purpose. Plus, can actually encode/quote expanded text in a context-dependent way (eg attributes vs elements) and prevent or allow expansion of replacement text into <script> directed by allowed content models, and prevent other injections using HTML-aware templating.

it's a defacto standard for template "engines" targetting HTML or other markup to invent ad-hoc syntax rule

Totally.

My hypothesis: people enjoy writing templating engines, which is why there are so many. And people especially enjoy inventing their own programming languages.

Templating engines are the perfect place for a web developer to dip their toes as gently as desired into language creation, in a format that’s kind of fun and is also immediately relevant and useful.

For me this feels like a candidate to build on top of fmt instead of a standalone thing, with a custom formatter wrapping JSON data. I think that direction of extension might still be open, while keeping the current interface for convenience and compatibility.

If you’re in the Qt ecosystem shout out to grantlee which has been around forever.

https://github.com/steveire/grantlee

Anyone using C++ for "standard" web backend dev ? I don't expect there be things as convenient as Django or Rails but maybe there are a few nuggets such as this nice Jinja-like library.

Then there is of course other uses for templates besides web development.

Actually there are, for example https://www.webtoolkit.eu/wt

I use C++ for large web backends because I dislike Typescript. I use Javascript for small web backends. Actually to me, JS feels so close to C++.

I use cppcms most of times but in some cases I use Seastar for high perf.

I don’t understand what this adds to C++20’s standard `format`, which you can run in older versions of c++ via the fmtlib library.

Is there a use case I don’t understand?

If you go back and re-read the subsection Statements (and perhaps other sections of the README as well), I'm pretty sure you'll find a use case you might have not yet understood.

There is also Boostache:

https://github.com/cierelabs/boostache

I would have hoped for a typesafe (compile-time checked) template engine for something dubbed "Modern C++".

This thing must fly. Are there any benchmarks?

Is this Unicode?

This is a little confusing because C++ already has an unrelated built-in template concept (including the keyword "template").

In C++ terms this is a library that generates HTML, not a template engine.

To be a bit more precise it's a library that renders strings from a template.

The result may or may not be valid HTML.

My thoughts precisely. Maybe it could be renamed to string parser and replacer(?) for C++. SPaRC.

“Template” is a term of art for this sort of thing, but if you’re looking for an alternative, there’s already “macro processor” for things like this. It’s what GNU’s M4 is called, for example. https://en.m.wikipedia.org/wiki/M4_(computer_language)

But - whoops - now you’ve got collision with C++ “macros” - which already has collision with Lisp “macros” and text editor / word processor macros - and “processor” which looks a lot like the C++ “preprocessor” and …

I am fine with it “templating engine” has a pretty well defined meaning as a group of words.

If it was called “modern templating for c++” I would agree.

In web dev terms it makes total sense.

What is not clear to me, from a scan of the docs is if it properly escapes strings for html, or if it is a general templating system for strings.

I will admit I followed the link because I was expecting some kind of lovecraftian template horror, only to discover it was templates in the string sense.

I'm not sure whether I should be disappointed or relieved :D

Reply on news.ycombinator.com