trainUs/website/content/blog/2026-06-14-lancement.en.md
David 352a3d5e88
Some checks are pending
CI / Lint & Format (push) Waiting to run
CI / Build (push) Waiting to run
CI / Tests (${{ matrix.browser }}) (chromium) (push) Waiting to run
CI / Tests (${{ matrix.browser }}) (firefox) (push) Waiting to run
Initial commit
2026-06-18 13:06:57 +02:00

60 lines
4.4 KiB
Markdown

---
title: 'Launching the TrainUs website'
date: 2026-06-14
description: 'Introducing TrainUs: a local-first, bilingual, installable fitness tracking PWA that runs entirely in the browser.'
---
> Cet article est disponible en français : [Lancement du site TrainUs]({{< relref "2026-06-14-lancement.fr.md" >}})
Today I'm publishing the documentation site for **TrainUs**, a fitness tracking app I've been building for the past few months.
## What is TrainUs?
TrainUs is a progressive web app (PWA) that runs **entirely in the browser**. There is no server, no account to create, no data sent anywhere. Everything is stored locally on your device using SQLite WASM and the OPFS API (Origin Private File System).
The app is **bilingual** (English and French) and **installable** on your phone or computer like a native app — with full offline support.
## Why this project?
Most fitness apps I've tried share the same limitations: they require an account, send your data to the cloud, and disappear if the subscription ends or the service shuts down. And when you want to share a workout or export your data to another tool, it's often impossible — or locked behind a proprietary format.
I wanted something simple, that works without an internet connection, collects nothing, and lets you share your data freely. So I built it.
> **AI wrote almost all the code.** I have the technical skills to carry out this kind of project, but not the time — and to be transparent: the vast majority of the source code was written by AI assistants, not by me. I directed the architecture, reviewed every change, guided the implementation, and made all the decisions. But if authorship means writing the actual lines, that credit belongs mostly to the AI. The rise of these tools changed the equation entirely: what would have taken me months of evenings and weekends became achievable, and I got to compare quite a few models and assistants throughout the process — which is a benefit in itself.
## What the app can do
TrainUs covers the full training cycle:
- **Exercises** — define each movement with a description, default reps, weight, side management (left/right), and image/video links.
- **Combos** — group exercises into circuits with a built-in timer (EMOM, AMRAP, TABATA, or classic superset).
- **Sessions** — compose workouts from exercises and combos, in any order you like.
- **Collections** — organize multiple sessions into a weekly program or training phase.
- **Execution mode** — follow a session in real time: timers, actual reps, weight used, left/right side, audio cues.
- **Statistics** — charts for frequency, volume, and progression per exercise.
- **Import / export** — share exercises and sessions between devices or with other users via JSON files.
- **Backup** — download the SQLite database directly; the app regularly reminds you to make a backup.
## Technical choices
| Aspect | Choice | Reason |
| -------- | -------------------------- | ---------------------------------------------------- |
| UI | Vue 3 (Composition API) | Lightweight, declarative reactivity, good ecosystem |
| Database | SQLite WASM + OPFS | Performant local persistence, no server needed |
| PWA | vite-plugin-pwa + Workbox | Full caching, native installation |
| i18n | i18next + i18next-vue | Instant language switch without page reload |
| Charts | Chart.js 4 + vue-chartjs 5 | Lightweight, well documented, simple Vue integration |
| Build | Vite 7 | Fast builds, good WASM asset handling |
The choice of **SQLite WASM with the `opfs-sahpool` VFS** deserves a special mention. It is the most performant configuration available in a browser: synchronous I/O via `FileSystemSyncAccessHandle`, without requiring COOP/COEP headers. The only trade-off is that SQLite must run inside a Web Worker (synchronous OPFS APIs are not available on the main thread) — which is good practice anyway to avoid blocking the UI.
## What's next?
The app is in **preview** — functional and fairly complete — but not yet publicly released. The next step is to deploy it and finalize the documentation.
The source code is available on GitHub under the GNU AGPL v3 license (link in the footer).
---
_This post opens the project blog. Future articles will cover technical decisions, upcoming features, and usage feedback._