Initial experiences using htpy

[davepeck]

Thanks for this handy library.

I had a chance to use it in a new project, voterbowl.org. We're running campaigns to encourage college students in the US to check their voter registration in advance of the 2024 presidential election. To give a sense of what it looks like:

VoterBowl came together pretty quickly, and is relatively small, so my experience with htpy is still fairly minimal. But here are some very early thoughts:

0. For this specific project, I prefer using htpy over Django templates; in fact, an early version of the site used Django templates and I converted it. Overall, I find the new code easier to reason about; the ability to use Python type hints throughout, particularly for individual components in my design, feels like a real win.
1. The compact approach to specifying classes and IDs is appreciated and works well.
2. After a brief moment of surprise, I came around to the use of __getitem__ for children.
3. I'm using HTMX and I find that web components pair nicely. I didn't notice the (clever, useful) module-level __getattr__(...) in htpy at first, but it also pairs nicely with web components.
4. As discussed elsewhere, it would be nice to have a well-defined pattern for building "components" that look like htpy.Elements but can have more complex trees before nesting their children. (I settled on a pattern like the one suggested in [Idea] allow repeated attribute extension! #6).
5. I ended up also building a Fragment class to allow me to render non-nested HTML. This is useful in a few places, like HTMX responses that use oob swaps. It feels like Fragment could actually be the class that htpy.Element derives from: it's a container for children but without an explicit parent tag/attributes.htpy.Node could then reference Fragment instead of Element. (Fragment is distinguished from a list of Element in that str(some_fragment) will render HTML, while str([element_1(), element_2(), ...]) won't.
6. The one place where Django templates still shine for me is when the content is (much) less programmatic and (much) more pre-canned, for instance the FAQ content on voterbowl.org. Using htpy also requires me to be very careful with whitespace characters; it's a bit awkward in places. This reminds me of the javascript templating world just before JSX became mainstream; not really an issue with htpy, but it would be fun to see the community resurrect and build tooling around something like Guido's pyxl.

Thanks again for htpy!

[pelme]

Thanks a lot for sharing this write up, it is really useful and I am happy that htpy is useful to you!

• Your implementation of @with_children uses dataclasses which is a nice improvement over my version. I am still not sure how to best include it in htpy, if it belongs or not.
• I think we need some solution for rendering elements without a parent. See Request for Blank or Empty Element #22. I posted a suggestion but it would be very welcome with your thoughts :)
• pyxl would be amazing. It would be fun to experiment with it but would require so much backing from mypy/LSP/editors to be useful which is way out of scope right now :)
• I added a link to your repo on the References page, I think it can be very useful for others: https://htpy.dev/references/

[davepeck]

Glad it was helpful. Voter Bowl continues to hum happily along using htpy. :-)

I think we need some solution for rendering elements without a parent. I posted a suggestion but it would be very welcome with your thoughts :)

After dwelling on it, I think I like your suggested render(node: Node) -> Markup approach better than my Fragment class.

The main impact of adding render() is that — for consistency — you'll probably want to use it everywhere, even when you know the thing you have is (say) an Element of some sort. You probably no longer want to rely directly on the existence of Element.__str__() which is... okay? Maybe odd? I dunno.

In Voter Bowl, the minor impact is that my Django views will go from return HttpResponse(some_component()) to return HttpResponse(render(some_component())) — even if some_component() is known to return Element.

(Even though I think I prefer render(), considering it in the other direction, Fragment does feel like a natural superclass for BaseElement. Node would include Fragment in its union instead of BaseElement. Top-level component code, like the kind you expect to render in a Django view, would need to return something derived from Fragment; everywhere else, though, returning Node would still be fair game.)

pyxl would be amazing

Yeah, I think JSX is a fairly unambiguous win for the Javascript ecosystem. But, to your point, it didn't come together overnight! So many tools had to build robust support for it before it was really viable. Maybe it's something that the folks at Astral or Pydantic would be game to put real energy into down the road...