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

61–70 of 90 posts

Re: Htmy – Async, pure-Python rendering engine

#61

Post by littlestymaar »

v3ss0n wrote: post #44
liendolucas wrote: post #38

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) t…

Sometimes I want to do things totally pure html, with more dynamicness and more reusability. Jinja template fall short.

This! I recently wanted to get back to writing a web app entirely rendered on the server side without the need for a JavaScript framework and I was really struck by how embarrassingly clumsy templating engines are compared to JSX.

Re: Htmy – Async, pure-Python rendering engine

#63

Post by volfpeter »

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.

Thanks for this answer. Async support is handy if the framework in which you're using the tools is async (let's say FastAPI). See my answer to a similar question on reddit: https://www.reddit.com/r/Python/comments/1fvv11p/comment/lqb...

Re: Htmy – Async, pure-Python rendering engine

#64

Post by volfpeter »

anentropic wrote: post #31
mattigames wrote: post #19

Earlier quoted context omitted.

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

You're right, fetching all the data (that you may or may not need during rendering) in advance is of course doable and quite common. That's what you do for example with tools like Jinja. That may or may not work well for your use-case.

htmy does not force you to put data fetching or anything else into components (you can still have dumb components). It also doesn't force you to write async components. The most important thing it does is it gives you the option to build your application entirely in Python (no ugly custom templating language syntax with lack of static analysis or proper IDE support) and enables the use of modern async tools.

And admittedly, the lib was built with FastAPI and HTMX in mind, which kind of necessitates async support...

Re: Htmy – Async, pure-Python rendering engine

#65

Post by scotty79 »

koolba wrote: post #58
scotty79 wrote: post #35

Earlier quoted context omitted.

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.

> Async infrastructure allows your stuff to be sync or async. While sync infrastructure forces your stuff to be sync. Is that specific to the threading model for Python? The reverse is true in nodejs where once you’ve got one async call, the entire chain must be async.

Python is the same as JS.

Async function (that returns something you need) can be called only from async function. That's why autor of this specific rendering framework/lib chose it to be async. So that the user functions called in components can be either sync or async.

Re: Htmy – Async, pure-Python rendering engine

#66

Post by volfpeter »

mattigames wrote: post #60
anentropic wrote: post #31

Earlier quoted context omitted.

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

It seems like the view endpoint would be for functionality shared the full view, like auth safeguards and such, while the components would fetch the data they need; this would make it so you don't need to pass around the data to the view and save a few lines of code; of course this is not compatible with the idea of having "dumb" components vs "logic" ones like people do in React and alike.

Components don't really need to fetch anything, they don't need to be smart. It's up to you where data fetching happens. If you look at fasthx for example, you'll see that routes/views normally handle your business logic and fasthx does the rendering (now with Jinja or htmy). With Jinja for example, it can only work like this. With htmy, you have more flexibility (which can be an advantage but of course it can also be misused).

Async components can be handy for example when you need to load files. See the Snippet utility and the markdown support in the lib. https://volfpeter.github.io/htmy/examples/markdown/

Re: Htmy – Async, pure-Python rendering engine

#67

Post by volfpeter »

liendolucas wrote: post #38

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) t…

That's a fair point, although my feeling after working quite a bit with Jinja recently is the opposite (primarily for lack of static analysis and IDE support).

You're right, for example the documentation should be improved quite a bit. Keep in mind that this project is pretty new, I simply had no time to add more docs or further improve the existing one.

Ps.: with the Snippet utility and markdown support, you can actually write quite a bit of your HTML in a html files rather than Python. You could even use Jinja templates as the backend for some of your components. This part will see more work as I have spare time to work more on the project.

Re: Htmy – Async, pure-Python rendering engine

#68

Post by btown »

gpderetta wrote: post #49
scotty79 wrote: post #48

Earlier quoted context omitted.

> By contrast, calling async code from sync code requires a special blocking wrapper (Python) ... That's exaclty my point. If you don't have async by default in your platform you need to do stupid things to fake it. If function calls and main in Python were innately async you could be calling async code just as easily as sync code. > [...] or unavoidably breaks control flow (JavaScript). async/await syntax avoids it…

> would require small revolution that might happen at some point. or python could have blessed gevent and done away with all the nonsense.

I hope that someone does an oral history of why gevent wasn't seen as the solution here. The existence of models like Twisted, and a general idea that yields to an event thread should be explicit in some way, I think caused the exact kind of fracturing of the ecosystem that everyone was trying to avoid. "Everyone will write async code" simply didn't happen in practice.

Re: Htmy – Async, pure-Python rendering engine

#69

Post by johnisgood »

skeledrew wrote: post #52
johnisgood wrote: post #37

Earlier quoted context omitted.

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.

JavaScript is optional even on the client side nowadays with the advent of PyScript via WASM, etc.

I did not know that. Is it true? Can I have dynamic updates (something like what AJAX does) without refreshes? If so, I need to do some research in this area! I assume I can use any programming languages for WASM as well?

Re: Htmy – Async, pure-Python rendering engine

#70

Post by volfpeter »

globular-toast wrote: post #50

There is already htpy: https://htpy.dev/ I have used it in production and like it. For those asking the point is being able to do similar to React JSX components, but on the server side. It's so much nicer to use than templates like Django or Jinja (there might be other reasons, but this is quite clearly the goal of htpy and I assume this too). Just looking at this one briefly it seems to use magic methods on datacla…

I've seen htpy before starting this project. While creative, I'm not too happy with the interface if I'm honest and it feels quite a bit more limited.

There are no magic methods really, you can even write function components. Using dataclasses in examples is also an irrelevant technical details.

The actual reason for requiring an `htmy()` method is that this way you can turn any of your business objects (be it Pydantic or SQLModel classes for example) into components without the fear of a method name conflict with your business stuff. Actually, I expect/planned this to be a very frequent use-case, and then there'll be zero unnecessary nesting.

Post reply on HN