Python FastHTML: The Ideal Web Framework for HTMX & LLMs

By Mike Levin

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:

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

   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.