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

21–30 of 90 posts

Re: Htmy – Async, pure-Python rendering engine

#21

Post by guidopallemans »

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?

Re: Htmy – Async, pure-Python rendering engine

#22

Post by ramon156 »

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.

Because checking for two conditions is impossible? This seems like a solution for a non-existent problem. I could be missing something

Re: Htmy – Async, pure-Python rendering engine

#24

Post by franga2000 »

eddautomates wrote: post #16

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.

Re: Htmy – Async, pure-Python rendering engine

#25

Post by worthless-trash »

franga2000 wrote: post #24
eddautomates wrote: post #16

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…

Spoken like a true dynamic types programmer. Some programmers prefer having errors over these surprises.

Re: Htmy – Async, pure-Python rendering engine

#27

Post by mattigames »

azinman2 wrote: post #23

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

Re: Htmy – Async, pure-Python rendering engine

#30

Post by anentropic »

kissgyorgy wrote: post #17
pplante wrote: post #5

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

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

Post reply on HN