How do I handle AI coding assistance when FastHTML isn’t as well-known as React/Next.js?

Developers worry about “swimming upstream” by choosing FastHTML when AI assistants like Claude and GPT-4 have much better training on mainstream frameworks.

The solution is investing in good cursor rules and context files. Isaac shared that he uses detailed cursor rules for FastHTML that provide examples and patterns. He notes: “if you give the right context to the model…it does a lot better.” The companion repo includes these cursor rule files that help AI understand FastHTML patterns.

Wade from the Discord added another perspective: “Cursor + good cursor rules has proven to be a good combo for me personally.” The key is that with FastHTML, you’re working with ~80 lines of code for a functional annotation app versus hundreds more with other frameworks. This smaller codebase is easier to understand and debug when AI suggestions go wrong.

As Isaac put it: “I find that with pure vibe coding, I start out with super fast progress then my iteration speed slowly gets worse over time until I get really frustrated.” With FastHTML plus good context, you maintain consistent development velocity.

Should I build a custom annotation tool or use something off-the-shelf?

At the moment there is a narrow gap between how long it takes you to build your own labeling thing and configuring an off the shelf tool (Argilla, Prodigy, etc.). There is a non-trivial amount of things that you have to sort through to configure all the settings with an off-the-shelf tool, as well as some limitations.

Custom tools make sense when:

• You have domain-specific workflows (like the medical flashcard example Isaac showed)
• You need tight integration with your data pipeline
• Your annotation needs will evolve based on what you learn

However, existing tools have advantages for:

• Large-scale team collaboration with many distributed annotators
• When you need enterprise features like detailed access controls
• If you have standard annotation needs that fit the tool’s paradigm

Isaac’s Anki flashcard annotation app demonstrates when custom makes sense - they needed to handle 400+ results per query with keyboard navigation, multi-step review processes, and domain-specific evaluation criteria that would be difficult to configure in a generic tool.

How should I handle disagreements between annotators in my annotation app?

Annotation disagreements are inevitable, but the workflow for resolving them depends on whether you’re refining the rubric or just collecting labels. Many teams struggle with when to show annotations to other reviewers.

Answer: The approach depends on your goals. Shreya explains: “If you truly want independent annotations from annotators, yes you might want to hide comments. But sometimes the annotators are jointly working together to review a large amount of traces…and showing the comments standardizes interpretations of good and bad between annotators.”

Isaac’s implementation takes a pragmatic approach: “Eventually we need to decide what score to assign to it. We could do a second round where annotators cannot peek at other comments. However, in the AnkiHub case, they found that annotator disagreements often stemed from incomplete rubrics.” This highlights a key principle - if you’re still defining what “good” looks like, facilitating discussion between annotators helps refine the rubric. Once the rubric is stable, you might want more independent annotation.

The FastHTML app Isaac built handles this with a “finalized” step where disagreements trigger a review process with comments, allowing annotators to explain their reasoning and reach consensus.

When should I use FastHTML vs Streamlit for annotation apps?

Isaac recommends FastHTML when you need flexibility beyond simple dashboards. Isaac elaborated that “FastHTML is more flexible and a full web app. If you feel like you have some really custom or unusual things that might be tricky to get right, maybe not streamlit.”

The key differentiator is state management complexity. As discussed in the Discord, “state management in streamlit is a nightmare if you have anything a bit complex.” For simple annotation interfaces with minimal state, Streamlit works fine. But once you need features like multi-step workflows, keyboard shortcuts for rapid annotation, or custom UI components, FastHTML’s flexibility becomes valuable.

The choice depends on your needs - start with Streamlit if it meets your requirements, but be prepared to switch to FastHTML if you hit limitations.

Why

You are often already using a database for your web application, and if you need to process items in that database with some kind queue, its convenient to use the database itself!

First, let’s define our queue table:

from fastlite import *
Path('queue.db').delete()

db = Database('queue.db')

class QueueItem:
    id: int
    data: str
    expire: int  # Unix timestamp

queue = db.create(QueueItem, pk='id')

Now, let’s implement the enqueue operation:

