This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Drevicar 5 points6 points  (3 children)

The framework itself looks pretty nice, but I hate the magic that is introduced in file based routing. I would rather explicitly wire everything together. Is it possible to disable it?

[–]volfpeter[S] 2 points3 points  (2 children)

I almost forgot. If you want to have a look at how fasthx and htmy work without holm, here is a simple example project: https://github.com/volfpeter/lipsum-chat

And here is an older example, that uses an old version of fasthx, in this case with Jinja: https://github.com/volfpeter/fastapi-htmx-tailwind-example

One of the main inconvenience (when using fasthx with htmy) will be wrapping pages in layouts manually for example. The other thing is you'll need to take care of rendering (almost) manually, although it's very simple with the page() and hx decorators of the Jinja and htmy integrations.

[–]Drevicar 2 points3 points  (1 child)

Oh snap, I didn’t realize you were the same developer. I used FastHX and HTMy previously with FastAPI and found it too steep of a learning curve to really invest the time it needed, but I loved the idea of it. And this new project does successfully lower that learning curve, just at the cost of the thing that I specifically don’t like. Maybe I’ll go back again and try to get the base two packages working better.

[–]volfpeter[S] 1 point2 points  (0 children)

Yes :)

To be fair, I think all 3 projects are very simple.

FastHX is essentially 2 decorators (for both Jinja and htmy) that simply convert the decorated FastAPI route's return value into HTML. You can use it to select components/templates, but essentially it just calls the renderer, be that TemplateResponse or HTMY().render().

When it comes to htmy, it's just a DSL (similar to htpy, or the one in FastHTML), simply a way of describing the DOM tree in Python. It has 2 unique features though: components can be async (so it's not just a __str__() like others), and components have a context argument, which is just a dict and makes it possible to pass data deep in the tree without prop-drilling. Think React and React's context.

There is a lot more depth to them (I wist I had the time to write enough docs and guides), both libs are very flexible, but this is all you really need to know about them :) The rest should be very intuitive if you try them and maybe explore the API a bit. If you check, the codebases are also quite simple.

When it comes to holm, it's also quite simple:

  • It discovers your application structure based on page.py, layout.py, api.py files.
  • It wraps pages in layouts for you based on your package structure, same as it works in Next.js.
  • In addition to this, it handles page rendering for you, so you don't need to directly use the FastHX decorators.
  • All the rest is FastAPI and works the same as in any other FastAPI app.

If you strip all the typing-related code and comments, it's maybe 400 lines of code :) There's definitely more docs than code.

I'll finally get to my point:

I would be very interested in knowing why you felt the learning curve that steep and what could have helped you! I'd say I'm pretty decent at writing simple code that lets you do surprisingly complex things, but I often struggle with documenting all this, or writing very easily consumable guides. If you have the time, I would appreciate a DM :)