Show HN: Askama – Type-safe, compiled Jinja-like templates for Rust | Hacker News Reader

Show HN: Askama – Type-safe, compiled Jinja-like templates for Rust

github.com

82 pointsdochtman27 comments

There's also Bart (https://github.com/maghoff/bart), inspired by Mustache. Like Askama, it's typesafe and compile time generated.

Hi! I'm the author of Bart. AMA :)

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.)

I just wish rocket and diesel got the new tokio goodness, then Rust will probably replace flask in my workflow.

wow, I must have missed a generation, I have literally no idea what you're talking about.

they are rust libraries. no reason to have heard of them if you aren't learning/using rust.

http://tokio.rs/ : async io

https://rocket.rs/ : a web framework

http://diesel.rs/ : ORM/Querybuilder

Isn't Rocket using Hyper, and Hyper using Tokio? It may be that Rocket is still on a non-tokio Hyper, but that'd only be temporary then.

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.

Django/Jinja/Stencil should be the de facto standard for all templating systems so developers can port their work to any platform without sweat.

Kudos for porting Jinja to Rust.

Jinja yes, django not so much.

It's essentially the same syntax

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.

Yeah, I understand the motivation but it doesn't help when you just want to call a model method with just a single argument.

They are also dog slow :(

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.

> 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?

Does Mustache compile into .swift files that need to be typechecked and linked into the binary?

Is the answer not in the section you quoted?

Are they dynamically linked?

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.

Because you can then catch errors at compile time instead of run time.

Performance, type-safety. Is it worth it? No idea, haven't tried it, and probably depends a lot on your use case and development process.

My main reason was type safety; getting early feedback from the compiler is really valuable to me.

I don't see compiling them as a big downside, either. What problems do you see with that?

Tera (https://github.com/Keats/tera) exists already if that's more your cup of tea.

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).

You understood it right.

Reply on news.ycombinator.com