Everybody's built a todo app. It's the canonical beginner project, right up there with a blog and a calculator. So why build another one? And more importantly, what does it take to build one that people actually use?
tsks.in started as a single HTML file with inline CSS and JavaScript. No framework, no build step, no dependencies. The first version was about 200 lines of code. It let you type a task, check it off, and delete it. Everything was stored in localStorage and disappeared if you cleared your browser data.
That first version was used by exactly one person (me). And it was fine. It did what it needed to do. But I wanted to access my tasks from my phone and my laptop without copy-pasting JSON around.
Firebase was the obvious choice for sync. Authentication, database, real-time listeners — all in one SDK, all with a generous free tier. The trick was keeping the code simple. No state management library, no Redux, no complex data flow. Just a local array that gets updated by the Firestore listener and re-rendered with a plain loop.
The hardest part was handling the time between adding a task and the snapshot listener firing back. If you're not careful, the task appears twice — once from your local state and once from the server. The solution was to let the server be the single source of truth and re-render only from the snapshot.
The hardest part of building tsks.in wasn't writing the code. It was resisting the urge to add features. Every user request for due dates, reminders, categories, tags, sharing — each one sounds reasonable on its own. But each one adds complexity, and complexity is death for a simple tool.
The design philosophy became: if a feature requires a UI element beyond a text input, a checkbox, and a button, it doesn't belong. This is restrictive, but it's also liberating. Every new feature has to prove it's essential, not just nice to have.
tsks.in will stay simple. That's the whole point. Future improvements are about making the existing experience better — faster sync, offline support, better accessibility. Not about adding more things to the screen.