UX Design Engineering, JavaScript for interface builders.
A practical course in JavaScript for designers and front-end developers who know HTML and CSS and want to build, debug, and explain real interface behavior.
In progress · 12 chapters
Introduction
Who this book is for
This book is for people who already build interfaces. You can write semantic HTML, lay out a page with CSS, and you understand why a focus style or a clear error message matters. You have probably copied some JavaScript into a project, changed a few lines, and got it working. What you can’t yet do is build an interaction from a blank file, find out why it broke, or explain to a reviewer why your code works.
That gap is common, and most JavaScript courses don’t close it. They start with variables, data types, loops, and algorithms, and reach the page itself somewhere around the halfway point. That order suits someone learning to program. It suits interface builders less well, because the concepts arrive long before there is a reason to care about them.
This book starts with the page instead. Every concept is introduced to solve a specific interface problem: a menu that needs to open, a form that needs to tell people what went wrong, a list that needs to filter as someone types.
The four questions
Every interaction in this book is built by answering the same four questions:
- What state does this interface need to remember? Whether a menu is open, which tab is selected, which tasks are complete, whether a request is still loading.
- What events can change that state? A click, a key press, a form submission, a response arriving from a server, an element scrolling into view.
- What should update on the screen when the state changes? Text, classes, attributes, whole lists of elements, and the accessibility information that assistive technology reads.
- How do we make the interaction usable, accessible, and resilient? It needs to work with a keyboard and a screen reader, survive a slow network, and leave the content readable if the script fails to load.
Variables, functions, arrays, objects, DOM methods, events, promises, observers, and components are all tools for answering those questions. When a chapter introduces one, it says which question it helps with.
How each chapter works
Each chapter follows the same sequence:
- It starts with a user problem and the interface behavior that solves it.
- It explains the mental model, then the JavaScript concept that implements it.
- It builds the smallest version that works.
- It checks that version with a keyboard and a screen reader, then fixes what the check finds.
- It breaks something on purpose and walks through finding the cause.
- It ends with a plain-language explanation of why the code works, and a project that uses the chapter’s ideas together.
The explanation step matters most. If you can say “this works because…” and finish the sentence accurately, you understand the code well enough to change it, debug it, and defend it in a review.
What you need
You need a code editor, a current version of Chrome, Firefox, or Safari, and a way to serve a folder of files locally. The editor’s live-preview extension or npx serve both work. Every example is plain HTML, CSS, and JavaScript loaded with <script type="module">. There is no build step and nothing to install.
What this book leaves out
There is no Node setup, no bundler, no TypeScript, and no React, Vue, or Svelte. Those tools matter, and the last chapters prepare you for them, but they are not what stops most interface builders. What stops them is being able to read JavaScript without being able to make an interface do what they want. Frameworks hide the parts of the browser this book is trying to teach, so it leaves them until you understand what they are hiding.
The book also skips algorithms, class hierarchies, and most of the language features that interface code rarely needs. When something is left out on purpose, the chapter says so and points to where it comes up later.
The book’s projects
The chapters build a set of small, realistic interfaces: a profile card customizer, an account settings page, a task board, a resource library, an event registration form, a support ticket dashboard, an interactive documentation page, and an accessible component playground. Chapter 10 is a bug lab of deliberately broken interfaces. Chapter 11 turns the patterns from earlier chapters into a small component library without a framework. The capstone in chapter 12 brings them together in a documentation site for a small design system.
Table of contents
- 1 The browser is the environment How JavaScript reads and changes a page through the DOM, from selecting elements to updating text, classes, attributes, and data attributes, and a profile card customizer that enhances a page that already works.
- 2 Events How event listeners connect what people do to how the interface responds, from the event object and bubbling to delegation and choosing the meaningful event, and an account settings page built from small behaviors.
- 3 State How to decide what an interface remembers, where that memory lives, and how to keep the page in step with it, ending with a task board that adds, completes, filters, counts, and clears tasks.
- 4 Functions How to organize interface code into small named functions, by refactoring the chapter 3 task board into helpers that calculate, change state, and update the screen.
- 5 Rendering How to model interface data as arrays of objects and turn it into DOM safely, with templates, empty states, and stable ids, building a searchable resource library.
- 6 Forms How native forms work and how to add validation, accessible error messages, and submission states on top of them, building an event registration form with a fake async submit.
- 7 Async behavior and APIs How to design an interface around waiting with promises, async/await, fetch, request state, retry, debouncing, and AbortController, ending in a support ticket dashboard.
- 8 Browser APIs The browser APIs that handle common interface problems (observers, matchMedia, storage, the URL and history, dialog, popover, and Web Components), ending in an interactive documentation page.
- 9 Accessibility-driven interaction How JavaScript behavior affects keyboard, screen reader, zoom, and touch users, covering semantics, names, ARIA states, focus, live regions, and roving tabindex, ending in an accessible component playground.
- 10 Debugging, explaining, and working with AI How to find out why an interface misbehaves using errors, the console, breakpoints, and DevTools panels, how to use AI as a tutor and reviewer, and a bug lab of eight broken interfaces to diagnose and explain.
- 11 Component thinking without a framework How to turn interface patterns into reusable components with clear boundaries, inputs, outputs, and accessibility contracts, and build a tiny vanilla JavaScript component library with no npm and no build step.
- 12 Capstone: a mini design system documentation site A capstone brief for building a documentation site for a fictional design system, with required features, a suggested architecture that reuses earlier chapters' code, milestones, deliverables, and a self-review rubric.