[pplante]

I was looking for something like this a few weeks ago. I typically use Django and hate the template engines limitations. I needed to make some reusable components and the best option available was switching to jinja to get their macro support, bleh.

This reminds me of the best part of Flutter UI composition, but in a language I always return to.

Have you done any benchmarking? I don't even know what the comparison would be.

[kissgyorgy]

Check this out: https://compone.kissgyorgy.me/

Much simpler than this library, components are simply functions, rendered to strings.

I made one microbenchmark, it's "only" 2x slower than Jinja2 right now, but I know how to make it faster.

[globular-toast]

How many of these are there? I also pointed out htpy elsewhere in the thread.

[anentropic]

if you can make it as fast as jinja2 I'm sold ...I haven't done my own benchmarking but so far I haven't seen any of these HTML-in-Python libs able to report comparable performance

I've implemented a bunch of AlpineJS "components" as jinja macros in my current project and ... it works, but it's pretty ugly and it sucks not having type safety or ability for the IDE to understand connections between the template and the Python code

what I really want is something like JSX/TSX for Python... having gone through this process I can see why that approach is desirable. I kind of feel like libs which mimic the syntax but unable to provide the type-safety/IDE support are missing the point. So although I love the look of "Python HTML element objects" approach libs like yours and OP have I think for now it is probably the best way available.

for my current project we are pre-compiling all the jinja templates (via Jinja's own utils) for deployment as AWS Lambda

I did look into JinjaX but it has its own separate jinja env and secondary template cache and didn't look like it would be easy to plug it into the pre-compile step

[rubenvanwyk]

+1 for TSX for Python, that would be great!

[neeleshs]

You might want to look at django-cotton for components

[volfpeter]

I haven't done benchmarking yet. To be fair, I had limited time and I focused on developer comfort and the features I needed for projects I work on. Simplicity and flexibility was another goal: the rendering engine itself is as minimal as possible, but can be replaced or optimized in the future.

I'll probably do a simple comparison with Jinja (using FastAPI) this week. Given that I can put an htmy() method on my business objects (it was an important design consideration, no conflict with other tools), I expect an okay results, but we'll see.

[volfpeter]

I did some testing in the meantime. Depending on what you render, it's about an order of magnitude slower currently.

The renderer is as simple/minimal as possible at this point (the focus was on the core feature set I needed until now), so it's performance is as bad as it can be :) There's plenty of room for improvement. I'll work on a few optimizations as I have time, but contributions are more than welcome.