If it is what I think it is, it’s extremely neat. Parsing both HTML and templating syntax at the same time is way more robust than doing just the templating and hoping for the best.
I was thinking about something like this, but with some blend of Jinja2 / Twig / Nunjucks [1] syntax and Svelte/JSX-like use of variables in element attributes:
{% for para in page.body %}
<p class={{ para.class }} {{ **para.attrs }}>
{{ para.text }}
</p>
{% endfor %}
---[1]: the irony is not lost on me that I’m mentioning Python, PHP and JS template engines in a Ruby discussion :-) Liquid is the closest equivalent I think, but there was some crucial piece missing last time I had to use it, though I can’t remember what exactly.
I've been working with FastHTML and I have to say, I rather enjoy HTML-markup-as-objects.
It works pretty seamlessly and you get something like this:
@app.post('/part/add')
def create_part(part_number: str, name: str, description: str):
p = Part(part_number=part_number, name=name, description=description)
p.save()
return (p,
Input(placeholder="part number", id="part_number", hx_swap_oob='true'),
Input(placeholder="description", id="description", hx_swap_oob='true'),
Input(placeholder="name", id="name", hx_swap_oob='true'))
Note, I'm not using FastHTML's built-in database interface. I prefer a little less implicit than the strict FastHTML style. Phoenix (Elixir) has a very elegant version of that, without the need for the extra indent:
<p :for={para <- paras} class={para.class} {para.attrs}>
{para.text}
</p>
With :for being a list comprehension. I was afraid at first this is the only option (which makes it difficult to generalize this to loops with body consisting of anything but a single element). But as an optional shorthand it is indeed pretty neat! (Personally though, I still like explicit “layering” of a separate `for` block a bit more.)
Interesting! I actually find the in-lined forms far more explicit. For me, the use of `<%=` blocks tends to muddle the structure of the underlying HTML, so I avoid them where possible (not always the case though, as you rightly note).
I'm not seeing any ERB here. Whatever blend you came up with could be done in ERB which just combines Ruby with HTML.
Template engines like liquid are good for simpler use cases where you'd want your end users to write templates (who aren't programmers)
Yeah, that’s intentional — I think having a clear separation between templates and code is a good thing. Regardless, you can use most of Python syntax in Jinja2 (and in my interpretation too, of course).
And no, it’s not only good for simple use cases. Template inheritnace alone is a killer feature for bigger projects: https://jinja.palletsprojects.com/en/stable/templates/#templ...