volfpeter

3 ms·

1.
by volfpeter 1y ago
It's just sugar. It hides the manual template selection, context creation, and rendering logic behind a simple decorator. This way you always write standard FastAPI routes (or you add HTML rendering to existing JSON APIs without changi
2.
by volfpeter 1y ago
It's a shame you did all the rendering manually :) FastHX would have simplified your life a bit. devpush seems really interesting! I wasn't aware of it, but I'll check it out! It also looks great (no surprise there, it's
3.
by volfpeter 1y ago
Well, the thing is, FastHX, htmy, and holm should be powerful an unopinionated. Think of them like ReactDOM, React, and Next.js. On the other hand, I already thought about building a component library for htmy. I'd prefer to do it with
4.
Show HN: Next.js-like Python web framework, built for Htmx with FastAPI(volfpeter.github.io)
6 points by volfpeter 1y ago|6 comments
5.
by volfpeter 2y ago
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
6.
by volfpeter 2y ago
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
7.
by volfpeter 2y ago
Yeah, the renderer itself must be async to enable async tooling, but everything else can remain sync unless async is really needed. Regarding data fetching (it's a recurring theme in the comments), I'd probably do most of my async
8.
by volfpeter 2y ago
That's a pretty complex question. Reflex is a great project with a great feature set, it does everything (client rendering, state sync, API) and you can even write your callbacks in Python. It seems like the best option from this famil
9.
by volfpeter 2y ago
I haven't done benchmarking yet. To be fair, I had limited time and I focused on developer comfort and the features I needed for projects I work on. Simplicity and flexibility was another goal: the rendering engine itself is as minimal
10.
by volfpeter 2y ago
The most important difference is that htmy does not bring its own web framework, you can use it your preferred one (preferably one with async support, but you can always delegate the rendering if you use a sync one).
11.
by volfpeter 2y ago
Funny, I went through the exact same process before I started creating this project :)
12.
by volfpeter 2y ago
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.
13.
by volfpeter 2y ago
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
14.
by volfpeter 2y ago
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
15.
by volfpeter 2y ago
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-
16.
by volfpeter 2y ago
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&#x2F
17.
by volfpeter 2y ago
I just noticed on Reddit that someone posted my package here. I see there are several comments already. I'll try to answer a few as I have time.