6 ms·

One of the huge advantages of Maud is that it keeps code and markup close together, so you can do things like having rust control structures determine what mark

by zaarn 4y ago

One of the huge advantages of Maud is that it keeps code and markup close together, so you can do things like having rust control structures determine what markup is used later on (for snippets or widgets, for example). Plus, Maud has a definitive speed advantage from what I've noticed. Sadly, there isn't any great alternative for making performant HTML templates in Rust from what I've seen, a lot of the other HTML templating libs aren't that great comparatively.

dochtman 4y ago
> Sadly, there isn't any great alternative for making performant HTML templates in Rust from what I've seen, a lot of the other HTML templating libs aren't that great comparatively. Which others have you tried, and why do you think they're not great?
- zaarn 4y ago
  I've tried handlebars and liquid. They're okayish, but both slow and don't have any compiletime help or typing when I tried them. Horroshow, ructe, typed-html and yarte were okay but inheritance was underdocumented (or generally not as well documented), which is a big no for me. And a few only give minor-quality help at compile time. Maud on the other hand has decent compiletime help and doesn't require a lot of documentation as normal rust code is doing the heavy lifting.
  - dochtman 4y ago
    I created Askama (which yarte forked), the inheritance docs aren't great but also not too bad. Curious why you didn't try it?
    - zaarn 4y ago
      I haven't found askama yet, or rather, discovered it through HN here, I don't check the arewewebyet.org site too often and it's my main source of frameworks to find. My main worry on things is that I'd rather like being able to express the inheritance in the type system through generics. Ie, having a top level "Page<T>" struct in which I can start putting the various subparts needed to render a page. It seems askama is doing it the other way round with a "parent" member needed in the child page.
rbanffy 4y ago
> One of the huge advantages of Maud is that it keeps code and markup close together I'd say it's actually a disadvantage. Front end engineers will work with HTML with embedded logic (as little as possible - values, iterators, conditionals). Generating HTML from Rust code is nice for simple things, but won't work with complicated HTML templates when those are required and will be harder to integrate with front-end applications. It's possible to compile a template with embedded logic (Java Server Pages did that in the late 1990's) to performant and type safe code. An approach like that would be great for Rust (someone must have done it by now)
- zaarn 4y ago
  My projects have no front-end engineer, however. The frontend is written in Rust as well and also uses Maud for HTML templating. And I dispute it not working with complicated HTML templates, that's handling it fine and integrates very well since I share code between frontend and backend anyway.
  - rbanffy 4y ago
    I get that, but Maud is not the first of its kind and the absence of similar engines in web development is a telltale sign it's not the optimal approach.
    - zaarn 4y ago
      Well, as mentioned, I've yet to find something that can replace Maud without sacrificing it's advantages (in-code inheritance, code-sharing and compile-time type-safety). So even if it's not the "optimal approach" as you title it, it's the ergonomic approach for me because it doesn't get in my way.
      - rbanffy 4y ago
        For these requirements, it's indeed a good choice. It's just not a use case I've seen often.
mkj 4y ago
Askama should be comparable in speed and type safety? It probably doesn't integrate any better inline with source though (I've only used it with standalone template files). https://djc.github.io/askama/creating_templates.html#the-template-attribute https://djc.github.io/askama/creating_templates.html#the-tem... Regardless, it's good to see some variety and experimentation like Maud in software design
- zaarn 4y ago
  Askama looks interesting, though the inheritance is a bit underdocumented. Ideally, I'd imagine just making a "Global<T>" struct, where I insert the current page context like so "Global<LoginPage>" to get the final template. Though by the looks, it sounds more like LoginPage will simply have to have all the global context available via some attribute like "LoginPage.global".

by zaarn 4y ago

dochtman 4y ago

> Sadly, there isn't any great alternative for making performant HTML templates in Rust from what I've seen, a lot of the other HTML templating libs aren't that great comparatively. Which others have you tried, and why do you think they're not great?

zaarn 4y ago
I've tried handlebars and liquid. They're okayish, but both slow and don't have any compiletime help or typing when I tried them. Horroshow, ructe, typed-html and yarte were okay but inheritance was underdocumented (or generally not as well documented), which is a big no for me. And a few only give minor-quality help at compile time. Maud on the other hand has decent compiletime help and doesn't require a lot of documentation as normal rust code is doing the heavy lifting.
- dochtman 4y ago
  I created Askama (which yarte forked), the inheritance docs aren't great but also not too bad. Curious why you didn't try it?
  - zaarn 4y ago
    I haven't found askama yet, or rather, discovered it through HN here, I don't check the arewewebyet.org site too often and it's my main source of frameworks to find. My main worry on things is that I'd rather like being able to express the inheritance in the type system through generics. Ie, having a top level "Page<T>" struct in which I can start putting the various subparts needed to render a page. It seems askama is doing it the other way round with a "parent" member needed in the child page.

rbanffy 4y ago

> One of the huge advantages of Maud is that it keeps code and markup close together I'd say it's actually a disadvantage. Front end engineers will work with HTML with embedded logic (as little as possible - values, iterators, conditionals). Generating HTML from Rust code is nice for simple things, but won't work with complicated HTML templates when those are required and will be harder to integrate with front-end applications. It's possible to compile a template with embedded logic (Java Server Pages did that in the late 1990's) to performant and type safe code. An approach like that would be great for Rust (someone must have done it by now)

zaarn 4y ago
My projects have no front-end engineer, however. The frontend is written in Rust as well and also uses Maud for HTML templating. And I dispute it not working with complicated HTML templates, that's handling it fine and integrates very well since I share code between frontend and backend anyway.
- rbanffy 4y ago
  I get that, but Maud is not the first of its kind and the absence of similar engines in web development is a telltale sign it's not the optimal approach.
  - zaarn 4y ago
    Well, as mentioned, I've yet to find something that can replace Maud without sacrificing it's advantages (in-code inheritance, code-sharing and compile-time type-safety). So even if it's not the "optimal approach" as you title it, it's the ergonomic approach for me because it doesn't get in my way.
    - rbanffy 4y ago
      For these requirements, it's indeed a good choice. It's just not a use case I've seen often.

mkj 4y ago

Askama should be comparable in speed and type safety? It probably doesn't integrate any better inline with source though (I've only used it with standalone template files). https://djc.github.io/askama/creating_templates.html#the-template-attribute https://djc.github.io/askama/creating_templates.html#the-tem... Regardless, it's good to see some variety and experimentation like Maud in software design

zaarn 4y ago
Askama looks interesting, though the inheritance is a bit underdocumented. Ideally, I'd imagine just making a "Global<T>" struct, where I insert the current page context like so "Global<LoginPage>" to get the final template. Though by the looks, it sounds more like LoginPage will simply have to have all the global context available via some attribute like "LoginPage.global".