I wish even more great tools like this were ported to Rust or some other language that makes packaging easy.
Do you think it could be reused to support pug/jade or slim? These are very similar template languages, and like haml, both have dependencies (JavaScript for the former, also Ruby for the latter) that make them difficult to use everywhere.
Having toyed around with such concepts I can naively say that templating languages fall into one of three camps:
The first is just alternative syntax: the templating language is, for all intents and purposes, just a sugared version of the destination language. HAML mostly falls into this camp. While it may have some nice features the mapping to HTML is so close that it can easily be implemented in most any language (and you'll notice this Rust version doesn't do Ruby evaluation yet, more below).
The second is logical templates: the language has a limited set of logical constructs (basic types, basic expressions, conditionals, iterators, interpolation) that will handle most of the situations you'll run into. An example is Soy; the languages you list almost fall into this camp as well (more on that below). The problem with logical templates is in the Pareto principle - they're good for 80% (probably more) of your use case but chafe at the remainder. Some have a notion of functions/extensions to help with such coverage but those have to be implemented in each language as well, which can lead to dependency-bloat and code duplication.
The last is embedded language templates: the language is capable of executing arbitrary code snippets embedded in the template. JSX (JavaScript), Jinja (Python), EEx (Elixir), and the languages you list all have this kind of functionality (as does HAML, to spec). The beauty is that they can leverage the full power of their programming language without needing to add extensions. The problem is that they need language support to do so; in order to implement Jade in Rust (to spec) you would need a JS interpreter.
Thus, while it would be possible to support MOST of pug/jade/slim up to the logical level you won't be able to implement them entirely to spec (as they all support unbuffered code) without also dragging along a JS/Ruby interpreter.
I wanted this so badly as a Rails dev checking out Rust a few years ago (and still kind of do). At the time, i convinced myself that if I was going to move to a type-safe compiled language i should see if compiled type-safe templates could work for me. I made a note of https://maud.lambda.xyz/ at the time which notice is still going and has a lot of a clean syntax of haml with some of the more rust-y compile time and type-safety aspects.
One thing to note, Haml-rs is going to be different than maud in the sense that, at least currently, there is no support for any sort of variables or expressions. You cannot use Rust (or Ruby) in this Haml-rs templates and expect them to render correctly.
It is something that I'm looking into and trying to think of the best way to handle it. Do I cripple variables and get rid of expressions? Do I allow Rust to be used instead of Ruby in the template? It is something I need to think about before working on.
5 comments
[ 2.1 ms ] story [ 16.9 ms ] threadI wish even more great tools like this were ported to Rust or some other language that makes packaging easy.
Do you think it could be reused to support pug/jade or slim? These are very similar template languages, and like haml, both have dependencies (JavaScript for the former, also Ruby for the latter) that make them difficult to use everywhere.
The first is just alternative syntax: the templating language is, for all intents and purposes, just a sugared version of the destination language. HAML mostly falls into this camp. While it may have some nice features the mapping to HTML is so close that it can easily be implemented in most any language (and you'll notice this Rust version doesn't do Ruby evaluation yet, more below).
The second is logical templates: the language has a limited set of logical constructs (basic types, basic expressions, conditionals, iterators, interpolation) that will handle most of the situations you'll run into. An example is Soy; the languages you list almost fall into this camp as well (more on that below). The problem with logical templates is in the Pareto principle - they're good for 80% (probably more) of your use case but chafe at the remainder. Some have a notion of functions/extensions to help with such coverage but those have to be implemented in each language as well, which can lead to dependency-bloat and code duplication.
The last is embedded language templates: the language is capable of executing arbitrary code snippets embedded in the template. JSX (JavaScript), Jinja (Python), EEx (Elixir), and the languages you list all have this kind of functionality (as does HAML, to spec). The beauty is that they can leverage the full power of their programming language without needing to add extensions. The problem is that they need language support to do so; in order to implement Jade in Rust (to spec) you would need a JS interpreter.
Thus, while it would be possible to support MOST of pug/jade/slim up to the logical level you won't be able to implement them entirely to spec (as they all support unbuffered code) without also dragging along a JS/Ruby interpreter.
It is something that I'm looking into and trying to think of the best way to handle it. Do I cripple variables and get rid of expressions? Do I allow Rust to be used instead of Ruby in the template? It is something I need to think about before working on.