I'm going a tiny step further with the XML/HTML generation solution in functional Perl [1]: provide actual functions to instantiate HTML (or defined XML) elements, instead of relying on arrays. That allows for passing them directly to higher-order functions like map (and it also gives elements a proper type).
It looks like a nice project, but I wonder about the use case. It is limited to HTML output and usage from Rust. Hence, limiting the projects where it can be used.
HTML syntax has its problems, but when you work with the web, you have to know it anyways. Why would I want to deal with yet another syntax? It also means that as a user of the templating system you have to hope that the system can deal with all the quirks that HTML has (e.g., <br> in HTML 4, <br/> in XHTML and both in HTML 5).
It would be interesting so see an FAQ that explains where the advantages are over other templating solutions like Handlebars.
I have to say, my first (and rather uncharitable) thought when I saw this was, "Does the world really need another templating language?" I've been really happy with Haml for years now, and have reached moderate levels of satisfaction with Jade when I can't use Haml.
Since I use Jinja syntax for tempaltes already and potentially would like to switch to Rust later, would it make more sense later to add Jinja support to this library or to go with https://github.com/jroweboy/jinja2-c ?
The function/component concept is a neat idea, but I wonder how useful it would be to your team's designer or front-end dev who isn't so familiar with (or fond of) such strict rules and separations.
Well components, are purely static. They are the equivalent of text expansion, or string interpolation.
A Function's logic, isn't defined in Polly. You have to define it in Rust. This moves all the logic to your Rust server, where your logic should be. It also provides the advantage of being compiled, and optimised with the program, rather than if Polly defined it's own syntax for functions, and logic, and trying to parse that out at run-time.
I think the point is that templates themselves can't contain logic. All logic is declared at compile time so that the compiler can optimize it, but then used at runtime like any other templating language.
the idea of using a backend platform for a frontend task like templating has a big flaw. you can't use any part of the template from javascript. so you might need to write everything twice when you start using ajax. I think it would be better to pass the data from your controller to something like node which then renders the html. then you could reuse this at the front end. of course doing the entire view part by front end javascript is also a possibility (with the disadvantage your site would not work when the user disables javascript). I think non-node web frameworks should address this problem by making it easy to let node do the rendering.
Prefer logic-less functions to output html strings? Hiccup has this use case covered. This is all stock Clojure[script], not a templating language:
Plus there's plenty of ways to quickly build up a bootstrap (, etc) page. BTW, there are some interactive examples at http://hiccup.space