Front End
What the user actually sees: the web platform itself, the JavaScript ecosystem on top of it, and the Python shortcuts for when you do not want any of that.
There are two routes to a user interface here, and the site covers both without pretending one is correct.
The first is the real one: HTML, CSS, JavaScript, then a framework, a bundler, a linter, and a build step. The second is to skip it, and let a Python library generate the interface. That is the right answer more often than front-end developers like to admit, particularly for a dashboard or a model demo, which is most of what gets built in this collection.
Before either route there is a third thing, which is deciding what the interface should be at all. The design pages below cover that, and they are the only part of this site that is not about a tool.
Nearly every page assumes a Django REST Framework backend, because that is what these interfaces are put in front of. See Back End for that half.
Design: UI and UX
Twelve pages on designing the interface rather than building it, ordered the way the work runs: understand people, structure the content, design the behaviour, then the surface, then evaluate it. Every page ends with a section on how that discipline fails in practice, which is usually the fastest part to read.
Understanding users and content
| Page | Covers |
|---|---|
| UX Research | Interviews, contextual inquiry, surveys, diary studies, affinity mapping, personas and jobs-to-be-done, journey maps, and how many participants is enough |
| Information Architecture | Content inventory, organisation schemes, the four navigation models, labelling, card sorting, tree testing, search, and URLs as interface |
Designing behaviour and surface
| Page | Covers |
|---|---|
| Interaction Design | Flows, the eight screen states nobody designs, affordances and signifiers, feedback timing, forms, progressive disclosure, undo over confirmation, and Nielsen’s ten heuristics |
| Visual Design Foundations | Hierarchy, grids, the spacing scale, type scale and measure, colour as roles rather than a palette, Gestalt grouping, elevation, and icons |
| Design Systems and Tokens | The three token tiers, naming by role, one source of truth to many platforms, theming light and dark, component API design, versioning, and when not to build a system |
| Responsive and Multiplatform | Content-driven breakpoints, fluid type with clamp(), container queries, touch versus pointer versus keyboard, platform conventions, density, internationalisation and right-to-left |
| Content Design and Motion | Voice and tone, microcopy, error messages that say what to do, empty states, readability, then animation duration and easing, and perceived performance |
Constraints and validation
| Page | Covers |
|---|---|
| Accessibility | WCAG 2.2 AA, POUR, semantic HTML over ARIA, keyboard and focus management, accessible names and live regions, contrast, the 2.2 additions, alt text, and how to test |
| Prototyping and Handoff | Choosing fidelity, wireframing with real content, Figma auto layout, variants and variables, what a developer actually needs, and design QA |
| Usability Evaluation | Heuristic evaluation, running a session, writing tasks that do not leak the answer, facilitating without helping, severity rating, and testing with disabled participants |
| Measurement and Experimentation | Event schema design, funnels, session replay and heatmaps, A/B testing and its limits, HEART, Core Web Vitals, SUS and NPS, and the usual statistical traps |
| Process and Ethics | The double diamond, dual-track delivery, design ops, the dark pattern catalogue and why it is now a legal question, consent and privacy, and inclusive design |
Skipping the Front End
Python libraries that generate the interface, ordered by how much control they give up.
| Page | Covers |
|---|---|
| Streamlit | The most detailed of these. A script becomes a web app, which is why it wins for internal tools |
| Gradio | The same idea aimed at model demos, an input, an output, and a shareable link |
| Plotly Dash | Flask, Plotly.js, and React underneath, exposed as Python. More work than Streamlit, more control in return |
| fastHTML | HTML generated from Python, without the JavaScript layer |
| Grafana | Moved to IaaS, alongside the rest of the observability stack |
The Web Platform
| Page | Covers |
|---|---|
| HTML | The markup itself |
| CSS | Styling |
| Bootstrap | The CSS and JavaScript component framework that saves writing most of it |
| SVG | Vector graphics in the browser, at length |
| Markdown | The lightweight markup behind most documentation, including this site |
| HTTP Headers | Message headers, how Nginx sets them, and CORS, which is the one that breaks a front end against an API |
JavaScript and Its Toolchain
| Page | Covers |
|---|---|
| JavaScript | Writing the front end against a DRF API |
| Fetch API | Promise-based HTTP requests, replacing XMLHttpRequest |
| jQuery | The older way, still met in existing code |
| TypeScript | Optional static typing over JavaScript, compiling back down to it |
| Node | JavaScript on the server, its core concepts and ecosystem |
| npm | Dependency management for all of the above |
| Webpack | Bundling code, styles, and assets into what the browser actually loads |
| Prettier | Opinionated formatting across JS, TS, HTML, CSS, and JSON |
| ESLint | Linting, for the errors formatting cannot catch |
| Highcharts | Charting driven from a DRF endpoint |
| DataTables | Sortable, searchable tables |
| SurveyJS | The JSON format for defining forms and surveys |
React
| Page | Covers |
|---|---|
| React Overview | Fundamentals through to modern patterns and ecosystem tooling |
| React Setup | Getting a project running |
| React Init | The initial scaffold |
| React Libraries | The npm add-ons worth knowing, grouped by what they do |
| React and Django | The full-stack pairing: project structure, how the two halves communicate, deployment, and practice |
| React with Docker | A production setup for Django, DRF, React, and PostgreSQL together, using multi-stage builds, Nginx for static files, and Compose to orchestrate it |
Flutter
The mobile and desktop route, where one codebase targets Android, iOS, Linux, Windows, and macOS.
| Page | Covers |
|---|---|
| Flutter Setup | Getting the toolchain working |
| Widgets | The framework’s whole model is that everything is a widget |
| Dart | The language underneath |
| Riverpod | State management |
Being Found and Measured
| Page | Covers |
|---|---|
| SEO | Split into three layers, of which a full-stack developer owns one completely, shares one, and should refuse the third |
| Website Metrics | Tracking traffic and behaviour through analytics, heatmaps, and log analysis |
| Google Analytics | Wiring GA into a Django project |
Not Covered Yet
- No Vue, Svelte, or Angular. React is the only JavaScript framework covered.
- No testing. Neither component testing nor browser automation appears anywhere.
- Nothing on state management in React specifically. Riverpod covers it for Flutter, but Redux, Zustand, and the modern alternatives are absent.
- Four stubs at two to three cells: React Init, Fetch API, jQuery, and Google Analytics.
- No build-level performance page. Bundle size and code splitting go unmentioned even though Webpack has a page. Core Web Vitals are covered as a design constraint in Responsive and Multiplatform and Measurement and Experimentation, but not as a build concern.
- No worked design example. The design pages are principles and mechanics; none of them takes one screen from research through to built component.