fasthtml-example is a shelf of runnable FastHTML apps you can open and copy

One directory per technique, each a self-contained app

The repository is a catalogue rather than a framework. The README describes it as a collection of example applications built with FastHTML, and the layout makes that literal: every example lives in its own directory at the top level, and each directory holds a complete small application with its own dependencies.

Four are highlighted in the README. Game of Life, the todo app, the chatbot and Pictionary get their own sections with screenshots. The rest are listed only by their folder names, and the names alone tell you what they cover: 04_sse, htmx, infinite_scroll, passkey, oauth_example, cli_oauth_example, code_editor, code_highlight_and_copy, annotate_text, image_classification_app, image_app_session_credits, image_app_simple, e_commerce, chess_app, doodle, story, echo, helloworld, h2f, hacker_news_reskin, devtools, 3d-component and xtermjs.

Read as a catalogue, that list is a map of the techniques a web project needs and the framework has an answer for. There is a directory for uploads, one for a 3D component, one for a terminal emulator widget, one for passkeys and one for OAuth, both browser and command line. There are two todo examples plus todos1 and todos2-hf variants, so the same problem appears more than once in different shapes.

The README is clear about the status of all of this. The remaining examples are proofs of concept and demos rather than full-fledged applications, and they are offered as patterns and techniques you can reuse in your own projects.

Game of Life synchronised over WebSockets

The first highlighted app is Conway's Game of Life, and the point of it is the concurrency. The README describes an interactive grid with real-time updates across multiple clients and WebSocket integration for live synchronisation, and the directory ships an animation GIF of the result.

That is a deliberate choice for a first example. A grid that changes on its own is easy to fake on one screen, and hard to fake on several, so the example forces the two things you need in a real-time web app: a way to push changes to connected clients and a way to apply an incoming change to the local state. If you are writing anything collaborative, a dashboard with live numbers, or a page where several people edit, this is the pattern to read first.

The WebSocket direction of travel matters too. The application is not just fetching updates on a timer, so a client that connects late has to be brought up to the current state, and the code in 00_game_of_life is where you can see how that initial state is delivered.

The todo app: SQLite and updates without a reload

The second highlighted app is a todo list, and the README describes it as simple yet functional, demonstrating dynamic updates and database integration.

The feature list is the interesting part: adding, editing and deleting items, marking them complete, real-time updates without page reloads, and SQLite as the store. A SQLite file is the right choice for an example because it needs no server to set up, and the todo folder also shows the boring half of a real application that a demo often hides. The page needs a list, a form, an edit path, a delete path and a complete toggle, and every one of those is a round trip to a database.

It is also the easiest example to adapt. If you have ever wanted to see how a FastHTML application handles a create and update cycle end to end, this is the one.

The repository carries several sibling todo variants, including todos1, todos2, todos2-hf and the highlighted 01_todo_app directory, and there is a separate story directory and an annotate_text directory. The duplication suggests different approaches to the same problem rather than a single canonical version, which is useful if you want to compare rather than copy.

Chatbot styling with DaisyUI and Pictionary captioning with a multimodal model

The chatbot example is about presentation and message updates. The README describes a simple chatbot that demonstrates custom styling with DaisyUI for the chat message bubbles, and it notes that it includes different approaches to handling chat message updates. The screenshot in 02_chatbot shows the result.

Two lessons hide in that directory. First, a component library can be used for the visual layer without giving up control of the markup, which matters when a chat window needs behaviour that a theme does not describe. Second, when messages arrive out of order or in bursts, the handling of updates is a design decision, and seeing two approaches side by side saves you from discovering the hard way.

Pictionary is the example with an external dependency. The README describes sending user drawings to a multi-modal AI model for continuous captioning, and the animated GIF in 03_pictionary shows the loop. The interesting engineering is the streaming shape: the model answers continuously while the user is still drawing, so the application has to accept partial answers and update the display.

What the README does not explain is how the model is configured, which key is needed and what happens when it is missing. You will need to read the code in that directory before you can run it, which is a reasonable thing to expect from an example repository but worth knowing before you plan around it.

Running any example takes a requirements file and one command

The instructions in the README are uniform across the collection. You navigate into the directory of the app you want, install its dependencies, usually with pip install -r requirements.txt, and then run the command the app's own README specifies.

pip install -r requirements.txt

The command is typically one of two:

uvicorn main:app

python main.py

The distinction is worth noticing. A uvicorn entry point exposes an ASGI application called app in a module called main, which is what you would deploy. A python main.py entry point runs a script that starts its own server, which is what you would use to poke at the example in place. Some apps support both, and the app-level README decides.

Two files outside the app directories support the collection. deploy.sh sits at the top level, and there is a document called deploying-to-pythonanywhere.md, so at least one deployment path is written down rather than assumed. The devtools directory is there for the tooling around the examples.

Every app is standalone, which means the cost of trying one is a virtual environment and a dependency install. That is the main practical argument for the repository: you can find the pattern you need and run it without reading FastHTML documentation end to end.

Licence text, missing releases and what the examples are not

Two details matter before you copy code out of here.

The first is the licence. The GitHub listing for the project records Apache-2.0, while the README links an MIT licence file and calls it the MIT License. Those are different licences with different obligations, so the LICENSE file in the repository is what you should read before you paste a directory into a commercial project. This is a licensing fact rather than legal advice, and it takes a minute to settle.

The second is the versioning. The repository has no tagged releases at all, and the last push to the default branch was on 2026-09-09. There is no changelog to read and no version to pin, so if you depend on an example, copy it into your own repository rather than pointing at it.

It is worth restating what this collection is not. It is not a framework, so the API reference lives in the FastHTML project itself, and the acknowledgements section points there for the capabilities being demonstrated. It is not a set of production applications, by the README's own description. And it is not a single application with a shared shell, since each directory is independent with its own requirements and its own entry point.

The contribution guidance is short: pull requests are welcome. The maintainers are, in effect, inviting people to add examples, which tells you something about how the collection is meant to grow.

Editorial conclusion

Adopt fasthtml-example when you are starting a FastHTML project and want a working pattern for the piece you are unsure about, such as server-sent events, passkeys, OAuth, an infinite scroll list or a terminal widget, and each app is small enough to read in one sitting. Do not adopt it as a framework reference, since the README says these are proofs of concept and demos, and the repository carries no tagged releases. Before you copy anything, check the LICENSE file, because the GitHub listing records Apache-2.0 while the README links an MIT licence, and read the requirements.txt of the specific example you plan to borrow, since dependencies differ per directory and the Pictionary app also depends on a multimodal model that the README does not explain how to configure.

Frequently asked questions

Official sources

1. AnswerDotAI/fasthtml-example on GitHub
2. Issues
3. License: Apache-2.0
4. README