Most templating systems work in combination with an external program written in a high-level language, e.g. Ruby for Liquid or Python for jinja2. m4 does not.
And m4 works in combination with a bunch of C code. Virtually any system with m4 can come with an interpreter for a higher level language without running out of space (I can't imagine many uses for m4 at runtime on systems where, say, a perl interpreter wouldn't fit). Why is relying on such a runtime a problem?
No, m4 is written in C but it is autonomous. Liquid needs something like Jekyll around it.
Re:M4 as a templating language (2020)
by ricardobeat on Friday July 30, 2021 @07:07AM
(#28006690)
What does “autonomous” mean? There are a ton of template engines that don’t depend on a parent framework, there is no reason you can’t implement all features in C.
Something like mustache for example, which has a C implementation that includes support for includes/partials: http://mustache.github.io/mustache.5.html
That seems like an odd assertion given the existence of other templating systems which have friendlier syntax while being capable of generating arbitrary output. Is there a reason why you think on the M4 approach is valid?