fastHTML - A new way to generate websites from Python

I have been working with a new web technology called fastHTML, developed by Jeremy Howard and answer.ai. FastHTML is a way to develop web apps straight from python without the need for extensive javascript, flask etc.

Why does this matter?

As time has progressed so the stack of software tools that you need to know to develop an app has increased. As somebody from a scientific and machine learning background I have worked mainly with Python and the libraies that work with this such as pytorch, matlab, numpy, pandas etc. As somebody who developed a model it is common for that model to be then integrated into a app by a team of people, some with database experience, some that deal with the infrastructure the app needs to work, some with the frontend. Typically the tools required for an app developer as compared to a model developer are NPN, Node, CSS, typescript, oauth, webpack, bundlers, react / svelt / vue, websockets, javascript, shadowdom, firebase, graphhgl (list taken from fastHTML site). This enormous software stack can be overwhelming and can make it very difficult for individuals to develop an app themselves, indeed most modern web apps require a team of people to develop and maintain. FastHTML, requires a little html and css knowledge but removes the need for most of the other libraries, making it much easier and simpler to work with.

Underpinning fastHTML are a number of well established technologies, two of the most important being ASGI and HTMX. The ASGI is provided by Uvcorn and Starlette, the former a web server, the latter a framework for building web applications. HTMX is possibly the key to enabling fastHTML to be competitive with current state of the art web technologies but at the same time much simpler. HTMX is explained in at the Hypermedia Systems website and indeed there is a free ebook there. HTMX enables a web page to change only the parts of a webpage that need to be changed and can be triggered by almost any event such as a mouse pass over etc. This avoids one of the main traditional issue of html websites, that the whole page had to be reloaded after every click or entry.

To put this into context, modern web pages are almost always of a type called SPA (Single Page Applications). Such web pages do not operate in the way originally intended when html was developed, which was for the web application to navigate between pages, instead they use complex client side javascript models stored in a browser. The javascript model sends data backwards and forwards to the server and updates the page accordingly. HTML still provides a framework but the majority of the work is done by the Javascript model. This makes modern web pages more akin to thick client applications of the 1980s.

The reason the web moved this was was that this architecture made it possible to have a much richer user experience than the older HTML hypermedia systems could facilitate. The fact that this was developed and adopted despite the vastly increased complexity shows how important this enhanced functionality was.

So why am I going on about a new web framework when SPA and the associated Javascript frameworks are so well established? To answer this I will quote from the hypermedia systems book:

Given the popularity, power and success of this modern approach to building web applications, why on earth would you consider an older, clunkier and less popular approach like hypermedia?

JavaScript Fatigue

We are glad you asked!

It turns out that the hypermedia architecture, even in its original Web 1.0 form, has a number of advantages when compared with the Single Page Application + JSON Data API approach. Three of the biggest are:

• It is an extremely simple approach to building web applications.

• It is extremely tolerant of content and API changes. In fact, it thrives on them!

• It leverages tried and true features of web browsers, such as caching.

The first two advantages, in particular, address major pain points in modern web development:

• Single Page Application infrastructure has become extremely complex, often requiring an entire team to manage.

• JSON API churn — constant changes made to JSON APIs to support application needs — has become a major pain point for many application teams.

The combination of these two problems, along with other issues such as JavaScript library churn, has led to a phenomenon known as “JavaScript Fatigue.” This refers to a general sense of exhaustion with all the hoops that are necessary to jump through to get anything done in modern-day web applications.

We believe that a hypermedia architecture can help cure JavaScript Fatigue for many developers and teams.

The reason that the hypermedia team have suggested that this architecture can help is that HTMX is a hypermedia oriented library that allows users to achieve the same or even better user experience as can be achieved using SPA's but with much reduced complexity. The diagram below illustrates this:

What this is showing is the massive bloat in complexity that has arisen since the early days of the web and how HTML can massively simplify a modern web page.

What fastHTML has done is integrate HTMX and ASGI (plus other elements that I haven't discussed) into a python environment in such a way that a python coder with limited knowledge of web technology can build sophisticated web apps without having to learn any of the frameworks such as React. The key differentiation offered by fastHTML is explained better than I can manage on their site fastHTML foundations

The feedback from established web developers is that this is indeed a big change, and the number of websites using the technology is likely to grow fast, especially amongst developers used to working with data, python and AI, that have a need a way to get their products and ideas available to the community as fast as possible and without the cost and leadtime of more traditional web apps.