I can't clearly see a use case. I went on to the "why" section but I'm having a hard time trying to understand what this is trying to solve. Perhaps a clear and simple example to see why you would use it could be useful. Also I find it extremely verbose to write HTML the way is shown in the examples at the top. Having used Jinja for a very long time, its simplicity and separation from logic makes it almost (for me) the only templating lang that you need to learn in Python. Writing HTML code the way is shown is clearly not for me, but there might be uses cases for it.
Not clear why HTML rendering needed to be infected with async. None of the example code has a clear need for async - even the `is_admin()` method would be a prefetched property in any reasonable database model.
Async infrastructure allows your stuff to be sync or async. While sync infrastructure forces your stuff to be sync.
If anything sync (not async) infects everything you do.
Of course it depends if you call the infrastructure (then it's better for it to be sync) of if the infrastructure calls you (then it's better to be async).
Rendering engine is something you rarely call, but it often calls your functions.
Yes, and that’s the worst part of async. That’s why you need to be very strategic about where you introduce it into your code in order to minimize the number of functions it infects, not give up and write a framework that’s all async for no good reason.
Yes. But you should be equally strategic about introducing sync code into your platform. Because making your platform sync basically makes it only be able to call sync functions of your code.
It's not that async infects. It's sync that infects and restricts. We are just used to it by default.
The fact that we started from sync was the cause of all the trouble of epic because everything outside of CPU is innately async.
Your counterpoint still naturally involves something like async _somewhere_ (your proposal is just to move it out of the HTML rendering and into an initial data-gathering stage). If you accept that premise then the question is just where the async code goes.
While on some level it makes sense for HTML rendering to be a pure function where the inputs are gathered from elsewhere (potentially asynchronously), it looks like htmy wants to make it easy to define hierarchies of components. Instead of `is_admin()`, imagine a dashboard whose layout is stored in a database, supporting configurable charts of various flavors. The heterogeneity of the data supporting different types of charts makes it hard to efficiently pull data in a single SQL query (equivalently, any reasonable database model), so somewhere in your code you're pulling a bunch of data asynchronously, and somewhere else you're rendering it. The question, still, is "where?"
Going back to the idea of htmy defining hierarchies of components, imagine how annoying it would be to have to manually grab all the data for a "reporting page" component only to feed it straight back into the renderer -- either having to duplicate the hierarchial structure when feeding data into the renderer (a technique some UI libraries employ, though I don't like it) -- or having to come up with a method for flattening that hierarchy when instantiating the component (another technique some UI libraries employ, one I like more for small projects and less for large ones).
They solve that (to the extent that you think it needs solving) by bundling all that background logic into the components themselves. Did they really need to implement that recursively instead of just walking the hierarchy, gathering the data up-front, and populating it? Eh. The code winds up being similar either way, and either way it definitely forces async back into the middle of HTML rendering.
Mind you, that tends to either make some applications hard to build or to cause the framework to explode in complexity over time as people need new and new ways to say "yes, re-render this thing; no, re-render that other thing, but don't grab its data, ...." There's enough less particularly annoying code involved though that fat, smart components are a natural place for people to gravitate.
Unrelated to htmy completely, a technique I like from time to time even for problems which don't need async per se (and I'm usually using lower-level languages, so the implementation is some sort of more manual continuation pattern, but all those things are basically async, so I won't dwell on the details) is explicitly designing pausable/restartable structures for long-running computations. It's about as easy to write as purely iterative code, and you can run the result as purely iterative with no runtime overhead, so the downsides are low. It opens the door though to easily tuning how long you defer invariant maintenance (too infrequent and your algorithm devolves to the slow thing it's replacing, too frequent and the overhead isn't worth it), easily checkpointing a computation, adding other custom runners for an algorithm (like animating its progress), .... I can absolutely see a use-case for wanting to visualize each step of an HTML rendering, or log OS network counters after each step, and so on. Python's async isn't really the right tool for the job for that (it's hard to modify the runtime to support them without building quite a lot of nonsense from scratch), but async in the abstract isn't bad at all per se.
Imagine you have 2 big components, one fetches from an third-party API and the other from your backend, this way they can load at the same time instead of sequentially.
I was imagining more like you have a Django view that does all the async data fetching and then you hand off the results to a 'dumb' page component that does only rendering
I guess the point is to have components know how to fetch their own data, particularly when combining with HTMX and having backend return page fragments that correspond to components. But maybe this makes more sense in React than it does when translating the pattern back to server-side?
But there are many others. Not sure I understand the point of async rendering, unless you want to mix IO with rendering? Which feels a bit too close to old PHP+html for my blood.
What's wrong with the old PHP+html ways? It's one of the best toolchains to knock out a small to medium sized project. I guess that fundamentally, it's not scalable at all, or can get messy wrt closing tags and indenting. But with this approach I think you're good on both these aspects?
For websites you make for Tor, you would typically go for PHP or OpenResty, as it needs to be JavaScript-free. I personally aim for JavaScript-free projects regardless.
Of course if you want client-side whatever, you need JavaScript.
But what do you do use to create dynamic updates on the client side? I’m guessing it still has JS and makes API calls, no? And if so, it seems easier (to me) to just do all of the rendering client side and let the backend just be REST queries.
This is just the static html renderer, it has no JavaScript to update client side, but the author has another project for fastapi + this + htmx: https://github.com/volfpeter/fasthx
Consider updating your vocabulary because the term is often used for both.
Note that rendering to the “screen” really means writing bits at a memory range, which is just one interface for displaying things. Html is another, higher level interface these days.
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.
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
In the real world, for web things, people use django or fastapi. I'd suggest picking a project with lots of stackoverflow questions and poking around their docs to see which makes you the most comfortable. Personally I tend to favor litestar these days since it has good docs and issues don't sit around for years waiting on one dude to merge prs (fastapi) and it's a lot nicer than django (and I hate django docs).
Flask/quart are painful to work with due to horrible documentation in my experience, but they're popular too. Quart is just an async rewrite of flask by the same owners.
Note: as you probably know, popularity is not necessarily correlated with "actively maintained". For instance, Hug and Sanic are quite popular, but haven't seen a commit for quite a long time.
I think the “rule of thumb” is that none of them are better than using HTMX with templates. HTMX obviously having some limits in terms of security and complex REBAC.
Please don't! Pydantic demands 100% type correctness at runtime in a language that can't guarantee basically anything at "compile" (lint) time. Screw up one type annotation for one edge case and your entire system turns into one big ValidationError.
Dataclasses let you return "incorrect" data and that's a good thing. I'd rather get an unexpected None here and there (which can be handled) than have library code crash because the wrong type snuck into a field I don't even care about.
As for support, is any explicit support needed? You can Pydantic models into things expecting dataclasses and often the other way around too.
Probably, but I fail to see how that's relevant here.
This is not a "dataclass heavy" library in any sense, they just used dataclass in the examples to make them shorter.
Based on everything I see in the documentation, you should be able to use Pydantic models as well, or standard python objects, or anything else, as long as it has a method `def htmy(self, context: Context) -> Component`.
I can't clearly see a use case. I went on to the "why" section but I'm having a hard time trying to understand what this is trying to solve. Perhaps a clear and simple example to see why you would use it could be useful. Also I find it extremely verbose to write HTML the way is shown in the examples at the top. Having used Jinja for a very long time, its simplicity and separation from logic makes it almost (for me) the only templating lang that you need to learn in Python. Writing HTML code the way is shown is clearly not for me, but there might be uses cases for it.
Not clear why HTML rendering needed to be infected with async. None of the example code has a clear need for async - even the `is_admin()` method would be a prefetched property in any reasonable database model.
Async infrastructure allows your stuff to be sync or async. While sync infrastructure forces your stuff to be sync.
If anything sync (not async) infects everything you do.
Of course it depends if you call the infrastructure (then it's better for it to be sync) of if the infrastructure calls you (then it's better to be async).
Rendering engine is something you rarely call, but it often calls your functions.
Yes, and that’s the worst part of async. That’s why you need to be very strategic about where you introduce it into your code in order to minimize the number of functions it infects, not give up and write a framework that’s all async for no good reason.
https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...
Yes. But you should be equally strategic about introducing sync code into your platform. Because making your platform sync basically makes it only be able to call sync functions of your code.
It's not that async infects. It's sync that infects and restricts. We are just used to it by default.
The fact that we started from sync was the cause of all the trouble of epic because everything outside of CPU is innately async.
Your counterpoint still naturally involves something like async _somewhere_ (your proposal is just to move it out of the HTML rendering and into an initial data-gathering stage). If you accept that premise then the question is just where the async code goes.
While on some level it makes sense for HTML rendering to be a pure function where the inputs are gathered from elsewhere (potentially asynchronously), it looks like htmy wants to make it easy to define hierarchies of components. Instead of `is_admin()`, imagine a dashboard whose layout is stored in a database, supporting configurable charts of various flavors. The heterogeneity of the data supporting different types of charts makes it hard to efficiently pull data in a single SQL query (equivalently, any reasonable database model), so somewhere in your code you're pulling a bunch of data asynchronously, and somewhere else you're rendering it. The question, still, is "where?"
Going back to the idea of htmy defining hierarchies of components, imagine how annoying it would be to have to manually grab all the data for a "reporting page" component only to feed it straight back into the renderer -- either having to duplicate the hierarchial structure when feeding data into the renderer (a technique some UI libraries employ, though I don't like it) -- or having to come up with a method for flattening that hierarchy when instantiating the component (another technique some UI libraries employ, one I like more for small projects and less for large ones).
They solve that (to the extent that you think it needs solving) by bundling all that background logic into the components themselves. Did they really need to implement that recursively instead of just walking the hierarchy, gathering the data up-front, and populating it? Eh. The code winds up being similar either way, and either way it definitely forces async back into the middle of HTML rendering.
Mind you, that tends to either make some applications hard to build or to cause the framework to explode in complexity over time as people need new and new ways to say "yes, re-render this thing; no, re-render that other thing, but don't grab its data, ...." There's enough less particularly annoying code involved though that fat, smart components are a natural place for people to gravitate.
Unrelated to htmy completely, a technique I like from time to time even for problems which don't need async per se (and I'm usually using lower-level languages, so the implementation is some sort of more manual continuation pattern, but all those things are basically async, so I won't dwell on the details) is explicitly designing pausable/restartable structures for long-running computations. It's about as easy to write as purely iterative code, and you can run the result as purely iterative with no runtime overhead, so the downsides are low. It opens the door though to easily tuning how long you defer invariant maintenance (too infrequent and your algorithm devolves to the slow thing it's replacing, too frequent and the overhead isn't worth it), easily checkpointing a computation, adding other custom runners for an algorithm (like animating its progress), .... I can absolutely see a use-case for wanting to visualize each step of an HTML rendering, or log OS network counters after each step, and so on. Python's async isn't really the right tool for the job for that (it's hard to modify the runtime to support them without building quite a lot of nonsense from scratch), but async in the abstract isn't bad at all per se.
Imagine you have 2 big components, one fetches from an third-party API and the other from your backend, this way they can load at the same time instead of sequentially.
I was imagining more like you have a Django view that does all the async data fetching and then you hand off the results to a 'dumb' page component that does only rendering
I guess the point is to have components know how to fetch their own data, particularly when combining with HTMX and having backend return page fragments that correspond to components. But maybe this makes more sense in React than it does when translating the pattern back to server-side?
e.g. same author has this https://github.com/volfpeter/fasthx?tab=readme-ov-file#htmy-... which is doing that, but there's still a 'view' endpoint. Why not put the data fetch code there and have 'dumb' components that don't need to be async?
Because checking for two conditions is impossible? This seems like a solution for a non-existent problem. I could be missing something
There's a bunch of these kinds of html renderers. Here's mine: https://pypi.org/project/simple-html/
But there are many others. Not sure I understand the point of async rendering, unless you want to mix IO with rendering? Which feels a bit too close to old PHP+html for my blood.
What's wrong with the old PHP+html ways? It's one of the best toolchains to knock out a small to medium sized project. I guess that fundamentally, it's not scalable at all, or can get messy wrt closing tags and indenting. But with this approach I think you're good on both these aspects?
For websites you make for Tor, you would typically go for PHP or OpenResty, as it needs to be JavaScript-free. I personally aim for JavaScript-free projects regardless.
Of course if you want client-side whatever, you need JavaScript.
But what do you do use to create dynamic updates on the client side? I’m guessing it still has JS and makes API calls, no? And if so, it seems easier (to me) to just do all of the rendering client side and let the backend just be REST queries.
This is just the static html renderer, it has no JavaScript to update client side, but the author has another project for fastapi + this + htmx: https://github.com/volfpeter/fasthx
Oh it's server side "rendering"?
To me “rendering engine” also means something else. Namely taking html and rendering it to the screen.
Consider updating your vocabulary because the term is often used for both.
Note that rendering to the “screen” really means writing bits at a memory range, which is just one interface for displaying things. Html is another, higher level interface these days.
Hypertext markup Yanguage?
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.
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.
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
+1 for TSX for Python, that would be great!
You might want to look at django-cotton for components
How does this compare with FastHTML?
Slower because there is no fast in the name.
Would love to see some benchmarks for all these libraries that compare them to Jinja2.
Looks great. Anyone using this in production?
Is there a comparison or guide to choosing python frameworks? Every few weeks there's a new one posted here
In the real world, for web things, people use django or fastapi. I'd suggest picking a project with lots of stackoverflow questions and poking around their docs to see which makes you the most comfortable. Personally I tend to favor litestar these days since it has good docs and issues don't sit around for years waiting on one dude to merge prs (fastapi) and it's a lot nicer than django (and I hate django docs).
Flask/quart are painful to work with due to horrible documentation in my experience, but they're popular too. Quart is just an async rewrite of flask by the same owners.
Litestar has a half baked comparison chart here: https://docs.litestar.dev/latest/
Not a comparison, but a fairly comprehensive list that I maintain, with github stars as a proxy for popularity:
https://github.com/sfermigier/awesome-python-web-frameworks
Note: as you probably know, popularity is not necessarily correlated with "actively maintained". For instance, Hug and Sanic are quite popular, but haven't seen a commit for quite a long time.
I think the “rule of thumb” is that none of them are better than using HTMX with templates. HTMX obviously having some limits in terms of security and complex REBAC.
HTMX + templates are complementary to a backend framework rather than an alternative to one
Or Unpoly. I've been working with it for a month now and it's a real pity such a robust library it gets so little attention.
Looks similar to a framework I've been using for some personal sites reflex.dev, pretty cool when would you recommend using this over that?
I think in almost-2025 any dataclass heavy library should probably use pydantic (or support it)
Please don't! Pydantic demands 100% type correctness at runtime in a language that can't guarantee basically anything at "compile" (lint) time. Screw up one type annotation for one edge case and your entire system turns into one big ValidationError.
Dataclasses let you return "incorrect" data and that's a good thing. I'd rather get an unexpected None here and there (which can be handled) than have library code crash because the wrong type snuck into a field I don't even care about.
As for support, is any explicit support needed? You can Pydantic models into things expecting dataclasses and often the other way around too.
Spoken like a true dynamic types programmer. Some programmers prefer having errors over these surprises.
Probably, but I fail to see how that's relevant here. This is not a "dataclass heavy" library in any sense, they just used dataclass in the examples to make them shorter.
Based on everything I see in the documentation, you should be able to use Pydantic models as well, or standard python objects, or anything else, as long as it has a method `def htmy(self, context: Context) -> Component`.