HTML before SwiftUI

I was working through a feature for Danki: let someone tap the English keyword attached to a kanji, understand where that word came from, and replace it with something more useful to them.

My usual instinct would be to open the iOS project and start building. Add the SwiftUI views. Thread the new state through the app. Find the right data source. Run the simulator. Navigate back to the card after every change. At that point, even an unfinished idea has acquired architecture.

Instead, I used the Visualization feature in Codex. The result was one self-contained HTML file: an iPhone-sized interface with real buttons, a bottom sheet, an editor, and enough state to click through the whole decision.

The idea became discussable

The feature started with a product question, not an engineering one. A kanji keyword is a useful memory handle, but it is not a complete definition. For 泊, should the learner see “overnight stay,” “put up at,” or “ride at anchor”? How much dictionary evidence belongs on screen? When does helpful context become clutter?

Those questions are hard to resolve in a list of requirements. They became much easier when I could tap the keyword, see an action sheet rise, enter the editor, and compare KANJIDIC2 with JMdict and vocabulary from the app.

The visualization did more than show three attractive screens. It made the transitions between them concrete. I could judge whether editing was discoverable, whether the source hierarchy made sense, and whether a custom keyword felt consequential enough when it would later appear in reviews, search, and widgets.

Why HTML changed the pace

HTML is not inherently better than SwiftUI. It was simply the cheaper medium for the question I had at that moment.

The file opened instantly. Changes to spacing, hierarchy, copy, and behavior stayed local to the prototype. I did not need to preserve app state, satisfy the compiler, migrate data, or make an early decision fit Danki's existing architecture.

More importantly, the prototype was easy to throw away. That is a feature. Disposable code makes it emotionally and technically cheaper to admit that the first idea was wrong.

A lightweight prototype separates product uncertainty from engineering uncertainty.

The visualization is not the feature

The HTML prototype does not prove that the finished iOS feature is accessible, localizable, performant, or pleasant with real data. It does not handle persistence, Dynamic Type, VoiceOver, navigation state, or all the strange edges a production app eventually reveals.

That is still SwiftUI work. The point is not to replace native development. The point is to arrive at native development with fewer unresolved product decisions.

Use the lightest medium that can answer the question

A sketch is enough when I am asking about placement. A static mockup is enough when I am asking about hierarchy. When the question involves taps, transitions, and state, a small HTML visualization occupies a useful middle ground: more real than a picture, much lighter than an app feature.

In this case, Visualization moved the work forward because it let me spend my attention on the idea itself. When I eventually build the SwiftUI version, I will not be starting from a vague description. I will be translating a flow I have already used, questioned, and changed.