Teaching with Drafter

This area is for instructors. If you are a student, you probably want Start or the Reference instead.

Drafter was built for a specific teaching situation: an introductory Python course, mostly non-majors, where students have met functions, dataclasses, and lists, and want to build something they can show other people. Everything in this section assumes that situation, and notes where your course might differ.

Where to go

Why Drafter: the pedagogical case, the tradeoffs against Flask, Streamlit, and raw web development, and the honest limits. Read this first if you are deciding whether to adopt it.
The big ideas: the concepts that carry the whole library, in the order we suggest teaching them.
Beyond the student docs: the advanced surface (events, live updates, media components, configuration, the command line) that the student journey deliberately keeps quiet about.
Student misconceptions: the beliefs novices form about Drafter, what they look like in student code, and how to repair them.
Expert misconceptions: the wrong assumptions experienced web developers (and instructors) bring, mostly by analogy to Flask.
Lesson plans: three ready-to-run session plans (first day, forms and state, testing).
Project ideas: sixteen assignable ideas rated by scope, plus the anti-patterns to redirect.

How the student docs are organized

Students walk a journey: Start (first success), Guided Projects (four tutorials that form the instructional spine), Add to Your App (task pages in learner language), and Your Project (the final-project arc, ending in deployment). Concept pages exist but stay out of the main navigation; students reach them through "Understand it" links after they have already seen the behavior. Knowing this shape helps you assign pages: point students at tasks ("add a form"), not at concepts ("read about state").