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

81–90 of 90 posts

Re: Htmy – Async, pure-Python rendering engine

#81

Post by skeledrew »

johnisgood wrote: post #69
skeledrew wrote: post #52

Earlier quoted context omitted.

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?

Sure, dynamic updates are possible. Re language support, I'm only aware of PyScript for Python, and Blazor for C# already being fairly mature. But there are other language ports in progress.

Re: Htmy – Async, pure-Python rendering engine

#82

Post by volfpeter »

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…

I did some testing in the meantime. Depending on what you render, it's about an order of magnitude slower currently.

The renderer is as simple/minimal as possible at this point (the focus was on the core feature set I needed until now), so it's performance is as bad as it can be :) There's plenty of room for improvement. I'll work on a few optimizations as I have time, but contributions are more than welcome.

Re: Htmy – Async, pure-Python rendering engine

#83

Post by rafram »

BerislavLopac wrote: post #74
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…

> Async is syntactic sugar that can be reduced to sync code with callbacks The whole point of introducing async was to get away from callback hell.

Yeah, I’m not saying that callbacks are good, I’m saying that async is a veneer over callbacks.

Re: Htmy – Async, pure-Python rendering engine

#84

Post by rafram »

physicsguy wrote: post #75
rafram wrote: post #47

Earlier quoted context omitted.

But does it actually work that way? If I `await fetch_from_api()` in the first component before returning the tree with the second component that fetches from my backend, `fetch_from_api()` has to resolve before Htmy finds out about the second component.

You’d have to structure it differently, it’s definitely not a free lunch

Right, but if this framework enabled that optimization, I’d expect it to have some examples showing how you’d implement it. As far as I can tell, there’s no way to structure your code to allow parallel component rendering with this framework.

Re: Htmy – Async, pure-Python rendering engine

#85

Post by murkt »

mixmastamyk wrote: post #59
murkt wrote: post #4

Would love to see some benchmarks for all these libraries that compare them to Jinja2.

They are almost always slower, because jinja uses some compilation tricks. But, it usually doesn't matter compared to remote database access.

In my experience it doesn't matter if templates are pretty simple, or the database access is not optimized. Can matter if you're not careful.

Re: Htmy – Async, pure-Python rendering engine

#86

Post by v3ss0n »

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.

You had never tried gevent in production then. As soon as workload and concurrency increases python programs with gevent or gevent based drivers, especially monkey patches causes unexpected crashes out of the blue, no way to debug, no error message,Memory leaks and whole slew of nightmares

Re: Htmy – Async, pure-Python rendering engine

#87

Post by v3ss0n »

btown wrote: post #68
gpderetta wrote: post #49

Earlier quoted context omitted.

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

So many production problems that we never seen in development comes in and no way to debug

Re: Htmy – Async, pure-Python rendering engine

#89

Post by volfpeter »

rafram wrote: post #84
physicsguy wrote: post #75

Earlier quoted context omitted.

You’d have to structure it differently, it’s definitely not a free lunch

Right, but if this framework enabled that optimization, I’d expect it to have some examples showing how you’d implement it. As far as I can tell, there’s no way to structure your code to allow parallel component rendering with this framework.

With the current renderer (which is super basic because simplicity and features were the main priority over optimization for now), if a component has multiple async children, they will be resolved concurrently. I assume that's what you meant by "parallel". Not sure why that would need an example, but you can simply create a component that calls asyncio.sleep(1), then create a bunch of instances and render them to test it.

I want to have at least the same level of concurrency when the new, better optimized renderer lands.

Re: Htmy – Async, pure-Python rendering engine

#90

Post by johnisgood »

skeledrew wrote: post #81
johnisgood wrote: post #69

Earlier quoted context omitted.

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?

Sure, dynamic updates are possible. Re language support, I'm only aware of PyScript for Python, and Blazor for C# already being fairly mature. But there are other language ports in progress.

What do they call this these days, dynamic updates using WASM?
Post reply on HN