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

51–60 of 90 posts

Re: Htmy – Async, pure-Python rendering engine

#51

Post by nickpsecurity »

DonnyV wrote: post #45

Rendering html is something that needs to happen within 300ms. Anything more and its perceived as lagging. So why would you choose python to do visual rendering?

It could be useful for content creators that value reusing their Python expertise over other factors. Also, many apps work better when every integrated component is written in the same language. Also, there’s a lot of code in Python for or supporting web programming. Finally, if people use AI auto-complete, many people say they’re more effective at common uses of Python vs other languages or situations.

I’ve found the performance issue to be serious in some situations. Fortunately, there’s a number of accelerators for Python code that boost its performance. They range from JIT’s (eg PyPy) to custom VM’s (eg Cinder) to writing fast paths in Cython to Python-to-C++ compilers (eg mycpp).

So, you get the productivity and familiarity of Python with performance boosting in many use cases. If it doesn’t work, then it’s better to write that component as an extension in a systems language.

Re: Htmy – Async, pure-Python rendering engine

#52

Post by skeledrew »

johnisgood wrote: post #37
guidopallemans wrote: post #21

Earlier quoted context omitted.

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.

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

Re: Htmy – Async, pure-Python rendering engine

#54

Post by crubier »

scotty79 wrote: post #48
rafram wrote: post #46

Earlier quoted context omitted.

I just completely disagree. Async is syntactic sugar that can be reduced to sync code with callbacks. It doesn’t exist on equal footing. If you want to call sync code from async code, you just… call it. If it performs blocking IO, it’ll block, but that’s exactly what it would do if called from other sync code, too. By contrast, calling async code from sync code requires a special blocking wrapper (Python) or unavoida…

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

> Tbh await should be default function call semantics and there should be special keyword for calling without awaiting.

Your comment made me realize this is exactly what golang "go" keyword does. This is actually great.

Re: Htmy – Async, pure-Python rendering engine

#55

Post by globular-toast »

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.

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

Re: Htmy – Async, pure-Python rendering engine

#56

Post by shkkmo »

zupa-hu wrote: post #41
Jaxan wrote: post #28

Earlier quoted context omitted.

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.

"rendering engine" has a pretty clear meaning and is a pretty poor term to use for a system for tranforming one kind of text bits into another.

Perhaps you should consider using less confusing terminology in your vocabulary?

https://developer.mozilla.org/en-US/docs/Glossary/Engine/Ren...

Edit: You say "often used for both" but I am struggling to find any other examples. Yhe closest I can find is this extremely poorly named static site generator project: https://github.com/render-engine/render-engine?tab=readme-ov...

Edit2: Man, the appropriation of the term "rendering" by JS people has led to some pretty stupid stuff, like this statement: "SSR, short for Server-Side Rendering, is a technique in web development where the webpage's content is rendered on the server instead of the client's browser."

Re: Htmy – Async, pure-Python rendering engine

#58

Post by koolba »

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.

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

Re: Htmy – Async, pure-Python rendering engine

#60

Post by mattigames »

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…

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.
Post reply on HN