Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Htmy – Async, pure-Python rendering engine

volfpeter.github.io

Post reply on HN
Print view View original

31–40 of 90 posts

Re: Htmy – Async, pure-Python rendering engine

#31

Post by anentropic »

mattigames wrote: post #19
rafram wrote: post #8

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.

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?

Re: Htmy – Async, pure-Python rendering engine

#32

Post by anentropic »

devjab wrote: post #13
dcreater wrote: post #6

Is there a comparison or guide to choosing python frameworks? Every few weeks there's a new one posted here

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

Re: Htmy – Async, pure-Python rendering engine

#33

Post by rubenvanwyk »

anentropic wrote: post #30
kissgyorgy wrote: post #17

Earlier quoted context omitted.

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 th…

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

Re: Htmy – Async, pure-Python rendering engine

#34

Post by fermigier »

dcreater wrote: post #6

Is there a comparison or guide to choosing python frameworks? Every few weeks there's a new one posted here

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.

Re: Htmy – Async, pure-Python rendering engine

#35

Post by scotty79 »

rafram wrote: post #8

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.

Re: Htmy – Async, pure-Python rendering engine

#37

Post by johnisgood »

guidopallemans wrote: post #21
keithasaurus wrote: post #7

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.

Re: Htmy – Async, pure-Python rendering engine

#38

Post by liendolucas »

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.

Re: Htmy – Async, pure-Python rendering engine

#39

Post by rafram »

scotty79 wrote: post #35
rafram wrote: post #8

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

Post reply on HN