Building a Local-First Focus Environment in the Browser

VOXEL_DRAFT — Fri, 18 Sep 2026 01:48:48 +0000

A conventional Pomodoro timer has a simple job: count down a work interval and announce a break. That is useful, but it leaves out the parts of a session that determine whether someone can stay with the work: sound, context, rhythm, and visibility.

Pomoria started as an experiment in treating focus as an environment instead of a counter.

The session is a small state machine

A flexible focus session can be represented as a sequence of steps. Each step has a duration, a type such as work or break, and optional context such as a note or intention.

That model supports more realistic routines:

a short planning step before a writing block;
two deep-work blocks separated by a recovery break;
a longer reading block followed by a short review;
a custom sequence for a recurring creative workflow.

The important design decision is that the sequence belongs to the user. A fixed 25/5 preset is a useful starting point, but it should not be the boundary of the product.

Why local audio is useful

Ambient audio can be created and mixed directly in the browser with Web Audio APIs. A focus environment can use oscillators, gain nodes, filters, and scheduled changes to build a sound layer without sending the session to a server.

There are practical benefits:

no audio file needs to be uploaded for the core experience;
the sound can respond to the current step;
users can adjust layers independently;
the session can remain usable offline after the page is available;
the design is easier to explain in privacy terms.

Local does not mean every browser feature works identically everywhere. Autoplay restrictions, device volume, headphones, and browser power-saving behaviour still matter. A good interface should make the first interaction explicit and keep controls understandable.

Mixing layers without making noise

More layers do not automatically make a better environment. Each source should have its own gain control, and the default levels should be conservative. White, pink, and brown noise can be treated as alternative beds rather than three sounds that must all play together.

Rain can add texture. A binaural tone can be optional. The user should be able to remove any layer immediately and still keep the timer running.

Keeping the session visible

Picture-in-Picture changes the relationship between the timer and the work surface. Instead of asking the user to keep returning to a full tab, the active session can remain visible in a small window while the user writes, codes, or reads elsewhere.

This is a small feature with an important product implication: visibility should support attention rather than interrupt it. The timer should be available when needed and quiet when it is not.

What “local-first” does not promise

Local processing is not a promise that the entire product is offline or that every browser stores every setting forever. It is a design direction: keep the core focus experience in the browser, make data movement explicit, and avoid requiring an account just to start a session.

Being precise about this builds more trust than using “private” as a vague marketing word.

The product lesson

The main lesson from building Pomoria is that a focus product should model the environment around the work. The countdown is one component. A useful session also needs a beginning, a middle, and an end; a rhythm that fits the task; sound that can be tuned; context that can be remembered; and a view that stays available.

Pomoria is an early implementation of that idea: a browser-based focus environment with custom sequences, local ambient sound, and Picture-in-Picture. It is freemium and can be started without installing anything or creating an account: https://pomoria.app/

Questions for other builders

Which browser audio constraints have affected your product design?
When does a persistent timer help rather than distract?
Which settings should belong to a session template instead of a user account?

Building a Browser-Based Voxel Editor with React Three Fiber

VOXEL_DRAFT — Tue, 28 Jul 2026 06:37:06 +0000

I have been building VoxelDraft, a voxel editor that runs entirely in the browser without an account or installation.

The editor supports block painting, layers, keyframe animation, GIF recording, local projects, and exports for OBJ/MTL, GLB, VOX, Minecraft Schematic, and Roblox RBXL. This post covers the architecture choices that kept those features manageable.

Keep edit data serializable

The editable model is an array of plain voxel records rather than a collection of Three.js objects:

type VoxelData = {
  position: [number, number, number]
  color: string
  layerId?: string
}

That decision makes JSON backups, local persistence, undo/redo snapshots, sharing, and format conversion much simpler. Three.js objects are derived render state, not the source of truth.

Render repeated cubes with InstancedMesh

Creating one mesh and one React component per cube becomes expensive as a model grows. VoxelDraft uses THREE.InstancedMesh where geometry and material can be shared.

Each voxel contributes a transform matrix. Pointer intersections return the instanced mesh and instance ID, which can be mapped back to the editable voxel record.

There are tradeoffs. Per-voxel colors need instance colors or grouping by material, and changing a single block still requires carefully updating the instance buffers. The reduction in draw calls is worth that complexity.

Make exporters independent from UI

The format exporters accept voxel records and produce a Blob. The UI is only responsible for validation and triggering a download.

const blob = exportToVOX(voxels)
const url = URL.createObjectURL(blob)

VOX, Minecraft Schematic, and RBXL are generated directly. For GLB, the app builds a temporary Three.js scene and sends it to GLTFExporter from three-stdlib.

Keeping binary generation separate from React event handlers makes exporters easier to test and reuse.

Move GIF encoding off the main thread

VoxelDraft records both animation output and modeling timelapses. GIF encoding can easily freeze the editor, so gif.js runs its encoder in a Web Worker.

With Vite, a tiny module resolves the worker asset:

import workerUrl from 'gif.js/dist/gif.worker.js?url'
export default workerUrl

The editor captures canvas frames, sends them to the encoder, and displays progress. Resolution, frame count, and FPS need sensible limits because all three affect memory use.

Start local-first, but provide backups

Projects are stored in localStorage so the first editing session requires no backend or signup. This is convenient, but browser data can be cleared and storage is limited. The UI therefore offers JSON export for durable backups.

IndexedDB is the natural next step if projects and thumbnails outgrow localStorage.

Pre-render the pages around the editor

An interactive editor is not a great search landing page by itself. The surrounding English, Japanese, Chinese, and Spanish pages are pre-rendered with Vike. They include canonical URLs, hreflang, Open Graph metadata, and JSON-LD.

The broader lesson is that a browser tool has two surfaces: the client-heavy workspace and the indexable pages that explain why someone should open it.

What I would keep if I started again

Plain serializable data as the source of truth.
Instanced rendering for repeated geometry.
Exporters isolated from the UI.
Workers for CPU-heavy media encoding.
A no-account path plus explicit backup tools.

You can try the current build at voxeldraft.com. I would especially appreciate feedback on the editor flow, animation tools, and export compatibility.

DEV Community: VOXEL_DRAFT