Askama and Bart seem to be pretty similar in use (compile time, based on a struct definition) except for the template languages. Askama is rich, while Bart, like Mustache, is deliberately more restricted. ("Logicless", they would call it. I don't know how to quantify that.)
Rocket is not really using hyper. It takes one or two of its types, but implements HTTP itself. There's an ongoing discussion between all involved about it.
To be honest, there have been multiple takes on Jinja in Rust already; I think Tera (https://github.com/Keats/tera) is the most used. However, Tera didn't quite feel Rusty to me, so I wanted to try another approach.
Kind of but not really, Jinja let's you do a lot more. {{(x or y)|filter(z)}} for example, or even just {{function(a, b, c)}}.
Django is far more restrictive in what you can put between the braces. I think one of the design goals of it was that designers with little programming knowledge could write the templates, which is a noble idea but leads to frustration as anyone who has maintained a large django app will tell you.
I think part of the motivation for the limitations was to stop people from putting too much business logic in their templates. You can of course implement any kind of tag or filter you want and just use that. Or indeed just use Jinja if you want. Django's templates are perfectly fine and I still prefer them over the similar alternatives.
> Because Askama will generate Rust code from your template files, the crate will need to be recompiled when your templates change.
Being Swift a compiled language just like Rust, why can we modify the templates (Stencil, Mustache) in Swift without recompiling the app but not in Rust?
Stencil and Mustache do that because they don't compile to Swift, but load and parse templates dynamically. That kind of template language implementation of course exists for Rust as well. (And the other way round, you could have a system that's like this submission for Swift, if there isn't one already)
That's exactly the point, why do that in Rust when it can be done without the need for compiling it? That's the explanation I want to hear. Having to recompile the whole app just to test changes in the template is absurd in my handbook.
Parsing templates at run-time is a run-time cost, possibly amortized by caching. If it's done at compile time then it only has to happen once (or anyway a lot less frequently than your program will be run).
On the other hand, perhaps it could parse them dynamically in debug mode (and statically in release mode), but notice that the library creates a structure to hold the data that is inserted into the template. In debug mode it would have to do dynamic lookups into that structure, which means capturing its layout for use at run time. All the other template features would likewise need some run-time implementation. You'd end up writing everything twice. If you're willing to do that extra work, you might instead think about writing a JIT compiler for your template language. Instead of caching the AST of a template, a JIT implementation would generate and cache runnable code.
On the gripping hand, one of the things that makes static compilation possible here is that the template compiler uses macros to generate Rust code, which the Rust compiler then compiles. To do a JIT you would either have to write your own compiler, or embed all of Rust (and LLVM) into the application. You wouldn't be the first to make a language that makes the entire compiler available at run time, but there's always a cost to that.
This looks awesome, if I'm understanding this right there's type checking with the template at compile time(I.E. if "name" in the template isn't found in the Rust struct it's a compile failure).