def enqueue(data): return queue.insert(data=data, expire=0)

For the dequeue operation, we’ll implement the logic described in the comment:

import time
def dequeue():
    available_items = queue(where="expire = 0", limit=1)
    
    if not available_items: return None  # Queue is empty
    
    item = available_items[0]
    future_time = int(time.time()) + 300  # 5 minutes from now
    
    # Step 2: UPDATE SET expire = future_time WHERE id = item.id AND expire = 0
    updated_item = queue.update(id=item.id, expire=future_time)
    
    if updated_item.expire == future_time: return updated_item
    else: return dequeue()

Let’s See It In Action!

# Enqueue some items
enqueue("Task 1")
enqueue("Task 2")
enqueue("Task 3")

# Dequeue and process items
while True:
    item = dequeue()
    if item is None:
        print("Queue is empty")
        break
    
    print(f"Processing {item.data}")

Processing Task 1
Processing Task 2
Processing Task 3
Queue is empty

Limiting Async Tasks

To limit the number of tasks that can be running concurrently, we can use a asyncio.Semaphore. A semaphore allows us to control access to a shared resource, in this case, the number of concurrent tasks. ¹ Here’s how it works:

import asyncio

# Create a semaphore with the maximum number of concurrent tasks
max_concurrent_tasks = 5
semaphore = asyncio.Semaphore(max_concurrent_tasks)

async def limited_task(task_id):
    async with semaphore:
        print(f"Starting task {task_id}")
        await asyncio.sleep(2)  # Simulate some work
        print(f"Finished task {task_id}")


tasks = [limited_task(i) for i in range(5)]
_ = await asyncio.gather(*tasks)

Starting task 0
Starting task 1
Starting task 2
Starting task 3
Starting task 4
Finished task 0
Finished task 1
Finished task 2
Finished task 3
Finished task 4

Define the server

#The "I'm done" messages will be printed after this cell
if IN_JUPYTER:
    from fasthtml.jupyter import JupyUvi, jupy_app, HTMX
    app, rt = jupy_app()
    server = JupyUvi(app) 
else:
    app,rt = fast_app()

I'm done
I'm done

async def long_running_task():
    await asyncio.sleep(5)  # Simulate a long-running task
    print("I'm done")

@rt("/")
def get():
    return P("Async Task Demo",
        Div(
            Button("Start Task", hx_post="/start-task", hx_swap="outerHTML"),
            id="task-button"
        )
    )

@rt("/start-task")
async def post():
    # These will run in the background since we aren't calling await.
    # There are multiple tasks, and asyncio.gather is one way of kicking them off
    asyncio.gather(long_running_task(), long_running_task())
    return Div(
        P("Task started! Check your console in 5 seconds."),
        id="task-button"
    )

HTMX()

server.stop()

Run with a process

We are starting a thread inside a new process so it runs in the background. Remember, parallel will execute f in a new thread.

It will print kinda wierd because of the threading and things completing at the same time.

from multiprocess import Process
p = Process(target=g)
p.start()

154832
76

Run with a thread

Instaed of starting a thread in the background with a process, we can also start it with another thread.

from threading import Thread
t = Thread(target=g)
t.start()

51
8
7
6

4
2
3

How to choose Threads vs. Processes

See my blog post.

If your tasks involves network calls, consider using threads. For CPU intensive tasks, use processes.

@threaded decorator

This will make functions run in the background in a new thread or process.

from fastcore.parallel import threaded

@threaded # casuses g to be threaded
def g(): parallel(f, a, threadpool=True)
    
    
@threaded(process=True) # casuses h to be run in a process
def h(): parallel(f, a, threadpool=True)

g()

<Thread(Thread-9 (g), started 6248116224)>

12
4
6
3
5
7
8

h()

<Process name='Process-3' pid=40899 parent=40147 started>

42538761

startthread

We can also start a thread by calling the startthread function.

from fastcore.parallel import startthread

def g(): parallel(f, a, threadpool=True)
startthread(g)

# this will run right away in the main process, since the other code is running in the background
print('hello') 

hello
12
3
4
5
6
7
8