Show HN: Polly: A templating language for Rust | Hacker News Reader

Show HN: Polly: A templating language for Rust

gitlab.com

47 pointsAaronepower21 comments

Really, I think Hiccup is the best solution in this space.

Prefer logic-less functions to output html strings? Hiccup has this use case covered. This is all stock Clojure[script], not a templating language:

    (def foo [:h2 "something cool"])
    (hiccup.core/html foo) ;;=> "<h2>something cool</h2>"

Plus there's plenty of ways to quickly build up a bootstrap (, etc) page.

    (defn bootstrap-page [hiccup-form]
     (hiccup.page/html5 
      (hiccup.page/include-js "link-to-jquery.js" 
                              "link-to-bootstrap.js")
      (hiccup.page/include-css "link-to-bootstrap.css")
      hiccup-form))

BTW, there are some interactive examples at http://hiccup.space

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

  my $rows= list(list(1,2,3), list(4,5,6));
  HTML(BODY(TABLE($rows->map(fun($row) { TR($row->map(*TD)) }))))->string
  # => '<html><body><table><tr><td>1</td><td>2</td><td>3</td></tr><tr><td>4</td><td>5</td><td>6</td></tr></table></body></html>'

  ref HTML()
  # => 'PXML::PXHTML';

[1] http://functional-perl.org/

Hiccup is wonderful, almost makes it painful to go back to jade/erb/jinja/etc after working on a project with hiccup.

CL-WHO is an often forgotten grandfather of Hiccup - http://weitz.de/cl-who/

Also here's a quick list of some other CL-WHO alternatives - http://stackoverflow.com/questions/671572/cl-who-like-html-t...

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.

Or just support HAML syntax...

Right? Hasn't this wheel been reinvented a gajillion times before.

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.

Also, it wasn't clear to me from looking at https://gitlab.com/Polly-lang/Polly/blob/master/GUIDE.md#var... how I would actually write, say, an email addressing including an "@" symbol (I'm sure it's possible, just not documented there).

You're right, I didn't explain it there, I'll update it, but you can just escape it with a \ so "bshimmin\@mail.com" would work.

It looks nice, but what about choosing something else as a name?

There are already at least two programming languages named Polly and a third one Poly.

Can you suggest a link to a list of programming language names that people could use to check this for themselves?

Google, Yahoo, Bing, DuckDuckGo ?

Just search for the desired name + "programming language".

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 syntax of Jinja is completely different to Polly's. If you're really persistent about using Jinja, you should probably use Jinja2-c.

I'm currently working on something like jinja/django templates in Rust, hopefully ready soon-ish

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.

It's 'truly logic-less' but with functions and components...

Yes, I had the same thought. Removing logic from templates all-together would hamper development, IMO. You need some basic level of logic to get by.

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.

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.

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.

Reply on news.ycombinator.com