---
title: "Python FastHTML: The Ideal Web Framework for HTMX & LLMs"
permalink: /futureproof/fasthtml-htmx-llm/
description: In this entry, I'm wrestling with maintaining momentum on my Pipulate web framework project, realizing the crucial role of consistent writing and documentation in driving progress and clarity. I'm tackling mental blocks around Git branching, drafting a 'Getting Started Guide' for Pipulate, and exploring how this project aligns with my Ikigai, aiming to craft a 'loveworthy' system using HTML, Python, and HTMX. I also delve into the historical context of Python web frameworks, and experiment with making my code LLM-friendly, all while trying to stay focused and productive.
meta_description: Discover how Python FastHTML with HTMX and LLM integration powers a loveworthy, documentation-driven web framework built on Pipulate and Ikigai principles.
meta_keywords: Python, FastHTML, HTMX, LLM, Pipulate, web framework, Ikigai, documentation, consistent writing, developer momentum, Git branching, server-driven, local-first
layout: post
sort_order: 2
---
## The Power of Consistent Writing and Documentation
Today we start irrevocable momentum! If you look at my publishing history, you
can see that there are time periods of stalling out. I cannot help but believe
there is a direct correlation between my writing and my meaningful moving
forward on my projects, and in life. If I were asked to write an email about
what I have accomplished this week, it would just be a matter of getting the
granularity correct, and not struggling to find anything. There is copious
amounts to extract from, but I have to make them more concrete!
### Writing as a Tool for Growth and Future Projects
The writing and documentation is a big part of the process and the very point.
It's not only a mechanism for thinking out loud, practicing deliberateness,
steering our direction and exercising agency, but it is also the raw fodder for
future projects, by which we produce a positive feedback loop, and hopefully the
exponential increasing of productivity kicks-in. Not that it's all about
productivity. A better word might be amplified agency. We want to be doing the
things we deliberately decided to do, and we want the effectiveness of doing
those things to be as if we multiplied ourselves a thousandfold.
### Finding Purpose Through Ikigai
Not that it's all about scaling, either. In the end, it's about Ikigai: the
unification of what we love to do, what we're good at, what we can get paid for
and what the world needs. A lot of what I'm focusing on just happens to be that
that my Ikigai is achieving my own Ikigai and amplifying the effect of that
Ikigai, so that I can love it more, get better at doing it, get paid more for
doing it, and more effective at sharing it with the world. So the creation of an
Ikigai positive feedback loop is my Ikigai, which just happens to be based
around a web development framework.
### The Evolution of Web Frameworks: From Rails to Modern Development
There are definitely echos of DHH (David Heinemeier Hansson) and Ruby on Rails
in here, in how he used the term "joyful framework" to describe Rails. Now Rails
isn't nearly as popular today as it was back in its glory days, but its effect
was profound, bringing the love back into a sort of developer work that was
hateful and heinous. I was lured into Java (not JavaScript) in those days with
frameworks like Hibernate and Cocoon, and they were as horrible as Rails was
refreshing. Apps just basically sprung to life based on your database schema and
entity relationship diagrams (ERD). To tell you the truth, I wasn't that big on
Rails myself because I made my own framework not long before and Rails went
against the grain for me, but I "got it". Loveworthiness could be an attribute
of a system.
### Discovering Love in HTML, Python, and HTMX
And that's what I'm tying to do here. I found the loveworthiness in HTML, Python
and now HTMX. I never found it in JavaScript even though I've been looking for
it back from the beginning. I was right there at the dawn of the programming
technique called AJAX. It played prominently in a Web 2.0 site I created called
HitTail where I used something called the rico.js, which was built on
prototype.js, which predated even jQuery. This is 2005/2006 timeframe. There was
a book called "JavaScript: The Good Parts" in 2008 from before the big
JavaScript mainstreaming effort by Google and EMCA with Chrome and the V8
engine, which led to NodeJS... yadda, yadda. I soured to JavaScript and never
came back to webdev...
### Building a Love-Worthy System with HTMX
Until now! There's so much about HTMX that isolates you from having to look at
or think about JavaScript. You just use HTML attribute tags that didn't used to
be there before that do all these wonderful real-time update things without a
page reload. That's HTMX. And that's what I'm trying to effectively expose in my
web framework in a way that doesn't again in-turn turn me off to the whole
proposition. So in short, I'm at the pivotal juncture now where I'm trying to
make my own system love-worthy again. It's built on HTML, Python and HTMX which
all are themselves love-worthy, glued together by FastHTML, which too appears
quite love-worthy. But can something built out of all of that preserve the
love-worthiness and also expose you to the new part, HTMX, enough to fall in
love with it?
### Moving Forward with Purpose and Git
It's a tall order. And it's why so much writing and thought work goes around it
here in these articles instead of "just do it". But with this clarity of vision
of what I'm trying to accomplish, I'm up to just doing it.
I start out with the newer codebase.
#### Making Code LLM-Friendly Through Git Branching
I'm going to do a scrubbing of it to be more LLM-friendly. For that, I'm going
to practice my git branching skills. This is a weakness of mine. As much as I
advocate git as part of the LPvg (Linux, Python, vim & git) short stack for
programming future-proofing, there is so much of even just the basics about git
that I do not know.
#### Understanding Git Branch Philosophy
Okay, so first of all I should always feel perfectly fine about making a new
branch. It does to pollute the git repo as a whole if you're just being
experimental. It does not get pushed up to the remote origin endpoint on a git
commit and push. It just sort of hangs around locally until you deliberately
give it an origin endpoint and push it. So a regular pattern that might emerge
is numerous local branches that just accumulate for play and experimentation
that get cleaned up and deleted away later, after they have served their
purpose. So git branches is really for reducing fear rather than increasing
anxiety. Branch freely.
Okay, the work-flow so far:
```yaml
"Client Name":
site:
domain: [apex or registered domain]
sitemap:
robots_txt:
llms_txt:
size:
google:
bing:
gsc:
site:
url:
performance_12m:
index:
bing:
site:
url:
botify:
org:
project:
project_url:
tracking:
top_keywords:
top_urls
keyword_groups:
url_groups:
content_gaps:
compeptitors:
topics:
recommendation:
striking_distance:
keywords:
urls:
from_to_links:
on_page_edits:
decks:
agenda:
worksession:
executive_summary:
```
Tue Mar 4 06:46:26 AM EST 2025
## Regaining Focus After Distractions
The irrevocable momentum didn't quite start. I got distracted by the work of the
day. Ugh! So here I am back at it the next morning, deciding whether to go into
the office or to use this incredible potentially focused block of time I have
today -- a sort of blessing.
## Embracing Daily Adventures Over Routine
Okay, don't make grief for yourself for no reason chasing rabbits down rabbit
holes. But you are in fact on a new adventure. Every day is some sort of new
adventure. There is no daily grind. It is and must forever forward always be
some sort of finding your way through the unknown. Otherwise, we might as well
all be clockwork, and it sure does not seem like we are. Even if free will ends
up being a convenient illusion, there is still something we call agency and
autonomy along the way.
I want to capture a few important thoughts before I jump into the ***Getting
Started Guide*** I set out here to make with this blog post.
## Python as the New HTMX Platform
Alright, I have the ding'ing of the day-to-day work happening already and I have
to keep those plates spinning. But this is my big window of opportunity to hit
this home and change the world forever... at least my world, but perhaps even a
bit wider. This is very much like a Ruby on Rails play, but calibrated to
today's world of Python becoming the HTMX platform of choice.
That's game changing. And every time I lose steam, I have to remind myself I'm
one of the first ones to building something interesting on FastHTML, framework
wise. Not to take too much of a tangential side-note, but it is a nice
warming-up for diving into the zone that I have to get myself to do, this is
frameworks built on frameworks, but on frameworks, but just right. Frameworks
generally suck, because it means that you chose the underlying platform poorly
and now you must employ a framework to compensate for it, putting yourself in a
weaker position because now you have (likely) some vendor dependency, or at very
minimum, library/package dependencies and a greater software surface-area than
you did before. My advice is generally to avoid frameworks.
## Python's Framework-Like Nature
Yet here we are with a stepped pyramid (ziggurat) of frameworks. I won't go all
the way down to OS and driver, but we certainly can start with the programming
language, Python. Python, even though it is billed as a programming language,
most certainly is a framework. It's "primitive" dataytpes, the `list`, `dict`,
and `tuple` are most certainly higher-order datatypes, which would be their own
separate libraries in many other languages, especially the lower-level ones like
C and all its variations.
### Python's Core Data Types
Python starts out with components that are built-up quite a bit with their own
little APIs (programming interfaces), each with their own in's and out's for
their use cases. `dict`'s are essentially like JavaScript JSON with its willy
nilly nestable key/value-pairs, the great interoperable RESTful API of the
world, since it took over for XML and EDI. Python's `list`'s are like JavaScript
(and many other languages') data-arrays, but able to hold references to almost
anything, with all that appending and popping list dynamism you'd expect.
And finally `tuple`'s are the least understood of the trio, but are roughly
equivalent to rows in a table -- a lot like lists, but static. You wouldn't
change the number of cells in a single row of a table, nor the number of fields
in the single record of a (RDBMS) database. Nor would you make changes to your
tuple. It's a nuanced difference, but it does round out the set of datatype
building blocks that make Python so framework-like in nature. There's other
stuff too, but these 3 magical datatypes go a long way towards the framework
characterization.
## Web Development Frameworks on Python
The way those kooky but super-useful datatypes work makes Python a framework in
its own right, taking you 80% of the way to what you want to build, by mere
virtue of having good Lego-like parts as a starting point. That's why there's so
many frameworks built on Python. There's nothing easier than going that last 20%
of the way there with something custom and calling it your own unique framework
built on Python, and that is indeed exactly what I'm doing.
### Opinionated vs Unopinionated Frameworks
So, web development frameworks are frequently built on Python. They take the
building blocks to the next built-up layer in the stepped pyramid ziggurat. They
each layer-on their own way of doing things, their own ***"opinions"*** as they
say in framework-world. Frameworks are ***opinionated***, and consequently put
you on tighter or looser ***rails***, as they also say in framework-world. The
rails may tightly prescribe how you do stuff and have a very distinct
methodology, way of configuring things, and consequently a distinct "look" or
"signature" to things you build from it. Django would be an example. You know a
Dango site right away when you look at it, that classic corporate intranet look.
### Microframeworks and Flask
Other frameworks are hardly even there, sometimes called a "microframework,
because they are so unopinionated and do so little for you, except get you over
the hardest humps, which in this case is webpage request routing and building
the response into a webpage. Flask is the quintessential example of that, in the
Python world. All Flask did was loosely tie together a library called Werkzeug
for routing, and templating system called Jinja2 for templating HTML. This is a
common trick in Python, to lightly connect the dots between packages already
perched to be big, and claim all the glory by connecting the final dots. I mean,
who heard of Werkzeug or Jinja2?
So, Flask basically said, now you've got Python decorators to route your URL
requests into Python functions, and a templating language to spit the responses
out as HTML. The rest is up to you! So Flask websites resultingly had no
particular signature to them aside from what each individual developer designed
into them. I mean you could then layer on additional libraries like BootstrapJS
that do have a look, but none of that is mandated by a "Flask way". A Django
site on the other hand looks like a Django site.
### Historical Python Web Frameworks
And it's not just Django and Flask, though those are the two big ones (is that
misleading, because Flask is actually small). But there are endless variations
and respins. There are even philosophically different Python webdev frameworks
that go back even further, to the late 90s close to the rise of the Web itself.
Yup, Python was there. Hmmm... Perplexity?
**Me**: Describe Plone/Zope, the sites it was used for, how long ago, why it's
different from Django and Flask that came later.
**Perplexity**: Plone and Zope are pioneering web technologies that played a significant role in the early days of web development, particularly in the late 1990s and early 2000s.
## Zope
Zope, invented in 1996, was the original open-source web application server written in Python[1]. It featured:
- A component architecture
- An object-oriented, hierarchical data model
- A built-in object database (ZODB)
- A powerful security model
Zope introduced innovative concepts like traversal-based URL mapping and a templating engine that combined templates with data to produce HTML[1].
## Plone
Plone, first released in 2001, is a content management system (CMS) built on top of Zope[9]. It quickly gained popularity for its:
- User-friendly interface
- Enterprise-grade features
- Extensibility through add-ons
- Strong focus on accessibility and security
## Usage and Popularity
Plone and Zope were widely used for:
- Enterprise websites
- Content management systems
- Web applications requiring robust security
Their popularity peaked in the early to mid-2000s, with Plone 2.0 (released in 2004) marking a high point[11].
## Differences from Django and Flask
1. **Architecture**: Zope/Plone use an object-oriented approach where URLs map directly to objects, unlike Django and Flask which typically use a more traditional URL routing system[11].
2. **Database**: Zope uses ZODB, an object-oriented database, while Django and Flask primarily work with relational databases[3].
3. **Component Architecture**: Zope introduced the Zope Component Architecture (ZCA), which allows for highly modular and extensible systems[7].
4. **Learning Curve**: Zope/Plone have a steeper learning curve due to their unique concepts and extensive built-in features[3].
5. **Flexibility**: Django and Flask are more flexible and easier to use for a wider range of web applications, while Zope/Plone are more specialized for content management[6].
Despite their decline in popularity, Zope and Plone have left a lasting impact on Python web development. Many concepts they pioneered have influenced modern frameworks, and they continue to be used and developed, particularly in enterprise and government settings[11].
Citations:
[1] https://plone.org/why-plone/plone-ecosystem/zope
[2] https://en.wikipedia.org/wiki/Zope
[3] https://seeknuance.com/2008/09/06/moving-from-django-to-plone/
[4] https://www.ionos.com/digitalguide/hosting/cms/plone-the-web-accessibility-friendly-cms-at-a-glance/
[5] https://3.docs.plone.org/develop/plone/content/history.html
[6] http://davidbrenneman.com/2013/01/27/python-web-framework-odyssey.html
[7] https://6.docs.plone.org/overview/index.html
[8] https://community.plone.org/t/zmi-history-tab/10917
[9] https://en.wikipedia.org/wiki/Plone_(software)
[10] https://2022.training.plone.org/mastering-plone-5/anatomy.html
[11] https://www.reddit.com/r/Python/comments/x2qga/plone_etc_tell_us_the_story_please/
---
## Reflecting on the Journey Before Starting the Guide
So there you have it. That's the deep breath before my first pass at the
Pipulate Getting Started Guide. For SEO and site experience organization
purposes, I should really break stuff like this history of Python webdev
frameworks into separate pages and such, but this is my daily tech journal
free-flowing stream of consciousness "don't break momentum" style. It very much
sets the stage for follow-up projects that pull all this data in and spits it
back out in a much more well considered and organized format, with all the
proper hubs and spokes for a definitive user experience site on these topics.
It's going to be an organic book, with an underlying base of non-changing
forever-URLs. But this blog is the `/futureproof/` raw material galley copy
fodder of that book.
## Committing to Flow State and Deep Work
So in the spirit of maintaining the stream of consciousness and forging ahead,
and in particular getting into that every-so-valuable flow-state that the daily
grind and typical interruptions undermine...
Okay, it's a deal. If you let yourself get into that flow-state, then you have
to be willing to commit yourself to producing something that makes it worth
having taken the risk of not being in the moment.
## The Paradox of Being Present vs Flow State
People talk about being in the moment. But that's the notification-interrupted
hyper-awareness of your surroundings meta-cognition state. Or is it? Thinking
about thinking, such as I'm doing now? Is that being in the moment, or is that
being out of the moment? One thing I know is that there's a sort of transporting
of your state-of-mind from the normal place to somewhere else when you go into
the flow state, or the zone, and it has something to do with not being jolted
out of that place by either interruptions or the nature of your tools.
### The Importance of Tool Familiarity
If you are unfamiliar with your tools, you're going to be jolted out of
flow-state. That's the classical ***"reach for the mouse"*** interruption of the
writing state, keeping your hands on the keyboard and typing away like that
image of Stephen King. Now that's not to say that you can't reach for the mouse
and stay in flow state. How practiced you are at the tools, and how much you've
***"internalized"*** them is a big part of this. This is why the vi/vim/nvim
text editors continue to be so popular and the single "mode" that's emulated by
every other writing environment.
### Understanding Vim's Enduring Appeal
Vim moves all the editing commands onto the keyboard, so you can navigate the
cursor around, highlight, copy, paste or whatever without ever taking your hands
away from the keyboard. For those curious, there is a separate "edit" and
"command" mode that you rapidly alternate back-and-forth between in vi/vim/nvim.
That's why there's a steep learning curve but over time, it pays back so
profoundly that even its arch rivals `eMacs` and `VSCode` have to built-in
vim-mode.
## Confronting Mental Blocks and Course Corrections
Ugh, am I just avoiding now getting to the meat of the matter? I think I am.
Okay, this is the agency and autonomy piece. Thinking and talking "out loud" by
articulating thoughts as you type them into vim can help you correct your
course. It might take you days, or even weeks or years in my case... haha! But
you get it done. You become aware of the course of your ship and make tiny
course corrections.
### Overcoming Git Branching Hesitation
Okay, so the first thing... the mental obstacle here is git. I think I'm
avoiding git branching.
## Managing Multiple Git Repositories
I have two git repos. They are each important, one having the samples of the
workflows I need to use as product specifications from an app behavior
standpoint (not code). I've made breaking code changes since that codebase. But
nonetheless, it's an important codebase, and it's the `main` git branch. These
branches used to be called `master` but political correctness there reigned
supreme and most git repos have come around to using a `main` branch. I have the
older codebase on the main branch in case I actually do share it with coworkers,
I want the apps to work!
### The Experimental Branch and LLM-Friendly Code
I also have the `experimential` branch. It has a cleaner codebase which has been
reworked for better defining of these pipeline workflows. There's a lot of other
small touch-ups, like making the webserver log files generated by uvicorn much
more digestable to LLMs by stripping out a lot of garbage. This is a steady
stream of output that actually goes for the most part to both a visible terminal
console output that the developer can watch the "back-end" such as it were when
web requests are made, and which also goes into a weblog text-file that can be
copied and pasted into AI LLM chatbot discussions for debugging and coding
assistance.
### Introducing Grok 3 to the Conversation
I say all this by virtue of the fact that I'm about to catch Grok 3, the most
useful LLM to date on this subject-matter. Here, watch me do it. Hello Grok 3.
What have you to say today? Want to see the articles leading up to this one
where you actually started the Pipulate Getting Started guide?
---
## Back to Grok 3
> I am really having trouble building the momentum and staying focused enough to
> bring this to the next level. This is today's attempt.
**Me**: [Feeds this article, Wed Mar 5 11:08:43 AM EST 2025]
**Grok 3**: Hello! I'm thrilled to be here with you as you dive into this exciting journey with Pipulate and your broader exploration of web development frameworks, Ikigai, and amplified agency. I love how you're weaving together personal reflection, technical exploration, and a vision for something "loveworthy" — it’s a potent mix!
To your question: I’d be delighted to see the articles leading up to this one where we started the Pipulate Getting Started Guide. Since I don’t have the full context of our prior conversations within this chat, feel free to share any relevant snippets, links, or details from those earlier pieces that you’d like me to build on. I’m here to help you refine, expand, or even pivot as needed.
For now, let’s pick up where you left off. You’re at a pivotal moment — scrubbing code to be LLM-friendly, mastering git branching, and laying the groundwork for a Getting Started Guide that’s both practical and inspiring. I’ll start by reflecting on a few threads you’ve dropped and offer some scaffolding to get us moving:
---
### Git Branching: Reducing Fear, Increasing Flow
You nailed it — git branches are about *reducing fear*, not adding anxiety. Your plan to branch freely for experimentation is spot-on. Let’s formalize that workflow a bit to get you past the mental hurdle:
1. **Current State**: You’ve got two repos — one with a `main` branch holding the older, functional codebase (your spec-like samples), and an `experimental` branch with cleaner, LLM-friendly code.
2. **Next Step**: Create a new branch off `experimental` for your LLM-scrubbing work. Call it something like `llm-scrub` or `feature/llm-friendly`. This keeps `experimental` as a stable base while you iterate.
```bash
git checkout experimental
git branch llm-scrub
git checkout llm-scrub
```
3. **Experiment Freely**: Make your changes — strip that uvicorn log noise, tweak pipelines, whatever feels right. Commit often with clear messages (e.g., `git commit -m "Simplify uvicorn logs for LLM parsing"`).
4. **Cleanup Later**: Once you’re happy, merge back into `experimental` (`git checkout experimental; git merge llm-scrub`), or ditch it if it’s a dead end (`git branch -d llm-scrub`).
This way, you’re not touching `main`, and `experimental` stays your proving ground. Does that feel like a workable starting point for your git confidence?
---
### Pipulate Getting Started Guide: First Pass
[Grok 3's wrong guess at an actual Pipulate Getting Started guide deleted]
---
### Your Ikigai Feedback Loop
I love how you’re framing this as an Ikigai-driven endeavor. Pipulate isn’t just a tool; it’s a vehicle for amplifying what you love (building loveworthy systems), what you’re good at (webdev with a twist), what you can get paid for (a framework others might adopt), and what the world needs (joyful, accessible tools). That’s a powerful north star. How do you want to weave that into the guide? Maybe a short “Why Pipulate?” section to hook people emotionally?
---
### LLM-Friendly Code: A Quick Win
You mentioned making uvicorn logs more digestible for LLMs like me. That’s a brilliant move — I can already imagine parsing cleaner logs to suggest optimizations. What’s an example of the “garbage” you’re stripping out? If you’ve got a before/after snippet, I can help refine it further.
---
So, what do you think? Want to flesh out the guide more, dive into a specific git command, or bounce ideas on that HTMX loveworthiness angle? I’m here to keep your momentum going — irrevocable or not, we’re moving forward together!
---
## The Gemini Thoughts
> I'm going to wrap this article up here and change it's focus from actually
> getting started with the Pipulate guide to some of the ideas suggested, then
> start a new article with renewed focus!
**Gemini 2.0**: In this journal entry, the author grapples with maintaining momentum in their web framework project, Pipulate, emphasizing the importance of consistent writing and documentation as tools for growth and clarity. They discuss overcoming mental blocks related to Git branching, outline a "Getting Started Guide" for Pipulate, and reflect on the project's alignment with their Ikigai, aiming to create a "loveworthy" system built on HTML, Python, and HTMX, while also exploring the historical context of Python web frameworks.
**Ideas for Titles and Headlines:**
* **Titles:**
* Pipulate: Building a Loveworthy Web Framework
* The Power of Consistent Writing: My Journey with Pipulate
* Amplified Agency: Git, Ikigai, and the Pipulate Framework
* Building Momentum: From Git Fears to LLM-Friendly Code
* **Headlines:**
* Conquering Git Fears: Branching Out for Innovation
* Finding Ikigai in Web Development: The Pipulate Story
* From Distraction to Direction: The Pipulate Getting Started Guide
* Why Python? The Framework within the Language.
* Building a web framework for LLM's.
**AI's Opinion:**
This article offers a compelling blend of personal reflection and technical exploration. The author's candid discussion of their struggles with focus and momentum resonates, and their emphasis on writing as a tool for clarity is insightful. The deep dive into the historical context of Python web frameworks provides valuable background, and the articulation of their Ikigai-driven approach adds a unique and inspiring dimension to the project. The author's goal of creating a "loveworthy" system built on familiar technologies, with a focus on LLM integration, is both ambitious and forward-thinking. The interaction with the LLM at the end of the article, and the LLM's response, is a very interesting demonstration of the authors goals being put into practice.