Welcome to the Project! · PyHAT-stack/awesome-python-htmx · Discussion #1
What is this?
This group came out of a burst of inspiration at PyCon US 2023 to take on and defeat JS once and for all! bring together and organize the up-until-now largely disparate individuals working on the same class of problems.
Who are we?
We are a collection of people who have:
- bought into the dream described by htmx author Carson Gross in his various essays (start here if you haven't read any).
- grown to resent the modern web, particularly what JS SPA's have done to it.
- Love building applications in Python
- Love TailWindCSS and CSS utility classes in general (this point is potentially optional if you are not onboard with this point, but are with everything else).
Specifically at this time we are @benjamin-kirkbride and @tataraba, but hopefully soon, we will be many more than that!
What are we doing?
The immediate goals of this initiative as we have conceived it are as follows:
- Identify (through awesome-python-htmx) the players and projects involved in this space.
- Attempt to gather a quorum of people passionate about and working on solutions surrounding the intersection of Python Web frameworks and htmx talking in the same space
- Work out some common terminology for the various patterns/libraries/features that people are using to enable the creation of Hypermedia Driven Applications, specifically using Python and htmx.
- Create a set of opinionated project templates for various Python Web Frameworks, using existing and potentially new libraries.
Call to action
At this stage, we need people to be found, brought into the fold, and start talking to each-other. If you know someone who is interested, especially someone who has made something with or for htmx + Python, please send them to here.
Open questions
- How should we organize? Discord is very popular and low-friction for real-time communication, but it can be difficult for new people to come up to speed quickly and it's not indexed by search engines. Using discussions and issues in GH makes things much more accessible and discoverable, but also adds a lot of latency and friction to communications.
- Where should we focus our efforts in creating/curating tooling and templates? The most mature framework for htmx use at this point seems to be Django, but FastAPI is currently where most of the hype is, and is easier to start working with (IMO?). Thoughts?
I would also greatly appreciate feedback on the name (PyHAT, pronounced pie-hat). If people like it/don't have anything better, it would be awesome if people started using the term in their materials/docs so we can gain some mind-share.
3 replies
PyHAT is okay for me. It is not as “cool” as PETAL that is used in the Elixir-Community, but I don't have a better idea, to be honest. So, I am fine with PyHAT.
Hi, just my two cents. I’d opt for something more straightforward:
- aptx / atpx / patx (could probably feature a domain using the obscure letters and make a thing out of it)
- phat-stack
1 reply
Thanks for the feedback. I did see that project but decided to go with the name for two reasons:
- We are in very different spaces; this is not a "project" per se, it's more of an initiative/a web stack
- It does not appear to be active, last commit was mid 2020
If others feel strongly that it's a problem, we can evaluate other options though.
Regarding your questions:
- Both are fine for me
- IMHO the awesome list is missing a "when not to use" part. SPAs have heir advantages , too. This part then could help new users to make an informed decision before investing time into HTMX and creators of HTMX related tools get a list of things to improve ;). Apart from that, more non "Hello World" examples on how to use HTMX might be helpful, in the form of templates/tutorials/... .
8 replies
@benjamin-kirkbride yes, mostly what @tataraba noted below. I have a non public example application to check limits of HTMX for bigger apps by building a simple E-Mail client. Can ping you once it can be publicized.
@tataraba missed that, sorry. These points do match my experience so far as well though. Would appreciate them being a little bit more prominent :)
One additional aspect I am missing with FastAPI and Jinja2 at the moment in big projects is the ability to easily refactor code and the template at the same time, e.g. get IDE/... support to not miss that one variable in the template. Not sure if that applies to other python based approaches as well though.
@lllama nice list. Maybe the E-Mail client example can go in there, but not in a timely manner!
Regarding the templating with both the template and code in one file: I'm thinking about that for fastapi-htmx as well. Mainly for easier refactoring but also for code locality. This component/module based approach of SPAs did work quite nice for me. Maybe we can port the advantages over ;). fastapi-htmx currently already supports some modularization features for url rewriting + history, but it depends on includes in the template to work.
Is your approach based on a particular templating engine or framework? Do you have anything public yet?
My initial attempt was with Starlette (because imho, FastAPI doesn't offer much over that when you're just doing templates.)
My new attempt is with Sanic. The reason is that it's a great developer experience plus it ships with a server, so deployment is a little easier. I'm taking the Svelte approach in that I'm "compiling" the single files into a "standard" Sanic app.
A little update from me. This project plus binging some Theo videos on YouTube made me decide to build in Tailwind support to sanic-kit. The project will now download the latest Tailwind CLI and set up a basic config for the project. Running the server will spin up a Tailwind watcher as well, so any changes to the templates will result in new CSS being generated. Next step is to sort out some form of live reload.
This is great!
I recently started a "from scratch" FastAPI web app again to chronicle what felt "necessary" to start a PyHAT build. While there are several decisions that could use some automation or CLI usage to enhance the experience, I feel like it's not too terrible, once you know what you're aiming at. One thing you said earlier really sticks with me ,though;
Given that htmx is all about HOWL, I'm not sure whether there's such a thing as an "htmx specific" framework but having worked on an app I think the two main things that help are template fragment support and a helper middleware for decoding headers etc.
I think this is absolutely correct, especially the fragment support. I also think the helper middleware (like starlette-htmx and/or similar packages) is intriguing.
I haven't tried that solution yet, but it seems like it would be very helpful as well.
I also really like what you are doing with sanic-ki for the tailwind stuff, particularly running the watcher on app startup. I have a build command on app startup, but makes sense to include an option to start a watcher as well!
This is excellent! Definitely worth watching pyscript as it develops as a project -- could potentially be applicable to the goals of this stack/project. :)
1 reply