
Show HN: Haml-rs – Haml parser in Rust - jetti
https://github.com/jhartwell/haml-rs
======
Arkanosis
That's sweet!

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.

~~~
seangrogg
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.

------
amichal
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/](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.

~~~
jetti
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.

