This is the conclusion of a transition that started more than a year ago, stemming from my frustration with TypeScript and the state of front-end frameworks. Gleam and Lustre were and still are a breath of fresh air and I am glad to have made the move.

This post will detail how those early motivations measure up in hindsight, and what it means (and feels) to maintain tens of thousands of lines of Gleam code.

You could do it too

Nestful is what I call “almost done” software. It’s not quite the completeness that are SQLite or Sublime Text, but is also not as ever-changing as something like Windows, a bastion of agile development these days. This positioning makes Nestful able to survive such a rewrite.

Nestful is valuable to users as is, and so they are more tolerant of features not being a part of every browser refresh. Some are happy with the low amount of jarring changes. Not every app has this luxury, with some pushed by their market segment to chase competition. Thankfully Nestful is a very opinionated tool in a niche without much innovation, so could easily afford the rewrite.

However, a rewrite is not the only avenue. Since Gleam is not a pure language, it’s very easy to interact with existing JavaScript or TypeScript code. New code and much-needed refactors could be done in Gleam with little to no hassle. In fact, this is how Nestful started, with Vue SFCs written in Gleam, and later with Lustre taking over state management while Vue kept on rendering.

You could do the same in your company, implementing carefully and incrementally, and enjoy the benefits described in the blog post for those new sections of code.

Of joy and trouble

Clearly, Nestful does change. “Almost done” is very different from “done”, with improvements added in a calculated manner. As of writing, the next planned big feature is showing items from third party services. This requires a non-trivial amount of architecture to then be able to arbitrarily add tasks from other services and have them bubble up next to one another for the user to compare priorities.

To do that, the code base needed to support changes maintainability-wise, but also the enjoyment of writing them. The thing is — those are intertwined. Yes, there is an aspect of enjoyment that stems solely from the writing, in isolation. But there’s also the mental load that comes from bad maintainability which kills that joy of coding.

In my original post about rewriting in Gleam, I mentioned some of the language specifics that were a joy — simple, exhaustiveness checks, pattern matching, friendly syntax. Those all turned out to be true. A stark contrast to TypeScript’s complexity, where one has to write two programs; one serving logic and the other types. All I wanted was to make sure there aren’t any null references.

Difficulties on the front end most often boil down to managing state. jQuery closures, Angular services, React and Vue hooks and stores and of course, the resurgence of back-end-centric solutions like Phoenix — those are all attempts trying to make sure incrementing a counter won’t turn on the user’s toaster.

Elm and its architecture almost entirely solved state issues like the aforementioned by getting state soundness in exchange for boilerplate. You write more defining your state model, the actions that can be performed on it, and the side effects they may incur and in return you get significantly fewer bugs and, most importantly, developer clarity of how state flows. That is a fine exchange. Boilerplate is much easier to live with than being ever-vigilant about state racing like it’s Daytona.

Along the years I’ve advised companies on how to replicate this architecture with TypeScript, solving issues like the that “spooky actions at a distance”, unpredictable reactivity, and unruly side effects. I’ve done it with Nestful. However, there was always this feeling of trying to fit a square peg in a round hole. It’s well worth the benefits, but could I have done better?

That’s where Lustre — Gleam’s implementation of The Elm Architecture — shines as the true star of the show.

Explicit state handling and not having to fight off reactivity made Nestful much faster. The architecture also avoids over-design by allowing the developer to easily compose and recompose state and its handlers, Gleam and Lustre do make refactors easy and clean, because in the end, it’s all just regular functions with strong type guarantees.

This all concludes to a single word: fun. Programming Gleam is fun, and I do not intend on going back to the old, cold days of TypeScript if I can help it.

Lessons Learned

The following is a short summary of some lessons learned along the way, in no particular order (except for that first one). I hope that they can be useful to you.

The AI Elephant in the Room

I know I’ll get a lot of replies saying how Gleam is too new for AI and therefore productivity is reduced compared to something like React. Well, I’ve been using Opus 4.5 for some of the rewrite and I can tell you two things:

1. It is much better at Gleam even compared to Sonnet 4.5 and Codex 5.2

2. LLMs are very knowledgeable idiots

Given their stupidity as their main weakness and their vast knowledge as their main strength, LLMs need very precise guidance and supervision to crank out what I’d consider acceptable code. In that context, having more knowledge about a specific framework or language results in diminishing returns, especially with tools like Claude Code or OpenCode which give the LLM more information.

Instead, it’s much preferable to guide the LLM to avoid its stupidity. The constraints that are inherent to Gleam and Lustre do that perfectly. Yes, the LLM might try to concatenate a conditional CSS class instead of using attribute.classes, or rename variables weirdly because it has PTSD from JavaScript name collisions. That is much easier to deal with than having it RNG an architecture like we’re playing The Sims.

Forget view hierarchy

This is more of an Elm architecture generality but is useful even if you don’t adopt a framework that follows it. Due to components holding state, React and Vue make it extremely easy to model your state hierarchy identically to your view hierarchy.

This is often not only counterproductive but downright harmful. State should be modeled completely separately from the view. Drawing state encapsulation lines that match view encapsulation will just mean you’ll be ever-busy trying to circumvent your own architecture as you discover state cross-requirements.

Design late

JavaScript and to some extent TypeScript are both landmine languages and therefore incur significant refactor cost, as refactoring doesn’t only mean avoiding pitfalls in the new code, but also breakage that is caused by removing the old code.

This is almost entirely absent in Gleam, which has your back. This makes the drawbacks of designing early — making incorrect assumptions about the future — more harmful than the logic inconsistencies that still can sneak into Gleam code, especially since it’s not pure.

Instead, just build really well for what you have now. The code will tell you when you need to change the design, which will be a mostly painless process.

Accept the boilerplate

Lustre requires you to commit to more boilerplate. It is a fact of its design. Fighting it by being “smart” will come back to bite you down the line.

Consider your FFI boundaries carefully

FFI is by far the most bug-prone area of the code. This is understandable. Be careful when writing it and its glue code to Gleam.

I hope that tooling in the future could detect type inconsistencies between TypeScript types and the types declared in Gleam for the external function.

Have fun

I may be repeating myself — well, I am repeating myself — but remember to have fun. Slight adjustments to the things you do can go a long way in making you enjoy them. Even if you don’t like Gleam or Lustre (how?!) — incorporate what you do like, even if in a small way. I haven’t done my research but I’d bet people who enjoy the work do it more productively.

What more do you need?

I’ve found the most successful way to write these blog posts isn’t to sit down and hammer out words on a deadline. It’s to start an idea rolling on Monday, let it drift through the week like vapor, and then, by Sunday, it’s ready to land. This one began in a half-formed note just after I hit publish on the last piece. I returned to it on Thursday with a few new thoughts and shaped it into something fuller by the weekend. I’ve started applying this rhythm to other work too, not just writing, and it’s reminded me that so much of what we call productivity happens off the page, outside the task, in moments that don’t look like work at all.

I wrote in an earlier post about how due dates can kill momentum — that you don’t have to finish a task in one moment, you just have to engage with it a little. Sometimes that little snowballs and becomes a flow session. Sometimes it doesn’t, and the task slips back into the background. Either way, it’s still alive. That first touch-in is enough to start something stirring. I don’t think we give enough credit to that kind of invisible work—the work that simmers while you’re walking in the park, or lying in bed, or staring out the window without realizing you’ve slipped into the middle of it again.

The brain has its own way of revisiting things. On my daily walks, I often stumble across answers to problems I wasn’t consciously thinking about. Noticing how an idea I’d started earlier in the week has evolved slightly. Two previously unconnected thoughts now sit side by side, quietly linked. Same thing in the shower. In fact, long showers away from my phone feel like a shortcut back to my mind. I know none of this is groundbreaking — there’s a name for it, after all. Psychologist Graham Wallas called it incubation. He laid out a four-stage model of creativity almost a hundred years ago: preparation, incubation, illumination, verification. It still holds. I find comfort in the idea that letting go for a while is not just part of the process — it is the process.

But I do wonder how often I derail that process myself. I know when I’ve scrolled too much, checked for updates on too many apps, yanked my brain out of that gentle hum and into distraction. I’ve started thinking of my phone as the enemy of incubation. I wonder how many ideas I’ve buried with overstimulation, how many breakthroughs I’ve drowned out by refreshing tabs that didn’t need refreshing. There’s something fragile about that drifting state. It doesn’t shout. It slips in when your mind is a little bored, a little open, not being asked to perform.

The idea of letting things rest isn’t modern, of course. I first came across the Daoist concept of wu wei years ago and it stuck with me. Non-doing, or more precisely, effortless action. It felt at once obvious and profound. I ended up reading the Dao De Jing, and then reading it again, and again. One line in particular keeps circling back to me: “Muddied water clears when left alone.” There’s something deeply relieving about that. That we don’t have to fix or force everything. That stillness is not failure, but a strategy. There’s a kind of bravery in leaving something alone long enough to let it become clear.

It’s the same with therapy. I often find myself grumbling about the price of a session: an hour that feels short, especially when I compare it to my own hourly rate. But the more I think about it, the more I realize the session is just a spark. The real shifts happen in the days between. Something unspools in the background. What felt tangled or stuck starts to loosen, not during the appointment, but in the quiet that follows. It’s the same thing, again. The work we think we’re doing is only part of it. The real change often happens later, silently.

That said, not everything needs days to marinate. Some tasks genuinely benefit from being done in one go — emails, admin, booking the damn dentist. Even creatively, there are days when everything’s ready at once and the words come tumbling out in a single sitting. But when that happens, it’s usually because the thinking’s already been done. I just didn’t notice it. The bubbling happened in the background. The writing part was just the final stage, the part that looks like work.

The moments I find hardest are when I’m expected to come up with something on the spot. A slogan, a concept, a sentence that sums up a campaign. It never works. I always freeze. My brain isn’t built for spontaneity in that way. It’s why I get so frustrated when someone says, “Just write it now!” as though writing is transcription and not excavation. I’m not an improv comic. The good stuff comes when I’ve had time to not think about it.

What this means in practice is that at any given time, I’m spinning several plates in my mind. I picture them quite literally, each one something I’ve nudged into motion. Some are spinning fast and don’t need me yet. Others wobble and ask for attention. The trick isn’t to keep all of them moving constantly — it’s to know when to step in and when to let them be. That’s what I’ve found Nestful quietly supports. The nesting function lets me break down big things into manageable parts. It gives me a bird’s-eye view, so I can dip in, check on something, and leave again. It mirrors the rhythm of thought itself — touch in, retreat, return.

There’s a strange joy in coming back to something that’s been quietly cooking in your mind. When you open the doc and find the shape is already there, you don’t need to push, you just need to tinker. The effort has already happened. It’s like skimming the fat off the top of a broth that’s been simmering all day. All that’s left is refinement.

And all of this — this drifting, circling, returning — it doesn’t happen well if you’re exhausted. It hinges on good sleep. Not just quantity, but quality. Regular, unrushed, properly dark sleep. I’ve noticed a direct correlation between my creativity and the nights I sleep well. Not because I wake up with epiphanies, but because the baseline of my brain is calmer. It gives me more chances to slip into the space where good work can happen.

So when I say I’m working on something, I often mean I’ve nudged it forward, let it go, and trusted it’ll come back when it’s ready. Sometimes it surfaces while I’m walking. Sometimes while I’m showering. Sometimes not at all, but even that’s okay. There’s no real rush. The plate keeps spinning. The water clears on its own.

Try Nestful.

Subscribe now

Share

There’s a familiar urge to wait for the top of the hour. Or the half hour. To not begin at 2:17PM, but to wait for a neater time: an official start. It’s easy to tell ourselves it’s just about procrastination, but it’s deeper than that. It’s about wanting time to feel clean, structured, legitimate. We’ve been taught to treat productivity like meal prep: clear the counters, lay out your ingredients, block off a whole afternoon. But most of life isn’t Sunday. It’s midweek noise, a surprise call, a delayed start. A half-hour that turns into thirteen minutes and a question: is it worth starting now?

What if productivity didn’t rely on perfect containers? What if it moved with time’s actual texture, fragmented, shifting, often unresolved? What if the aim wasn’t to stay perfectly on track, but simply to keep hold of the thread — to return to what matters, without the sense that you’ve failed just because you didn’t follow a line?

How do you see time?

I’ve been thinking a lot about how I perceive the shape of time and how that might be wildly different from those around me. Of course, how we see time affects how we move through it. For me, sometimes time looks like an agenda — neat little blocks, like a projection of Google Calendar in your mind — it can feel rigid, maybe even oppressive. But it can also feel satisfying. Tasks slot in. Hours get filled. Things get done.

Other times, time isn’t structured at all. It’s just a digital clock with numbers slipping forward whether I move or not. It doesn’t wait. It doesn’t care. There are no blocks, no cadence — just the slow dissolve of minutes into nothing. You’ll notice my perceptions of time are based on technology. This wasn’t intentional, but it’s deep rooted from the way we learned everything we know about time — through ticking timers, progress bars, and the white space of empty calendar invites. These tools have shaped how we all relate to time: not just as a backdrop, but as something to manage, fill, and spend.

I once did a 10-day silent meditation retreat: no speaking, no phones, no clocks. A bell would ring at 4:30AM to wake everyone for the day’s first meditation, and it would ring again throughout the day to signal transitions. We moved with the bells, and the sun became the best indicator of time. And yet, even in that setting, I still found myself grasping at it. I remember sitting in meditation and wondering how long I’d been sitting, how long was left, when the next bell would come. Even in the stillness, I couldn’t let go of time, not really.

The retreat felt like a slice of unreality. But the moment I left, I slipped right back into timekeeping. Almost instinctively, I returned to counting hours, checking clocks, measuring my day in terms of output and intention. I often catch myself thinking: I have a box of time here — one hour. Should I apply it to a task? Or should I lie in bed, listening to the radio? Both, in their own way, feel productive. That framing — the box, the trade-off — is deeply ingrained.

There are moments when time disappears altogether. There’s no clock, no list, no “next.” Just now. I’m here, and that’s all there is. With practice, these moments come more often. When they do, I notice. I’m like a kid balancing on a bike for the first time, my brain goes “Look! I’m doing it!” Urgency evaporates, objects become sharpened and everything gets a lot more vivid. It’s not a psychedelic trip, but it feels adjacent. It’s just presence. And then, of course, I fall back into the grid. The spreadsheet of hours. The pressure of minutes. Because, like everyone else, I’ve bought into the collective contract of time. We agree to measure it so we can move through the world together. It’s how we meet deadlines. Catch trains. Sync calendars. Time, distorted as it may be, still functions.

It also forms the backbone of how we approach productivity. But if time feels different for each of us, doesn’t that complicate things? Maybe the problem isn’t how we manage time, but how we experience it. Or more importantly — how our tools assume we experience it.

Time isn’t one thing

Once I started paying attention, I learned about just how differently people seem to experience time. Some really do see the blocks, time as a grid to fill. Others feel it as a current: sometimes rushing, sometimes pooling. Some experience it cyclically, looping back through familiar rhythms. Others feel it always running out. And some live mostly in the eternal now.

Each of these perceptions creates a different relationship to pressure, prioritisation, and momentum. And yet, most productivity systems are built around a single assumption: that time is fixed, linear, and schedule-shaped. That assumption alone can leave people feeling behind, overwhelmed, or strangely out of sync — not because they’re disorganized, but because the tool they’re using doesn’t match the way they relate to time.

The tools that shape our time

It’s not just that most systems assume time is linear — it’s that they quietly teach us to operate as if that’s the only valid shape it can take. Planning tools, digital calendars, and habit trackers rarely accommodate how elastic time can feel. Instead, they ask us to pin things down in advance: block out hours, assign slots, colour-code priorities. They promise structure — and sometimes they deliver it — but only if you already think in blocks and respond well to grids.

For those whose experience of time is more fluid or inconsistent, this can create a strange kind of friction. You’re not just managing your tasks, you’re performing a version of yourself who fits into the structure the tool expects. It becomes easy to mistake falling out of sync with the system as a personal failure, rather than a sign the system might be too rigid.

That rigidity isn’t always overt. It’s in the quiet expectation that focus can be scheduled. That motivation will arrive on time. That life won’t interrupt. When those things don’t hold true — and often they don’t — it can leave you feeling like the problem is you, not the framework you’ve been handed.

A different kind of rhythm

By now it’s clear: time doesn’t always behave. It stretches, shrinks, gets interrupted. Our energy ebbs and flows. Plans rarely hold. And yet, many systems still expect us to treat time like a fixed asset, divisible, predictable, tightly bound.

Over time, I’ve come to value systems that don’t expect me to be consistent in form, only in attention. Systems that let the shape of my focus change from one day to the next, that don’t require me to guess in advance when energy will arrive or how long it will last. Ones that hold space for ambiguity, without collapsing under it. I’ve noticed that what makes a system feel good isn’t how much it lets me get done, but how well it adapts when things inevitably shift.

That’s the quiet logic behind Spontaneous Productivity — not to eliminate structure, but to stop trying to impose the wrong kind. Instead of treating time as a container to be filled, it invites you to see it as something you’re in a relationship with — responsive, alive, unpredictable, and often surprising. It asks: what if your productivity system didn’t try to fix time, but moved with it?

This is what Nestful is designed to support — not because it has every feature under the sun, but because it doesn’t ask you to perform a version of yourself that never misses a beat. It lets you log what matters, then step away. And when you return, it quietly surfaces the things that are still to do. Some days you might work in sharp, focused bursts. Other days, you might drift, returning to tasks in fragments. Nestful doesn’t reprimand either. It simply keeps hold of the thread until you’re ready to pick it back up.

Maybe the real work isn’t to master time, but to recognize its many shapes — and find ways to move within them that feel less like resistance, more like rhythm. Not every hour needs to be optimized. Not every task needs a slot. Sometimes, just knowing the thread is still there is enough.

Try Nestful.

Subscribe now

Share

If you’ve ever spent more time moving things around in your planner than actually doing them, you know what I mean. Rigid scheduling assumes a level of control over life that simply doesn’t exist. Meetings get moved, energy fluctuates, and priorities shift. The more precisely you plan, the more you have to fight reality to make those plans work.

But here’s the thing: I never stopped working out. I just stopped trying to schedule it.

Energy matters more than the clock

Instead of saying, "I will go to the gym at 6:30 AM every day," I switched to a simpler rule: "I will go to the gym on Monday, Wednesday and Saturday.” No fixed time, no strict routine. I decided I could commit to consistency but not precision. Some days I go at 6:30 AM, some days at 10:30 AM. The time varies based on how I feel, what my workload looks like, or whether the class I want to take is full. But because the habit itself is solid, it happens regardless of when I do it.

This shift in mindset — prioritizing consistency over scheduling — was a game-changer. It turns out, you don’t need rigid routines; you need reliable habits. The real trick isn’t forcing yourself to do something at an exact time, it’s making sure you do it at all.

That’s where the real power lies: not in perfect timing, but in dependable rhythm. It’s a quieter kind of discipline — one that doesn’t crack when life throws you a curveball. Some mornings I still wake up groggy. Sometimes meetings spill over, or I just want to read in bed. But none of that derails the habit. I know the workout will happen — not because it's locked in at 6:30 AM, but because it's part of the rhythm now.

I used to think freedom meant being flaky. That if I wasn’t militant about scheduling, everything would fall apart. But what I’ve found — and maybe you’ve felt it too — is that freedom paired with clarity is a far more sustainable motivator than control paired with guilt. That’s what makes systems like Seinfeld’s “Don’t Break the Chain” so sticky — not because they’re strict, but because they reward consistency without boxing you in. When the stakes are “do it today” instead of “do it by 9:00 sharp,” you’re more likely to follow through and feel good about it.

This is where Spontaneous Productivity stopped being an idea and started becoming something I could actually live by. I didn’t need a perfect routine — I needed help knowing what to focus on next, without overthinking it. That’s what Nestful gave me. It didn’t shame me for being “off schedule.” It just surfaced what mattered — that HIIT class, that blog draft, that overdue call — and let me decide when to tackle it. No calendar Tetris. No mental drag.

Here’s what I’ve got recurring in Nestful right now:

• Monday / Wednesday / Saturday: “Move your body” (I choose the format)

• Daily: “Write something, even a sentence” (keeps me creatively in motion)

• Weekly: “Inbox zero-ish” (emphasis on the -ish)

These aren’t rigid time slots. They’re rhythms. I don’t always hit them perfectly, but I rarely miss them entirely — and that’s what counts.

The rhythm itself is flexible. What starts as “Monday, Wednesday, Saturday” might shift to Tuesday or Sunday one week — and that’s fine. The point isn’t to hit every beat exactly, but to keep the beat going. Say I usually work out every other day. If Friday gets wiped out by a last-minute wedding or bad sleep, I don’t panic and “catch up” — I just don’t tick the task. The next time I check it off, the rhythm continues from there. It doesn’t punish me. It flows. That’s the beauty of it: the interval stays intact, even when the exact days shift.

You don’t fall off the wagon; you just pick it back up at the next step. That’s what makes this approach so forgiving — and so effective. It meets you where you are, and it keeps going when you’re ready again.

I think we’ve been sold this myth that real discipline has to look militant — same time, same sequence, every day. But in reality, the people who get the most done aren’t always the ones with the tightest schedules. They’re the ones with systems that move with them — who focus less on planning the day and more on showing up for what matters.

That’s what Nestful helps me do: not just stay on track, but redefine what the track even looks like. It lets me show up — imperfectly, but consistently — and that’s enough.

Try Nestful.

Subscribe now

The first is a deep dive into how Nestful pulls off offline-first syncing using CRDTs, Yjs, and object storage, without relying on a traditional backend. It’s a practical look at keeping data consistent across devices while staying lightweight and low-maintenance.

The second is a reflection on what happens when productivity stops feeling like a chore. By approaching tasks with curiosity and playfulness instead of pressure, it becomes easier to get into flow and actually enjoy the work.

For anyone building tools or habits that reduce friction and invite momentum, both posts might resonate.

How Nestful uses CRDTs to sync your data with (almost) no backend

Nestful has quite the interesting use case – it is an offline first app, yet it supports cross-device sync. This means it should somehow consolidate data even if it’s the result of multiple different offline sessions coming back online at different times.

Most of you are already aware that the most common way to do this today is Conflict-free Replicated Data Types (CRDTs). As their name suggests, they are replicated data structures that can be combined, with algorithms guaranteeing that the data will eventually converge.

Nestful uses Yjs, a fast JavaScript CRDT. Yjs is truly a magnificent piece of software. Each user has its own Yjs Document where most data is stored. For local persistence that data is synced into IndexedDB, the in-browser database, using y-indexeddb, which is part of Yjs’ provider ecosystem.

Continue reading

How to reframe productivity as play, not work

Last week I turned avoiding my quarterly content calendar into an Olympic sport. The task sat there in my to-do app, glaring at me. Instead of starting, I spent 30 minutes reorganizing my task list. Classic avoidance behavior.

It wasn't until I reframed the problem –"let's experiment with content themes that might resonate" – that I finally dove in. Three hours disappeared in a flash. The difference? I'd accidentally turned work into play.

Why productivity feels like a chore

You know the feeling when you open your task manager and a long list (of things you don’t want to do) stares back at you. Where do I start? What's most important? Why does this feel overwhelming before I even begin?

Continue reading

Try Nestful

It wasn't until I reframed the problem –"let's experiment with content themes that might resonate" – that I finally dove in. Three hours disappeared in a flash. The difference? I'd accidentally turned work into play.

Why productivity feels like a chore

You know the feeling when you open your task manager and a long list (of things you don’t want to do) stares back at you. Where do I start? What's most important? Why does this feel overwhelming before I even begin?

The trouble is that most to-do lists don't help you focus. They present everything at once, leaving your brain stuck in decision mode rather than execution mode. Organizing tasks can feel productive, but too often, it’s a trap. I’ve lost entire mornings tweaking timeblocks, only for my boss to call with an urgent request that upends everything.

After cycling through probably a dozen productivity systems over the years, I've realized something: the best work happens when I’m engaged, curious, and free to follow momentum. Productivity isn't a chore when it feels like play.

How to reframe work as play

Play isn’t the opposite of work; it’s how we solve problems most effectively. Mark Twain captured this idea in Tom Sawyer, tricking his friends into whitewashing a fence by making it seem fun. The work stayed the same; the framing shifted.

Research backs this up. Mihály Csíkszentmihályi’s work on flow states shows that when tasks provide the right balance of challenge and skill, people enter a deeply focused, high-performance state. Studies by Teresa Amabile and Edward Deci have found that intrinsic motivation — genuine interest rather than external rewards — leads to better creativity and productivity. That’s why Google’s 20% time (which led to Gmail) and IDEO’s play-jams work: they invite curiosity and experimentation, making work feel effortless.

The shift happens when you stop seeing tasks as obligations and start seeing them as interesting problems to solve. So here’s my attempt:

• Writing becomes exploration rather than obligation when I approach it with curiosity.

• Content planning turns into strategic storytelling rather than filling slots on a calendar.

• Analytics reviews can be either tedious number-crunching or fascinating detective work.

The trick isn't forcing yourself to work harder — it's shifting how you experience the work. When I catch myself dreading a task, I ask: "How can I make this interesting?"

I get it — sometimes work feels like an endless slog, especially if you’re stuck in a role that seems inherently unexciting. Maybe you’re processing invoices, entering data, or sitting through mind-numbing meetings. My examples — writing, content planning, analytics — might sound creative or dynamic compared to that. But here’s the thing: the magic of reframing isn’t about the task itself, it’s about how you approach it. Even the most “tedious” work can become a playground if you tweak your lens.

Practical ways to reframe work as play

Here's what actually works for me when turning tedious tasks into engaging activities:

1. Make a mess first.
   Play is messy. When I'm stuck in perfectionism, I'll deliberately create an "ugly first draft" where the goal is speed, not quality. It's liberating to intentionally write something bad, knowing you'll improve it later. The fear of imperfection kills play. Give yourself permission to make a mess first.

2. Create challenges, not chores.
   I used to dread the monthly analytics reviews until I reframed them as detective work: "Can I discover one surprising insight nobody else has noticed?" Suddenly I was hunting for clues instead of trudging through data. Ask yourself: "What's the puzzle here that I'm trying to solve?" Almost any task can be reframed as an interesting challenge.

3. Lower the stakes with experiments.
   When I frame tasks as experiments rather than obligations, my fear of failure disappears. A recent email campaign flopped, but because I'd defined it as "an experiment in storytelling formats," I analyzed the results with curiosity instead of disappointment. Try asking: "What if this were just a prototype I'm testing?" The mental shift is immediate.

4. Build feedback loops.
   Games are addictive because they provide instant feedback. I've started breaking content projects into 25-minute chunks with clear "win conditions." Instead of "work on blog post," I'll set a goal like "write three compelling hooks and pick the best one." After each sprint, I get that small dopamine hit of accomplishment. Even better: share early drafts with colleagues and get quick reactions. Their feedback creates natural momentum.

How play fits into my productivity system

If there's one thing I’ve learned, it’s that forcing productivity rarely works. The best work happens when we tap into curiosity, momentum, and engagement — when work feels like play. But most productivity tools aren’t designed with that in mind. They assume we thrive on strict schedules and rigid planning when, in reality, that approach often leads to burnout, avoidance, and endless reshuffling.

What if, instead of wrestling with productivity systems, we used tools that worked the way our brains naturally do — surfacing what’s important at the right moment without constant effort? That’s the idea behind spontaneous productivity — a workflow that prioritizes action over overthinking.

That’s the kind of system I’ve gravitated toward. I need something that helps me keep up momentum without getting stuck in decision loops or spending half my time reorganizing a to-do list. Lately, I’ve been using Nestful because it fits that mindset: it doesn’t force rigid plans but makes sure the right things rise to the surface when I need them. Less managing, more doing. And for me, that makes all the difference.

Try Nestful.

Subscribe now

Most of you are already aware that the most common way to do this today is Conflict-free Replicated Data Types (CRDTs). As their name suggests, they are replicated data structures that can be combined, with algorithms guaranteeing that the data will eventually converge.

Nestful uses Yjs, a fast JavaScript CRDT. Yjs is truly a magnificent piece of software. Each user has its own Yjs Document where most data is stored. For local persistence that data is synced into IndexedDB, the in-browser database, using y-indexeddb, which is part of Yjs’ provider ecosystem.

Providers are pluggable pieces of code that hook into a Yjs document for added functionality. This is mostly in the form of sync to and from various places, from our local IndexedDB database to a middle ground in the form of y-websocket, to a full-blown solution like y-sweet.

Although I would have been glad to find a ready-made provider and integrate that into Nestful, things were not so easy. Commercial providers like y-sweet were in their infancy, so I didn’t even bother evaluating them. The most battle-tested solution was y-websocket, but that was just the communication layer. I would have had to write a non-negligible amount of backend code, which development (and maintenance) bandwidth did not allow for.

What do we do, then? To understand our options we need to figure out where Nestful was at the time, and what it is that we need to sync.

Nestful’s legacy

Historically Nestful was written as a generic, simple CRUD app using PostgreSQL via Supabase. I thought to myself – it’s a personal-use todo app, why would I need anything else? I’d say that for most todo apps that decision would have been correct (and it surely was correct at the time, for other reasons). The thing is, Nestful has two very important traits that change most of everything:

1. Nestful is offline-first, which now requires constructing a sync mechanism

2. Nestful uses a tree-structure which the traversal of can cause significant recursion

Don’t let anyone tell you otherwise – both are perfectly solvable and maintainable using PostgreSQL, even if they lend themselves better to something like a document-based CRDT.

Nestful’s other circumstances, including the way it was coded and my annoyance with my then local DB (a story for another time about how not to maintain FOSS) pushed me to switch.

So now we know that Nestful is hosted on Supabase, relying on its Auth and its Database, and most important of all – Nestful does not deploy any backend. This means that adding one will not only incur the complexity of the functionality we want to add, but of the expanded codebase, its deployment, and the server maintenance.

Doing that is all well and good, we are a software company after all, but let’s do better.

Update here, update there

That way sync works with Yjs (and most other CRDTs) is by using an update mechanism. Yjs allows the developer to obtain binary updates, representing a data diff, then send those over the wire. There are 3 main ways to do that:

1. Listen to changes

2. Diff against another version of the data

3. Get everything

Those updates can then be consumed in any order and they will converge to the same final state. Now that we know we want to sync updates, the questions are where do we save them and how will they get there.

Remember Nestful using Supabase? Well, Supabase has an S3 equivalent called Supabase Storage. The other side of the coin of provider lock-in is of course, blissful integration. After a minimal setting of permissions, end users would be able to push updates to Storage, and fetch updates that are already there.

Of course, just fetching all the updates all the time can be wasteful (and slow), so we’ll have to do some tweaking.

Almost converged

To not have the client download a humongous amount of files, which is as slow over these “serverless” platforms almost as how stupid the term “serverless” is, we could write a small “serverless” function to consolidate the updates for us.

That function will receive a date from the client, and will send over a single file.

When a client wants to get the latest data, he sends a date to the just-a-function-not-a-server. Upon receiving the combined update, the client diffs its own state against it, and uploads a diff directly to the just-object-storage-not-a-server.

This is called a full sync. At this point, the client and server are fully in sync. Any further update on the client is:

1. Uploaded directly to object storage

2. Broadcasted to peers using Supabase, to avoid a roundtrip

Using this scheme also has the added benefit of being able to restore data to a point in time, even if it was garbage collected by Yjs.

And that’s how Nestful syncs your data. This simple, client-dependent approach serves us well. It works, is stable, low maintenance, but… it’s slow. Nestful does not in fact require fast sync. It is not a real-time collaborative platform like other products using Yjs, and so sync can happen in the background, take a few seconds, and no one would notice.

But… we can’t settle for that, can we?

The future ahead

Even though it is fine for now (and for a long time from now) that a full sync is slow, we may need a bit more performance in the future. Although this may require getting an actual server and setting up an actual backend, the current design will stay mostly the same.

Since end-to-end encryption is planned for Nestful, the server will not be able to consolidate updates. Instead, a client will have to do that periodically and upload an encrypted checkpoint, which will serve as the new starting point for the next consolidation.

For this we’re going to need to cache both the metadata and data since the latest checkpoint for the update files in object storage to be able to quickly and efficiently serve whatever is needed, but that is for the future.

Check out the marvel of CRDT syncing by trying Nestful now, and also try Nestful itself while you’re at it.

Frequent readers will remember Nestful is written using Gleam and will probably wonder how we call Yjs from inside our lovely Gleam code. Here’s a YGleam link for you.

You may also be interested in our latest story about moving to an Elm-like state management.

Subscribe now

As much as you might have heard otherwise, the answer is an astounding yes. Those who fight on the hills pretending it’s all about the code are missing one very crucial point:

Frameworks shape the code you write.

To a certain extent, they define what’s possible, but more important than that – they set a path of least resistance. Yes, frameworks coming and going is one of the most frequent occurrences in nature, but that doesn’t mean it’s wasted effort to choose the right one or invest in it. The waste only appears when the frameworks are of the same kind, and introduce similar tradeoffs.

The clearest example of this is Elm. It’s not a coincidence that Elm manages state differently than how you’d normally do it in JS-land. Even Redux, which is an implementation of The Elm Architecture (also known as Model-View-Update), could not give the same streamlined experiences developers expect from Elm. Even if that experience is better than what’s otherwise available in the JavaScript ecosystem, you have to be fairly disciplined to keep it going.

Alas, there is only so much time in this world for us to try and fit a square into a peg. At this point some would fall back to the usual default: “Elm is great, but it’s too far from JavaScript. And there’s really nothing very different about all the JavaScript options, so I’ll just – ”

But wait. What if I told you there is another option? As robust as Elm, with a familiar syntax, and that you could learn in a day?

Grab yourself some tea, for this is the story of how adopting the Gleam language out of pure disdain for TypeScript led to much better state management for Nestful.

Before we delve into the details, let me bring you up to speed.

About a year since I started experimenting with Gleam, a delightful functional language that compiles to both Javascript and Erlang. I’ve decided to rewrite Nestful in Gleam to alleviate some of the terrible slog that is TypeScript.

The first major part was the introduction of Vleam, a set of tools that allows one to write Gleam inside Vue SFCs. Nestful is written with Vue and incremental adoption is a must when working on such a large-scale rewrite.

In November I launched OmniMessage, an experimental library for client-server communication. OmniMessage, you see, is an extension of Lustre (please bear with the buzzwords), Gleam’s Elm-inspired frontend framework. It allows one to define messages that are common to both the client and the server, thus streamlining communication.

Whether that’s a good idea or not, time will tell. What I do know is that Lustre was a breath of fresh air. But why? What is it about Lustre that’s missing from Redux (except for my strong, deep, unwavering dislike of React, that is)?

The answer is Gleam. Writing MVU-style apps in JavaScript is a bit like driving in a zigzag pattern — possible, but unless you’re 100% diligent, a crash is coming.

Luckily, I try to avoid premature optimization as much as possible and state management was no different. Nestful’s was simply done, by hooking up different kinds of Vue composables and utilizing Yjs’ event system. Some people may gasp at the lack of structure, but hindsight has revealed this to be a good decision. Much better than committing to what some would consider “proper” state management, spreading its tentacles into every corner of Nestful, making change a labor of desperation.

Instead, having a simple, unstructured system allowed it to be promptly removed when the learnings were sufficient and time had come to replace it.

After adopting Gleam for the language it is, Nestful could continue to enjoy its ecosystem, including Elm-inspired Lustre.

Why you should have some TEA

The Elm Architecture (TEA), also known as Model-View-Update (MVU), is a centralized form of state management made popular by —you guessed it —The Elm programming language.

As its alternative name suggests, it involves a centralized model that is sent for rendering to a view function, and is updated by an update function. If it sounds simple, that’s because it is. Here’s the state management diagram straight out of Elm’s docs:

Here’s the counter example from Lustre, Gleam’s frontend framework, which also implements TEA:

type Msg {

  Incr  

  Decr

}



fn update(model, msg) {

  case msg {

    Incr -> model + 1

    Decr -> model - 1

  }

}



fn view(model) {

  let count = int.to_string(model)

  div([], [

    button([on_click(Incr)], [text(" + ")]),

    p([], [text(count)]),

    button([on_click(Decr)], [text(" - ")])

  ])

}

That’s it, kids. For most web applications, you can pack Pinia and Zustand up, thank them for their service, and promptly show them out to the nearest commit.

You see, those popular solutions are popular for good reason. They are a low common denominator that, with all honesty, works quite well. The problem is they’re not as good as it gets. They break at the edges, if you will. A local maxima.

For Nestful, The Elm Architecture has the edge on them in three crucial places.

Preventing state-creep

State creep is the bane of my existence. When components are stateful, one of two things must happen:

1. You must hold constant, unwavering diligence, keeping local state local and global state global.

2. You despair as global and local states are inevitably mixed into a soup of misery.

I personally am not a fan of either constantly looking over my shoulder for the state boogeyman, nor of holding the mental model the size of the Tokyo rail system of how state flows through an application.

Instead, using TEA, I have a lovely, detailed map of all the paths data flows in. That map is an entire overview of the application, caging in the global state, only to be seen — never mutated.

A pure heart

Another great advantage of strictly enforcing TEA is that it makes it very easy to structure an application using “Functional Core, Imperative Shell”, a design pattern in which I/O is separated out to distinct parts at the start and end of a flow, while the center, the business logic processing that I/O, is kept pure. It always returns the same output for a given input, and does not involve side effects.

As it so happens, that is exactly how TEA pushes you to architect your state. Both the update and view functions are pure, and will return the same output for a given model and message.

Side effects are then handled by an effect system, which takes side-effect tasks returned by the update function and executes them out of the update function’s context.

This approach isolates the important bit of the application, the business logic, from the ever-changing, hardly testable, outside world.

Works great with Gleam

Gleam lends itself to this model quite significantly. Being a functional, type-safe language is a great usability gain for TEA, especially thanks to discriminate unions, who allow us to write the apps message type like this:

type Msg {

  Incr

  Decr

}

And the case statement, that allows for exhaustive matching on that message type:

fn update(model, msg) {

  case msg {

    Incr -> model + 1

    Decr -> model - 1

  }

}

Other implementations, like Redux, Dartea, or Vuex to some extent, while admirable, all fall short. After a developer has chosen a paradigm, tools need to not only enforce it, but encourage that paradigm. They need to not only make it the path of least resistance, but make the other paths hard in comparison.

A tool that requires diligence to keep going is failing at its job.

An added bonus from those three advantages is they make it extremely easy to refactor. They allow razing fields of old code to the ground, building skyscrapers above them, exchanging the fear of imminent crumble for the guarantees of type-safety and robust defaults.

But wait, isn’t Nestful a Vue app? How am I going to fit Gleam-written TEA into it? Am I going to have to settle for a TEA-like experience, similar to what I could conjure up using existing TypeScript solutions?

Incrementally adopting a frontend framework

So I’ve adopted Gleam and can now write it inside Vue files instead of TypeScript and look to use it to implement TEA and replace the current haphazardly-managed state.

To do that, two main tasks need to be completed:

1. Construct a runtime capable of executing the TEA state machine.

2. Somehow integrate that runtime into existing Gleam and TypeScript Vue components.

The first one already exists, it’s just Lustre (but without a view).

There are two ways of going about incorporating Lustre incrementally. The first is to carve out portions of Nestful and write those exclusively in Lustre. The second is to launch a Lustre app and render nothing, using just its state management capabilities.

Since the goal here is to have comprehensive state management, the second solution is more appealing, but a closer look will reveal that it’s actually the only solution possible.

Nestful, you see, is a giant item graph that’s traversed for specific views or actions. To enable offline-only capabilities, the entirety of the graph is stored on the client in the form of a single Yjs document, and if enabled, is synced on changes.

This means that not only is there very little local state to manage, the global nature of Nestful’s state will greatly benefit from collecting the static logic into a single, coherent, state machine. For Nestful, it makes much more sense to embed Vue in Lustre rather than Lustre in Vue.

// /src/compositions/useNestful.ts

import { computed, shallowRef, watch } from 'vue';

import { UseNestful } from '../nestful/compositions.gleam';

import { nestful } from '../nestful.gleam';



const modelRef = shallowRef();

const modelComputed = computed(() => modelRef.value);



const [initialModel, dispatch] = nestful((model) => {

  modelRef.value = model;

});



modelRef.value = initialModel;



export function useNestful() {

  return new UseNestful(modelComputed, dispatch);

}





// /src/nestful/compositions.gleampub type UseNestful {

  UseNestful(model: vue.Computed(Model), dispatch: fn(Msg) -> Nil)

}



@external(javascript, "/src/compositions/useNestful", "useNestful")

pub fn use_nestful() -> UseNestful

This is the glue code that allows Vue components, written either in Gleam or TypeScript, to read the model and dispatch messages. It is supported by helper functions in nestful.gleam to avoid having to import the different Gleam types into TypeScript.

Vue components are then treated as functions composing a Lustre app’s view function.

But there’s a catch.

The Elm Architecture’s centrally managed state trades off component composability to the point where Elm’s docs outright discourage them. While I don’t consider this blasphemy like some React folks may, I can see how different parts of an app lose on not being completely separate.

All things considered, it’s not an endemic issue similar to those I am trying to solve with the move to Gleam. That same page on the Elm docs discouraging components lists much more important things right before that that are benefits of TEA.

Which brings us to today.

A fun future

Except for two pending files, no global state is managed outside Lustre. State holding composables have been reduced significantly, and I hope to remove them completely in the following months.

The adoption of TEA has made Nestful faster, more maintainable and easier to develop features for. Most importantly, however, those advantages are now the path of least resistance in Nestful’s development cycle.

I hope that this transition will continue to bear fruit as time passes. By reducing the need for testing, by encouraging better design and architecture, and most importantly — by being fun.

This post was mostly about the technical benefits of Gleam and Lustre, but there’s also an emotional one — programming in them is a much, much, much more enjoyable experience than the TS alternative.

As we put our best foot forward in an attempt to increase value for our customers we sometimes forget about ourselves, and if we can — we can and should enjoy the process. Programming can and should be fun.

Subscribe and stay tuned for more unique takes on personal productivity and novel(-ish) web technologies.

Then reality sets in. In Obsidian, I conveniently forget that the system requires upkeep. I start adding notes haphazardly, leaving them unsorted, telling myself I’ll file them later. Fast-forward six months: I still haven’t filed them. Some – embarrassingly – don’t even have titles. The most success I’ve had with maintaining order is setting a recurring calendar reminder at the end of each month to clean up my mess. But even then, I find myself thinking: why don’t I just organize as I go?

Johnny Decimal works better in my Gmail, sort of. I have folders like “1 Work,” “2 Health,” and “3 Finance,” each with their own neatly nested subfolders. The problem folder is “0 Current,” my dumping ground. Everything lands in my inbox first. If I don’t want to deal with it immediately, I shove it in there. Spoiler: I don’t. “Current” is where tasks go to die.

Another issue: I can’t remember the decimal numbers. I don’t use the files often enough to internalize the structure. Sure, I recall that I have a “Current” folder with a “What’s on” subfolder, but I can never remember the numbers associated with them. And ultimately, I default to search anyway. I don’t navigate through “Car > Insurance” to find my policy details, I type “car insurance” into the search bar.

This realization makes me wonder: am I organizing out of necessity, or because I’m hooked on the ritual? I like the Johnny Decimal system and the big-picture view it gives me. One organizing spree, and I’ve got finances, travel, random notes on lock. I haven’t mentioned work. Forget that. Coding a feature or juggling sprint tasks doesn’t bend to decimals, so it gets siloed off into a whole other system.

Some folks let their MacBook files rot and lean on Spotlight — because chaos apparently works for them. On a Hacker News thread discussing the flaws of the Johnny Decimal system, one comment stood out:

“As an ADHD person, I’ve found the best way for me is not to put effort into organizing at all… My brain works better searching than browsing.”

This is what gets me — maybe organization isn’t meant to be organized.

But the real issue? Organizing is a form of avoidance. Not just avoidance of work, but avoidance of life itself. If I can just create the perfect list of movies to watch or the best places to buy furniture, then I’ll start living. Or then I’ll be safe because there will be just a little less chaos. Meanwhile, actual work (and living) sits there, not done.

Another Hacker News comment hit even harder:

“The more I tried to control and organize my life, the more stressed I became. Digitizing and organizing my knowledge base, in particular, wasted countless hours. Recently, I decided to let go of that rigid structure and instead focus on naturally prioritizing the most important tasks for the day, week, and month. So far, this approach has been working well, or at least it feels like it is.”

I went on a year-long journey organizing everything that might be useful someday. The only thing that’s actually been useful? Knowing where a scanned copy of my passport is. The next part of the Hacker News comment terrifies me because how could I possibly get things done without the illusion of organization? This is gonna take a fundamental mindset shift for me and anyone else who clings onto organization for dear life. Letting go of control feels insane, but what if that’s the point? What if the “messy desktop, just do it” crowd isn’t failing, but thriving?

The best productivity system could really be the one you don’t have to think about. Johnny Decimal’s solid if you babysit it, but the second you blink, it’s toast. I’m not a robot, and neither are you. My alternative system? Just go spontaneous and do what needs to be done. Keep what’s critical front and center. Nestful’s my wingman here: a to-do list that doesn’t care if my Obsidian is a mess or my inbox is full. Everything else can wait, because — shocker — it usually doesn’t matter. Productivity is not about control; it’s about action. Stop overthinking the how and just start. Trust me, you’ll survive the mess.

Try Nestful.

Subscribe now

Share

Falling into the trap of easy wins

Devs, project managers, anyone with a pulse, we all know the drill: split a task into subtasks, pin a due date, call it done. So why do we still choke? Because we treat due dates like finish lines and subtasks like a buffet. A deadline two weeks out feels like a cushion, so we coast. Subtasks stack up, and we gravitate to the low-hanging fruit – tweaking a UI, writing a quick test – while the meaty stuff (say, wrestling with an API) festers. It’s not laziness; it’s human nature misreading the signals. Parkinson’s Law is more than just time bloating, it’s about us shrinking from the real work until the last second.

Take a developer with a feature due in two weeks. They know it needs backend logic, frontend integration, and testing. They might mentally map it out, but with the due date far off, they start with the fun part and by the time they dig into the hard stuff, blockers pop up, scope creeps, and they’re crunching late, cursing themselves. Sound familiar?

Combatting avoidance with to-do dates

Here’s the shift that changed everything: stop tracking when it’s due and start tracking when to work. Due dates create pressure; to-do dates create progress. You’re not just breaking tasks down, you’re assigning them moments that make you face the tough stuff head-on, not just the easy wins.

Imagine that same feature, due March 24. Instead of one looming deadline, you set:

• “Outline requirements and API specs” for March 8.

• “Build backend logic” for March 13.

• “Hook up the frontend” for March 16.

• “Test and debug” for March 21.

Now, you’re engaging early. The backend doesn’t get kicked down the road; it’s tee’d up when you’ve got bandwidth. Each to-do date is a nudge to tackle the real work, not just the easy bits you like doing.

Some tasks resist splitting

Not every job splits neatly and it shouldn’t. Refactoring legacy code, for instance, laughs at tidy subtasks. You can’t always say “fix auth today, optimize queries tomorrow” – it’s a messy, iterative beast. But that’s where to-do dates shine brighter. Instead of forcing a breakdown, set time to dive in: “Poke at the codebase for 45 minutes on Monday,” “Tweak auth logic on Wednesday,” “Chase down query bottlenecks on Friday.” Rather than being rigid steps, these are simple commitments to show up and have consistent contact with the problem in hand.

How I make it work in practice

Here’s my setup:

• Hard due dates (like “Deploy feature, March 6”) go in Google Calendar – non-negotiable stakes in the ground.

• Subtasks and to-do dates live in Nestful, a dynamic to-do list that surfaces subtasks when they matter.

I put “Deploy feature” as my parent task in Nestful, then the four tasks I mentioned above as subtasks, with their respective to-do dates. I then drop in the less neat tasks, like tackling legacy code, on specific days with an allocated amount of time I intend to spend on them. Example: Spend 45 minutes untangling queries on Friday. I don’t have to finish that task on Friday, but I’ve just gotta engage with it. This tactic allows engagement to snowball, the due date rolls around and things are in an almost-done kind of state. No sweating.

For gnarly projects, I lean on micro-commitments to break the ice: “Open the editor and sketch one function” or “Run the old code and spot one flaw.” These tiny tasks (also complete with to-do dates) trick me into starting, and once I’m in, the real work flows.

Nestful’s Agenda View ties it together, showing me what’s ripe today and what can wait. It means there’s no guesswork, no cherry-picking.

Final thoughts

Due dates and division into sub tasks lets you hide from the hard stuff, picking easy tasks to feel productive while the clock ticks. To-do dates flip that, they’re guideposts that make you face the work that matters, when it matters. Whether it’s a feature you can slice up or a refactor that defies division, the principle holds: schedule the effort, not just the outcome.

Try Nestful.

Subscribe now

Share

I’d wake up at 6AM already behind, frantically bouncing between emails and trying to decipher my own half-written notes. One client needed revisions on a strategy doc, another was waiting on a pitch, and somewhere in between, I had to make sense of a last-minute brief I had completely forgotten about.

My immediate solution was task blocking in my Google Cal, but it quickly started looking like a losing game of Tetris, as tasks overran, interruptions took place and quickly everything became a big mess of overscheduling and subsequent rescheduling.

I started questioning myself: How are other people managing this? We all have the same 24 hours in a day — isn’t that what Kim K said? Maybe I just don’t wanna work. Had I taken on too much, or was I just terrible at time management?

The reality check

I know from experience that whenever you want to change something in your life, the first step is to be brutally honest with yourself. You need to ask: How much do I really spend each month? How much do I actually work out? Only then can you figure out why you’re not saving any money or seeing the fitness results you want.

It hadn’t occurred to me to apply this same level of honesty to my time. But once I did, the results were a real slap in the face. The amount of hours I thought I was working versus the actual time spent on deep work was actually embarrassing. Hours spent “working” were padded out with answering quick messages, checking X every 10 minutes and completing small insignificant tasks. Yes, I am distracted and avoidant.

I cleared everything from my Google Cal and stared hard at the blank Week View. The hours were there and I needed to understand how so many of them were going unaccounted for, if I were ever going to succeed in working for more than one client. I started to wonder if this was more about managing my own delusion about time than time itself.

Tracking my time and restructuring my days

To figure out where my time was going, I started backtracking everything in my calendar. I tracked every time I sat down to work, went to the kitchen, took a shower, and left the house for a few hours. The gaps were eye-opening — I spent more time on everything else than work itself. I told you, avoidant.

I read Cal Newport’s Deep Work, which helped me understand that I was filling so much of my time with shallow tasks and not getting to the important “deep” stuff. Day after day, I was filling my mornings with busywork, putting off deep work until the afternoon and then not having sufficient energy to do it.

I took some time to wallow reflect on what was happening and tapped into something I already knew about myself. I have the highest level of concentration in the early morning, so if I want to get anything meaningful done, I have to capitalize on those morning hours. The rest of the day, I could give away to shallow (but necessary) tasks.

The perk of freelancing of course is that you can plan around what works best for you. For me:

• Early mornings → Deep work (writing, strategy)

• Afternoons → Study, admin, light tasks

• Evenings → Offline time, no screens

Getting organized

From my experience, any vague sense of organization starts with a list. I love lists — shopping lists, movies to watch, books to read, to-do lists. They work great on paper for some things and better on a computer, where you can edit and remove items for others. So, whenever I’ve got multiple tasks on-the-go, a list is typically involved.

I’ve also spent a lot of time playing around with Kanban boards; there’s something satisfying about dragging tasks from To Do to Doing to Done. But when I’m managing multiple projects with shifting deadlines, I’m still having to put in the time to manually shuffle everything around. This led me to trying AI scheduling tools but I never went further than the free trial because there was too much manual setup to get it exactly how I wanted it — all time taken away from actually working.

Each time I started to feel overwhelmed by these tools, I’d default back to old-school list writing in Obsidian, then keying in deadlines and meetings to my Google Cal. I knew things could be more efficient but they work fine-ish like this.

So, it went like this for a while:

1. Prepare my list in Obsidian the evening before.

2. Get up early, complete the most important “deep” work and not touch any of the “shallow” stuff or social media until the afternoon – which still to this day takes a lot of discipline.

3. Prepare a new list for the next day. This was a crucial step — spending time figuring out what I’d be doing the next morning — so I could dive straight into it.

My current hybrid system

I’ve now created a system that works even better than this. I don’t need to spend time each evening figuring out what to do the next day anymore. I plan the upcoming week on Friday — and that’s it.

I’m still using Google Cal but I’m also using an app called Nestful. Google Cal is predominately where I put my fixed meetings and block out time where I know I will be sitting at my desk. I use Nestful alongside this — it’s basically a dynamic to-list, so it orders your tasks based on deadlines and tells you what you need to work on as soon as you sit down to work.

Here’s how it works: I add all the events that need to happen at specific times and places to my calendar. This often fills up further in advance than a week, but Friday is where I do my regular calendar check-up, so I know what’s coming up. Next week, I’ve got a couple of client check-ins, a few deadlines to keep an eye on and some on-site filming events — these all need to happen at specific times. The rest of the time, when I know I’ll be sitting at home at my desk, I block out with “Spontaneous work.” This is where I will go into Nestful and complete whatever it tells me is due next.

Instead of “Spontaneous work,” why not add the tasks to the calendar directly? Let’s revisit my Tetris point. Life is too unpredictable. A client requests something urgently, the dog pukes on the nice rug, mother calls for a chat — each of these derails the task-blocked calendar instantly. Maintaining the calendar becomes a task in itself and, as you’ll already have noted, I have too many tasks as it is.

Now, onto Nestful. I drop in all the tasks I need to do into its homepage. Each task can nest smaller tasks, so I give the main task the client’s name and then nest all the tasks required and due dates within it.

Here’s what it looks like within my client task:

I’ve done the same thing for my two other clients, adding in all of the tasks and due dates. Now, when I go to the Nestful homepage, it looks like this:

I can see exactly what is due today and get a holistic view of all my tasks coming up. Once today’s tasks are completed and checked off, they get archived. Tomorrow when I open Nestful, the Tomorrow column will have shifted to Today.

Nestful shifts the focus away from time allocation and scheduling to getting things done. All I need to know is that I have a two-hour window of concentrated work scheduled in my calendar, and then Nestful does the work of telling me exactly what to focus on next. There’s no need to schedule and reschedule tasks because they’re just there, waiting to be completed.

If you’re a freelancer struggling to keep up, I recommend trying this. The combination of structured flexibility is the only thing that’s actually worked for me so far.

This system keeps me sane. No decision fatigue. No wasted minutes debating priorities. Just work getting done.

https://nestful.app/

Subscribe now

Share

OmniMessage is written in Gleam, a language that compiles to both Erlang and JavaScript, and is an extension of Lustre, Gleam’s major frontend framework.

To understand the benefits of OmniMessage and how it works, we first need we’ll first need explore how Gleam and Lustre provide one of the best developer experiences you can find for the web these days, and how building on top of them can improve that experience even more.

If you’re already familiar with The Elm Architecture and functional languages, you can click here to skip to the OmniMessage part, however going through the Lustre tutorial really puts the problem it solves in perspective.

A Functional C

Gleam’s website says:

Gleam powers the app this blog is for, Nestful. Which I am incrementally rewriting.

That other blog post already covers a lot of Gleam’s advantages and the specific considerations and tradeoffs as they pertain to Nestful. Those still apply, but when we look at frontend development in general, one key trait of Gleam is crucial:

Gleam is a functional language with a C-style syntax.

That is an indispensable advantage on the journey to ecosystem nirvana.

Here’s some for you to bask in. It is a very pleasant language:

We know that frontend developers like functional paradigms. TypeScript functional-like libraries continue to pop up, some developers really like React, and even when they dislike those, they still argue about it on AirBnB’s style guide repository.

Even with all the that functional engagement in mind, however you slice it, frontend development is all in JavaScript-land, and JavaScript has a C-style syntax.

In my opinion, this is a significant part of why previous attempts like Elm, Reason/ReScript and PureScript did not reach the success they should have. It is also why Flutter made such huge strides with frontend developers. Flutter’s developer experience is excellent, and Dart sure does feel a lot like TypeScript.

The fact that Gleam has that kind of syntax will help the most crucial part of going mainstream — ecosystem growth. It’s going to be nice to have a functional language that’s not only simple and type safe, but also has a large ecosystem.

Enter Lustre

If I had to describe Lustre with only a few words, I would say it is Gleam’s Elm and LiveView.

Yes, Elm and LiveView. While not a 1-to-1 match, Lustre is a Model-View-Update framework that can run both as a single-page application, like Elm, on the server like LiveView, and with OmniMessage — well, you’ll see.

I am not going to define Model-View-Update. Instead, I’m going to teach you some Lustre. By the time we’re done you’ll know exactly what it means.

We’ll start with a counter example, which is small and contained, then continue to build a (very, very minimal) chat app. Follow along with the code, it’s nice seeing how the different pieces fall into place.

First, let’s keep our data in a model, and have a function initializing it:

type Model {
  Model(count: Int)
}

fn init(initial_count: Int) -> Model {
  Model(int.max(0, initial_count))
}

A Model type that contains a single integer, which we initialize to a given value, but not lower than zero. Fairly simple.

Next, we’ll define messages that can operate on that model:

import gleam/int

import lustre/effect.{type Effect}

type Msg {
  Increment
  Decrement
}

fn update(model: Model, msg: Msg) -> #(Model, Effect(Msg)) {
  case msg {
    Increment -> #(Model(model.count + 1), effect.none())
    Decrement -> #(Model(int.max(0, model.count - 1)), effect.none())
  }
}

Our update function returns a new count based on the message it receives, adding or substracting from the original. Don’t mind the effect.none() part for now — we’ll get to that later.

Finally, we’ll have a function for displaying a user interface. It’s important to note that all the view functions in this post use lustre_pipes, which is an extension of Lustre’s view utilities that I consider easier to read:

import lustre_pipes/attribute
import lustre_pipes/element.{type Element}
import lustre_pipes/element/html
import lustre_pipes/event

fn view(model: Model) -> Element(Msg) {
  let count = int.to_string(model.count)

  html.div()
  |> attribute.class("h-full w-full flex justify-center items-center")
  |> element.children([
    html.button()
      |> event.on_click(Decrement)
      |> element.text_content("-"),
    html.p()
      |> element.text_content(count),
    html.button()
      |> event.on_click(Increment)
      |> element.text_content("+"),
  ])
}

When we hand the init, update, and view functions to Lustre starts a runtime that:

1. Calls init with an initial value

2. Uses the resulting model to render a view

3. Listens to events and calls update with any dispatched messages, then back to #2

Model, view, update.

Because views are pure functions, meaning they do not perform any side-effects, they can be used anywhere. Every time we’ll hand the same model into that function, we’re going to get the same view. Every. Single Time.

This makes features like hydration very simple. Since this is a deterministic state machine, all we need is the current state. In Lustre, hydration means simply sending the model alongside the rendered HTML. Lustre will use that model to create a view of its own and compare it to the prerendered HTML. If they match, the app is “hydrated”.

But I digress. We’re here to talk about client-server state management, so let’s continue, building a small chat app.

A LiveView Single Page Application

Our app should be able to:

1. Send chat messages

2. Display chat messages and their status (sending, sent, received, etc)

3. Have a button that scrolls down to the latest chat message

4. Show the amount of active users in the chat room

We’re missing some key features such as receiving messages, chat room creation and user authentication. It doesn’t matter. Even this confined use case of a single room with a single user will show us the benefits of managing state with Lustre.

We’re going to build a single page application first, then use the fundamentals for the server as well. The conversion will be trivial.

First, our model:

// For date handling
import birl

pub type Model {
  Model(
    messages: List(ChatMessage),
    draft_content: String,
  )
}

pub type ChatMessage {
  ChatMessage(
    id: String,
    content: String,
    status: ChatMessageStatus,
    sent_at: birl.Time,
  )
}

pub type ChatMessageStatus {
  ClientError
  ServerError
  Sent
  Received
  Sending
}

Note that to avoid confusing chat messages and Lustre messages, the former will be strictly called a chat message.

We’ll initialize our model with an empty draft and empty chat messages.

fn init(_) -> #(Model, effect.Effect(Msg)) {
  #(Model([], draft_content: ""), effect.none())
}

Again, don’t worry about that effect.none() for now.

To define our Msg type, first let’s think through what we need to do. Lustre suggests using a SubjectVerbObject (SVO) structure:

1. UserUpdateDraftContent

2. UserSendChatMessage

3. UserScrollToLatest

4. ServerSentChatMessages

Number 4 is for getting back messages we sent to the server, not for other user’s messages, which is out of scope. This is more of a bring-your-own-refresh kind of app.

Having those messages written in SVO not only makes it easy to reason about how the app works, but also makes it easier to debug later, if and when needed.

Here is an update function that takes care of all the simple bits:

// For uuid generation
import gluid


pub type Msg {
  UserUpdateDraftContent(String)
  UserSendChatMessage
  UserScrollToLatest
  ServerSentChatMessages(List(ChatMessage))
}

fn update(model: Model, msg: Msg) -> #(Model, Effect(Msg)) {
  case msg {
    UserUpdateDraftContent(draft_content) -> #(
      Model(..model, draft_content:),
      effect.none(),
    )
    UserSendChatMessage -> {
      let chat_msg =
        Message(
          id: gluid.guidv4() |> string.lowercase(),
          content: model.draft_message,
          status: shared.Sending,
          sent_at: birl.utc_now(),
        )

      let chat_msgs = [chat_msg, ..model.chat_msgs]

      #(Model(..model, chat_msgs:), effect.none())
    }
  }
}

How lovely is that case, which the Gleam compiler should mark as an error. Gleam makes sure case is exhaustive — it has our back in guaranteeing we address all of the different messages that the update function should be able to handle.

But wait! There’s a design problem. We need to clean the draft after sending it, but that doesn’t make sense to do in the UserSendChatMessage branch — chat messages can come from other places. A “scheduled messages” queue, for example. We need another message, UserSendDraft:

pub type Msg {
  UserSendDraft
  UserUpdateDraftContent(String)
  UserSendChatMessage(String)
  UserScrollToLatest
  ServerSentChatMessages(List(ChatMessage))
}

fn update(model: Model, msg: Msg) -> #(Model, Effect(Msg)) {
  case msg {
    UserUpdateDraftContent(content) -> #(
      Model(..model, draft_content: content),
      effect.none(),
    )
    UserSendChatMessage(chat_msg) -> {
      let chat_msgs = [chat_msg, ..model.chat_msgs]

      #(Model(..model, chat_msgs:), effect.none())
    }
    UserSendDraft -> #(
      Model(..model, draft_content: ""),
      effect.from(fn(dispatch) {
        Message(
          id: gluid.guidv4() |> string.lowercase(),
          content: model.draft_content,
          status: shared.Sending,
          sent_at: birl.utc_now(),
        )
        |> UserSendChatMessage
        |> dispatch
      }),
    )
  }
}

UserSendDraft returns not only the model, but also something called an Effect.

An effect is a type that instructs Lustre’s runtime to perform tasks on our behalf. In this case we ask Lustre to dispatch UserSendChatMessage with the message, by returning that effect alongside our model. effect.none() simply tells Lustre that there’s nothing to do, which is the case for the rest of our case branches.

Side effects are a must in most apps, especially on the web. To be able to use them while keeping our update function pure (meaning, having the same output every time it receives the same input), MVU delegates their execution to the runtime. If we want a side effect to happen, we have to ask the runtime to perform it.

Now that we know effects exist, we’ll use them to implement UserScrollToLatest.

For that we need need a container to scroll. Enter, a view function:

fn status_string(status: ChatMessageStatus) {
  case status {
    ClientError -> "Client Error"
    ServerError -> "Server Error"
    Sent -> "Sent"
    Received -> "Received"
    Sending -> "Sending"
  }
}

fn chat_message_element(chat_msg: ChatMessage) {
  html.div()
  |> element.children([
    html.p()
    |> element.text_content(
      status_string(chat_msg.status) <> ": " <> chat_msg.content,
    ),
  ])
}

fn sort_chat_messages(chat_msgs: List(ChatMessage)) {
  use a, b <- list.sort(chat_msgs)
  birl.compare(a.sent_at, b.sent_at)
}

fn view(model: Model) -> element.Element(Msg) {
  let sorted_chat_msgs =
    model.chat_msgs
    |> sort_chat_messages

  html.div()
  |> attribute.class(
    "h-full flex flex-col justify-center items-center gap-y-5"
  )
  |> element.children([
    html.div()
      |> attribute.id("chat-msgs")
      |> attribute.class(
      "h-80 w-80 overflow-y-auto p-5 border border-gray-400 rounded-xl",
      )
      |> element.keyed({
        use chat_msg <- list.map(sorted_chat_msgs)
        #(chat_msg.id, chat_message_element(chat_msg))
      }),
    html.form()
      |> attribute.class("w-80 flex gap-x-4")
      |> event.on_submit(UserSendDraft)
      |> element.children([
        html.input()
          |> event.on_input(UserUpdateDraftContent)
          |> attribute.type_("text")
          |> attribute.value(model.draft_content)
          |> attribute.class(
            "flex-1 border border-gray-400 rounded-lg p-1.5")
          |> element.empty(),
        html.input()
          |> attribute.type_("submit")
          |> attribute.value("Send")
          |> attribute.class(
      "border border-gray-400 rounded-lg p-1.5 text-gray-700 font-bold",
          )
          |> element.empty(),
      ]),
  ])
}

Note how event handlers must return a Msg for our update function to handle.

event_onsubmit accepts a straight up Msg, so we just put UserSendDraft.

on_input accepts a function of the type fn(String) → Msg, which is exactly what UserUpdateDraftContent is. The following is identical:

|> event.on_input(fn(value: String) {
  UserUpdateDraftContent(value)
})

If you know HTML, the rest is fairly straightforward except for two parts: use and element.keyed.

use is syntactic sugar for a final-argument callback. Everything before the arrow is the callback’s arguments, lines below the use are the callback’s body.

This means these two are equivalent:

fn sort_chat_messages(chat_msgs: List(ChatMessage)) {
  use a, b <- list.sort(chat_msgs)
  birl.compare(a.sent_at, b.sent_at)
}

fn sort_chat_messages(chat_msgs: List(ChatMessage)) {
  chat_msgs
  |> list.sort(fn(a, b) {
    birl.compare(a.sent_at, b.sent_at)
  })
}

You know a language is simple when use is its most “complicated” part.

element.keyed creates an element whose children have a unique identifier (the key) attached to them such that when Lustre has to re-render the list itself, it knows which elements changed and which didn’t. This is similar to React’s or Vue’s key property and is done in Lustre by giving the element.keyed() function a list of tuples in the form of #(key, Element).

Now that we have our view, we can handle UserScrollToLatest:

# for handling possible errors
import gleam/result
# for interacting with the DOM
import plinth/browser/element as plinth_element

fn update(model: Model, msg: Msg) -> #(Model, Effect(Msg)) {
  case msg {
    // other handlers omitted for brevity
    UserScrollToLatest -> #(model, scroll_to_latest_message())
  }
}

const msgs_container_id = "chat-msgs"

fn scroll_to_latest_message() {
  effect.from(fn(_dispatch) {
    let _ =
      document.get_element_by_id(msgs_container_id)
      |> result.then(fn(container) {
        plinth_element.scroll_height(container)
        |> plinth_element.set_scroll_top(container, _)
        Ok(Nil)
      })

    Nil
  })
}

This code uses plinth, an library to interact with browser APIs, to first find the container by its id (get_element_by_id), and if found (result.then), scroll.

By extracting this effect to a separate function, we can include it in other places, like automatically scrolling on UserSendChatMessage.

By now you should experience how Gleam and Lustre make for this very structured, harmonious development experience, where everything has a place in the render loop.

Now that we have the client side taken care of, let’s address the server. As you’ve probably guessed, talking to the server is a side effect, meaning we’ll instruct Lustre to make the talking on our behalf. Luckily there is a package that does just that:

import lustre_http as http

fn update(model: Model, msg: Msg) -> #(Model, Effect(Msg)) {
  case msg {
    // other handlers omitted for brevity
    ClientMessage(shared.UserSendChatMessage(chat_msg)) -> {
      let chat_msgs = [chat_msg, ..model.chat_msgs]

      #(
        Model(..model, chat_msgs:),
        effect.batch([
          scroll_to_latest_message(),
          http.post(
            "/chat-message",
            [chat_msg] |> chat_msgs_to_json,
            http.expect_json(
              chat_msgs_from_json,
              ServerSentChatMessages,
            ),
          ),
        ]
      )
    }
  }
}

This takes care of creating the message on the server. We still update the model with the new chat message in Sending state, and we continue with effect.batch.

effect.batch takes several effects and combines them to a single one for our update function. The first one is our scroll effect that’ll happen after sending a message. The second will HTTP POST that message to the path /chat_message.

That effect is from the lustre_http library (that we import as http), that can create effects of HTTP requests. The arguments for creating the POST effect are:

1. The path to POST to, in our case /chat-message

2. The body of the post request, in our case a JSON.stringify-ed chat message

3. A description of the result, (JSON) and its handler (ServerSentChatMessages).

In a production chat app it would have been better to use websockets. The websocket effect works very similarly but requires more setup due to the nature of websockets. Since boilerplate does not add to our learning, we demonstrate using regular HTTP.

When Lustre will execute this effect, the following will happen:

1. It will post our encoded chat message to /chat-message

2. It will try parsing it as JSON using chat_msgs_from_json

3. On success, it will dispatch ServerSendChatMessages(Ok(messages))

4. On error, it will dispatch ServerSendChatMessages(Error(error))

Gleam, you see, has errors as values. That means that except for problematic FFI, functions never throw. You must deal with errors as they come or consciously defer their handling. This pairs fantastically with case’s exhaustiveness checks:

pub type Msg {
  // accepts a `Result` from `lustre_http`'s effect:
  ServerSentChatMessages(Result(List(ChatMessage), http.HttpError))
}

fn update(model: Model, msg: Msg) -> #(Model, Effect(Msg)) {
  case msg {
    // Gleam will make sure both variants are present. Lovely.
    ServerSentChatMessage(Ok(List(ChatMessage)) -> todo
    ServerSentChatMessage(Error(error)) -> todo
  }
}

Again, we have a design problem. The server is the source of truth for chat messages, so we’d like it to override our local copies (that’s how a Sending chat message will become a Sent chat message). However doing that for a list can be quite costly.

Let’s change our state to hold chat messages in a dictionary, instead:

pub type Model {
  Model(
    messages: Dict(String, ChatMessage),
    draft_content: String,
  )
}

And implement ServerSendChatMessage:

fn update(model: Model, msg: Msg) -> #(Model, Effect(Msg)) {
  case msg {
    ServerSentChatMessage(Ok(server_chat_msgs)) -> {
      let chat_msgs =
        model.chat_msgs
        |> dict.merge(server_chat_msgs)

      #(Model(..model, chat_msgs:), effect.none())
    }
    ServerSentChatMessage(Error(error)) -> {
      // this is where you'd show, say, an error toast
      #(model, effect.none())
    }
    // changes to other branches available in the full code below
  }
}

As with any project, the more time we spend writing its code, the more we learn about it and about the solutions it demands. With MVU, those changes are easy to adapt to since the state mechanism stays the same. By keeping the state handling mechanism completely separate from our project’s design choices, we avoid having to change it when we inevitably discover we made poor ones.

To complete our server-communication portion for chat messages, let’s fetch on init:

fn init(_) -> #(Model, effect.Effect(Msg)) {
  #(
    Model(dict.new(), draft_content: ""),
    http.get(
      "/chat-message",
      http.expect_json(
        chat_msgs_from_json,
        ServerSentChatMessages,
      ),
    ),
  )
}

So far this should have been a relatively pleasant experience of writing a very regular app, with all the pros and cons that come with it. Our state handling approach forever puts us on alert, having to make sure our local copy of the chat is up to date with the server’s copy — the source of truth. This is a very common SPA issue.

I can hear the LiveView gang collectively yelling into the past as I’m typing. “Keep everything on the server”, they say. Well, we’re about to. — “and get rid of that REST mess!”. Ok, I heard you, we’re about to.

Our first step of evolution will be to implement our final missing feature:

Show the amount of active users in the chat room

I sneakily did not include a Msg for handling this when we built our update function. This information is strictly server-side, with no interaction, and most importantly — it is meaningless when we’re offline.

It’s a no-brainer to run it exclusively on the server. This is where the LiveView part of “Elm and LiveView” comes in. We can take this Lustre component:

type Model {
  Model(user_count: Option(Int))
}

fn init(count_listener: fn(fn(Int) -> Nil) -> Nil) {
  #(
    Model(None),
    effect.from(fn(dispatch) {
      listen(fn(new_count) { 
        dispatch(GotNewCount(new_count))
      })
    })
  )
}

type Msg {
  GotNewCount(Int)
}

fn update(model: Model, msg: Msg) {
  case msg {
    GotNewCount(new_count) -> #(Model(new_count), effect.none())
  }
}

fn view(model: Model) {
  let count_message =
    model.user_count
    |> option.map(int.to_string)
    |> option.unwrap("Getting user count...")

  html.p()
    |> element.text_content(count_message)
}

Run it on the server, serve it via websockets on /user-count, then add the following to our client’s view function:

server_component.component()
  |> server_component.route("/user-count")
  |> element.children([
    html.p()
      |> element.text_content("Getting user count...") 
  ])

Lustre will make it happen so that our user count will travel from the server into the client, accurately rendered. No need to sync state, everything comes from the source.

In my opinion, even after considering all the good that is Gleam, MVU, and Lustre’s implementation of it, this is the biggest advantage of them all.

Whenever you use HTMX or LiveView, there always comes a time when you need to “sprinkle some JavaScript”. While sprinkling some JavaScirpt is much better than writing everything in JavaScript, writing none is best.

This is the power of Gleam’s Lustre. You have all the advantages of a single page application, and of server side components. You pick the right approach, and use the same exact tool to fulfill it.

I hear you, HTMX people calling into the past: “make the chat messages server side too”. Nope. Not going to happen. At least not the way you think it will.

You see, the chat is meaningful even when the user is offline. Even if you make it online-only, there’s a problem moving the chat messages functionality to the server. How will we handle a chat message that was just sent? The server can’t render a Sending state because it’s still sending — it doesn’t know it exists!

“Sprinkle some JavaScript!”

Yes, the current solution is to have some mix of client and server side code, and do the syncing manually, just for that one bit.

Or is it?

Introducing OmniMessage

OmniMessage is a library created to answer this exact problem. It is composed of a Lustre extension on the client side, and server utilities (including another, optional, Lustre extension) on the server side.

After you set those two up a subset of messages, at your discretion, will dispatch in both the client and the server. You can think of this as a more blissful RPC.

Here’s the boilerplate:

import omnimessage_lustre as omniclient

// This just converts to/from JSON
let encoder_decoder =
  omniclient.EncoderDecoder(
    // this converts TO JSON
    fn(msg) {
      case msg {
        // Encode a certain subset of messages
        ClientMessage(message) -> Ok(shared.encode_client_message(message))
        // Return Error(Nil) for messages you don't want to send out
        _ -> Error(Nil)
      }
    },
    // this converts FROM JSON
    fn(encoded_msg) {
      shared.decode_server_message(encoded_msg)
      |> result.map(ServerMessage)
    },
  )

// This creates an extended Lustre component
omniclient.component(
  init,
  update,
  view,
  dict.new(),
  encoder_decoder,
  transports.http("http://localhost:8000/omni-http", option.None, dict.new()),
  TransportState,
)

The “biggest” chunk of work is encoding and decoding, but that’s something you need to do anyway. Even pure server components eventually need to save to a database.

If we setup OmniMessage like that, our original Lustre app could reuse all the client-side messages we wrote at the beginning of this post, and the server will reply and override our Sending chat messages when they are received.

Yes, yes, I know you want to see the code, but it really is the same. Here, look:

// MODEL ---------------------------------------------------------------

pub type Model {
  Model(chat_msgs: dict.Dict(String, ChatMessage), draft_content: String)
}

fn init(_initial_model: Option(Model)) -> #(Model, effect.Effect(Msg)) {
  #(Model(dict.new(), draft_content: ""), effect.none())
}

// UPDATE --------------------------------------------------------------

pub type Msg {
  UserSendDraft
  UserScrollToLatest
  UserUpdateDraftContent(String)
  ClientMessage(ClientMessage)
  ServerMessage(ServerMessage)
  TransportState(transports.TransportState(json.DecodeError))
}

fn update(model: Model, msg: Msg) -> #(Model, effect.Effect(Msg)) {
  case msg {
    // Good old UI
    UserUpdateDraftContent(content) -> #(
      Model(..model, draft_content: content),
      effect.none(),
    )
    UserSendDraft -> {
      #(
        Model(..model, draft_content: ""),
        effect.from(fn(dispatch) {
          shared.new_chat_msg(model.draft_content, shared.Sending)
          |> shared.UserSendChatMessage
          |> ClientMessage
          |> dispatch
        }),
      )
    }
    UserScrollToLatest -> #(model, scroll_to_latest_message())
    // Shared messages
    ClientMessage(shared.UserSendChatMessage(chat_msg)) -> {
      let chat_msgs =
        model.chat_msgs
        |> dict.insert(chat_msg.id, chat_msg)

      #(Model(..model, chat_msgs:), scroll_to_latest_message())
    }
    // The rest of the ClientMessages are exlusively handled by the server
    ClientMessage(_) -> {
      #(model, effect.none())
    }
    // Merge strategy
    ServerMessage(shared.ServerUpsertChatMessages(server_messages)) -> {
      let chat_msgs =
        model.chat_msgs
        // Omnimessage shines when you're OK with server being source of truth
        |> dict.merge(server_messages)

      #(Model(..model, chat_msgs:), effect.none())
    }
    // State handlers - use for initialization, debug, online/offline indicator
    TransportState(transports.TransportUp) -> {
      #(
        model,
        effect.from(fn(dispatch) {
          dispatch(ClientMessage(shared.FetchChatMessages))
        }),
      )
    }
    TransportState(transports.TransportDown(_, _)) -> {
      // Use this for debugging, online/offline indicator
      #(model, effect.none())
    }
    TransportState(transports.TransportError(_)) -> {
      // Use this for debugging, online/offline indicator
      #(model, effect.none())
    }
  }
}

See? Same logic. The only differences are that some types are wrapped so we could share them with the server, and instead of handling network errors directly we now handle them through a TransportState variant.

Other than that, you dispatch messages and the server replies as if it’s the same app.

You decide how to encode the messages, and what transport to send them through. As long as the server can understand those, you can use whatever server, in any language. Currently we have transports for HTTP and websockets, but any transport is possible. For example, you could write one to communicate with an Electron or Tauri backend.

Here are some examples utilizing omnimessage_server, meant for Gleam servers. Say you have this simple handler:

fn handle(ctx: Context, msg: Msg) -> Msg {
  case msg {
    ClientMessage(shared.UserSendMessage(message)) -> {
      ctx |> context.add_message(message)

      context.get_chat_messages(ctx)
      |> shared.ServerUpsertMessages
      |> ServerMessage
    }
    ClientMessage(shared.UserDeleteMessage(message_id)) -> {
      ctx |> context.delete_message(message_id)

      context.get_chat_messages(ctx)
      |> shared.ServerUpsertMessages
      |> ServerMessage
    }
    ClientMessage(shared.FetchMessages) -> {
      context.get_chat_messages(ctx)
      |> shared.ServerUpsertMessages
      |> ServerMessage
    }
    ServerMessage(_) | Noop -> Noop
  }
}

Here’s how you’d use it in a Gleam HTTP server:

use <- omniserver.wisp_http_middleware(
  req,
  "/omni-http",
  encoder_decoder(),
  handle(ctx, _),
)

Just give it the request, the path it should handle, the messages encoder/decoder and the handler from above, and it will:

1. Decode incoming messages

2. Run them through the handler

3. Encode the result

4. Generate an HTTP response with it

Need to send messages without the client initiating a request? Use websockets:

["omni-pipe-ws"], http.Get ->
  omniserver.mist_websocket_pipe(
    req,
    encoder_decoder(), // this is the same encoder_decoer
    handle(ctx, _), // the same message handler
    logger, // error handler
  )

Have a more complex app and you need structure? Use a Lustre server component!

["omni-app-ws"], http.Get ->
  omniserver.mist_websocket_application(
    req,
    chat.app(), // lustre server component
    ctx, // flags for its init
    logger // error handler
  )

This is how the server component will look like:

// MODEL ---------------------------------------------------------------
pub type Model {
  Model(messages: dict.Dict(String, shared.ChatMessage), ctx: Context)
}

fn init(ctx: Context) -> #(Model, effect.Effect(Msg)) {
  #(Model(messages: ctx |> context.get_chat_msgs, ctx:), effect.none())
}

// UPDATE --------------------------------------------------------------

pub type Msg {
  ClientMessage(ClientMessage)
  ServerMessage(ServerMessage)
}

pub fn update(model: Model, msg: Msg) {
  case msg {
    ClientMessage(shared.UserSendMessage(message)) -> #(
      model,
      effect.from(fn(dispatch) {
        model.ctx |> context.add_message(message)

        ctx
        |> context.get_chat_msgs
        |> shared.ServerUpsertMessages
        |> ServerMessage
        |> dispatch
      }),
    )
    ClientMessage(shared.UserDeleteMessage(message_id)) -> #(
      model,
      effect.from(fn(dispatch) {
        model.ctx |> context.delete_message(message_id)

        ctx
        |> context.get_chat_msgs
        |> shared.ServerUpsertMessages
        |> ServerMessage
        |> dispatch
      }),
    )
    ClientMessage(shared.FetchMessages) -> #(
      model,
      effect.from(fn(dispatch) {
        get_messages(model.ctx)
        |> shared.ServerUpsertMessages
        |> ServerMessage
        |> dispatch
      }),
    )
    ServerMessage(shared.ServerUpsertMessages(messages)) -> #(
      Model(..model, messages:),
      effect.none(),
    )
  }
}

It’s like having the same app spread across two different files.

OmniMessage is still very young and is missing some important features, but the vision is clear — it is the last piece in the trifecta that is zen state management:

1. Client state — solved by MVU

2. Server state — solved by server components/LiveView approach

3. Hybrid state — solved by OmniState

The hybrid state OmniMessage represents is a very sharp sword that can be tricky to wield without a clear separation of concerns. This is why OmniMessage shines when a single party is the source of truth, since we can simply override the other party’s state every time a message arrives. This gives us all the benefits of OmniMessage without the beehive hornets nest that is carefully merging state.1

This is why Lustre is the end game of frontend development. It collected all of the right solutions and wrapped them up in the nicest, gleamy package.

Full, working, code is available in the OmniMessage repository.

Here is the OmniMessage documentation:

https://hex.pm/packages/omnimessage_server

https://hex.pm/packages/omnimessage_lustre

And don’t forget to check out Nestful! Not only is Nestful written in Gleam (the new “written in Rust”), but it actually has novel ways to manage your time:

https://nestful.app

Share

Nestful is very list-centric. Even the Kanban and Agenda views are just horizontal lists of vertical lists, and Nestful’s free-form text, the description field, is very limited. This avoidance in on purspose, a result of trial and error.

Before building Nestful, I had used some note-based competitors only to realize they weren’t competitors at all. Note-taking is a form of knowledge organization that is almost entirely orthogonal to list-taking.

When I tried using note-taking solutions exclusively, I found myself trying to recreate the functionality of list-taking inside of a note. While it is technically possible, it breaks down fairly early.

The Role of Notes

Notes are a collection of sections1 that benefit from being a single piece of prose.

An essay such as this blog post is the immediate example, where each paragraph is part of the essay and although it has some meaning by itself, it is significantly reduced.

Job listings, reviews, pitch documents, diary entries, and summaries are more examples that fit note-taking well. They consist of sections that form a whole, with each section losing significance when in isolation.

The Role of Lists

Lists are the exact opposite. They are a collection of items2 that preserve their meaning without being connected by prose.

The immediate list example is a shopping list, where each item has to be acquired regardless of the others.

I know what you’re thinking — a grocery list may have items dependant on one another if they are part of the same recipe. For example, if I want to make cookies and there aren’t any eggs available, I won’t need the sugar.

As long as you want to make cookies, you’re going to need sugar and eggs. The lack of eggs does not cancel the sugar, it just means that you have to look for eggs elsewhere. If eggs are hard to find, you may give up on making cookies, but that’s not sugar being dependent on eggs, that’s the ingredients depending on the recipe.

Even if you don’t think about it that way, a grocery list is a list of lists. Every item in that list is going to be used in the preparation of food, and therefore is part of a recipe.

This is where note-taking doesn’t fit. Notes cannot differentiate independent sections from interconnected ones, something that is explicit in lists.

Nestful uses that list-taking extensively. If you have lists of tasks nested into one another, Nestful allows you to “bubble up” due items by setting a due date. No matter how deep a task is nested, an agenda view will show it to you when it’s due. This is made possible by a list’s explicit division into items. In our grocery list example, one could add recipes, and the groceries will “bubble up” to form the list.

It’s a Spectrum

The division of content into lists and notes is not binary. Some fit into both.

While in my opinion a screenplay’s outline benefits tremendously from being a list, and should only become prose in the case of writing a treatment (or the actual screenplay). Some screenwriters prefer to outline as prose. That is fine.

The nice thing about it being a spectrum is that if you have content that’s not a clear fit for either, either will work, as it’s probably in the middle of the spectrum.

Use the right tool for the job.

I often hear being overwhelmed is a major roadblock to productivity, but it shouldn’t be that way. In fact — it’s easy to avoid.

To understand the solution, we first must understand the problem. While seemingly straightforward, there’s a nuance we must take to heart:

We can be overwhelmed by the length of a list and the perceived size of an item.

Therefore we need to solve both for a list with a large number of small items and a list with one huge item.

The latter is easier, so let’s start there.

Divide and Conquer

Any single task you find overwhelming is divisible into smaller tasks.

That is a law of nature that is eternally true. Why it is true is a tale for another day. Do email me if you’re interested.

If you ever happen onto a task that you find indivisible, you must check your premises. Any violation of the law above cannot exist. The case of the unknown is the easiest to split, as the first subtask will be to figure out how split to the seemingly indivisible task. That subtask is also divisible.

Nestful is meant for such usage and excels at it. To illustrate this, let’s look at how I learned Japanese.

First, I had this language learning list:

That’s not very useful as “Japanese” is hardly an innocent, small task. Splitting was due.

I learn mostly through content consumption, but this item was strictly for the “chores” part of learning. Here’s how it looked after I divided Japanese into subtasks:

But reading 8 books is also not a very consumable task. So we nest deeper:

This is more like it. For me, the size of these items is not overwhelming. If you still find them too large, remember: any task you find overwhelming is splittable into smaller tasks. Even if you don’t know the books, you’ll have a task to find the books. And if you don’t know how to look for them, you’ll have a task to ask a friend or learn how to use Google.

Eventually, you are going to reach a small enough task.

But now we have a lot of small tasks, which can cause the exact same symptoms. This is where Spontaneuous Productivity comes in.

Creation Offload

If you’ve used Nestful before, you know that in addition to the regular views in the above screenshots (list, kanban, etc), there’s also a special one called agenda.

Agenda view has a special trick up its sleeve: it will “bubble up” due items, even if they are nested deep inside your task tree:

The above screenshots show part of my home page, set to the agenda display, showing the due item “JPDB”, even though that item is inside “Japanese”, which is in turn inside “Languages”.

This is the secret to not being overwhelmed by the quantity. The length of the list is only overwhelming if you have to deal with the entire list. That is because having to deal with a big list as a list, is basically the same as dealing with a large item.

What we did here is we offloaded the mental load to the list’s creation by dividing it into doable tasks and setting a due date where needed. This means that now, even if the list is huge (and mine is), you don’t have to care — just do the thing at the top.

Even if you suck at creating a good list (and you probably will, at the beginning), it’s still going to work just fine. Editing a list built with such intent is a breeze, mostly just moving things around when priorities change.

If you’re interested in learning more about this approach, read our essay on Spontaneous Productivity.

That’s it!

The best solutions are the simplest solutions, since those are the ones we are most likely to do.

Sometimes, though, there aren’t simple solutions, so just split the problem.

If you found it useful, please consider supporting by giving Nestful a try and sharing this essay.

This post tells the story of why I wanted to leave TypeScript behind, and why I chose Gleam to replace it.

A Need Rises

Nestful is a list-taking app with the promise to consolidate all of the different things competing for its users’ time. Those things (work, chores, musings, etc) would usually be stored in siloes —GitHub for personal projects, Trello for house chores, notes on life in a notes app, and so on. That’s great for prioritizing within a project, but how do you prioritize the projects themselves?

Nestful was born to solve this problem for me. The premise is simple: Nestful is a list of items, and items can be inside other items. That way I could have a list of my projects, prioritize them, and when it’s time to prioritize the project itself, I click the project’s item and inside there’s its own specific items, relating to its completion.

These were my main requirements from Nestful:

1. Work completely offline, with composable sync (more on that later)

2. Fast iteration so I could dogfood it quickly

3. Work on all my devices

Web it was.

I chose Vue + TypeScript because I was the most fluent with it, but it could easily have been any other client-side web technology and this post would have stayed mostly the same.

TypeScript Frustrations

As with every clean-slate project, the beginning was a breeze. I got started relatively quickly, but as I progressed and Nestful grew, problems started popping up.

A Language Within a Language

The types part of TypeScript is a language in and of itself. First you program the actual business logic, then you have to spend 10% of the time that took to wrangle types to be correct. The worst part of it?

When you’re done, you still don’t have confidence that it’s correct.

I did not delve deep enough into the typing system of TypeScript to know if it’s psychological. Maybe it is mathematically proven that once TypeScript compiles without any `any`s, it’s safe.

Maybe. I don’t care.

The way I see it, a language has to justify a learning curve. Learning to navigate Rust’s convoluted (at times) syntax is rewarded by very impressive compile time guarantees.

What does TypeScript give you that is worth the time it demands, in learning and maintenance?

Inherited Difficulties

Those problems with TypeScript are inherited and compounded when using a library. I used to spend 2-3 days when upgrading the client-side database I used at the time because for some reason, may it be TypeScript itself or the library’s author investment, the type system did not supply enough guarantees.

This is compounded when there’s a bug in a 3rd party library, or that I need to understand the inner-workings of one. I have become fairly adept in understanding other people’s code, especially in TypeScript, yet it is still more intensive of a task compared to a nicer, simple language like Gleam.

Error Handling

After Rust exposed me to the concept of errors as values, I could not go back. It was so much more ergonomic and resulted in such a better end product that I started sorely missing it. Although this is a Javascript problem first and foremost, its supersets can solve it, and some did try.

There are several attempts to make “Functional TypeScript”, but I did not like them. First, there was no nice solution to handle those returned errors, with the glaring lack of pattern matching. More than that, though — eventually, when the kitchen sink is full enough, the tools are too suffocated to be useful.

TypeScript is No Fun

Anything I do should be as enjoyable as possible, and when it comes down to it, TypeScript is just not fun.

Some things are just destined to suck, like the recent clearing up of a clogged sewer at the house. Programming Nestful is not one of them.

This is also important to its success as an application — as Nestful grew and will grow, refactors were and will be needed. Every TypeScript refactor resulted in more bugs. Gleam refactors resulted in less. More on that below.

“Compiled to WASM”

I am a relatively thorough person. As I got more frustrated with the stack I had, I began going one by one over the possible alternatives. There’s a lovely repository on GitHub tracking languages that compile to WebAssembly, so I started looking at each, one by one.

They all had one problem in common, though. Although WASM runs in the browser, it will demand a practically complete rewrite of Nestful, due to interoperability issues that will inevitably arise.

The solution is then to strictly compile to JavaScript.

I can’t remember which list I looked at at the time (maybe the one on the CoffeScript wiki?), but in the end I have narrowed it down to:

• Dart

• F#

• OCaml

Dart was easy to pass on, even though it’s one I already knew, and on paper — the most fitting replacement — especially when adding a lot of the functional-style features I was looking for. However, it suffers from the crowded kitchen sink problem, and… Google makes it. I like using Flutter a fair bit, but I would rather split my eggs over multiple baskets, thank you very much.

F# and OCaml were pretty close. F# looked more approachable to me, but the ecosystem was fairly slow going, and I don’t paticularly enjoy working with Microsoft tools. OCaml seems to be back on track, and used in some major production codebases, but the syntax was not as familiar to me, and I got mixed signals about the rejuvenation they claim they have.

I have a soft-rule that says that in every new project I start, I must learn something new to the extent my bandwidth allows. Even though I decided not to go with either F# or OCaml this time, I’ll be happy if they turn out to be a good fit in a future project.

Then Gleam hit 1.0, which I discovered when YouTube recommended me a Primeagen video. Before, I probably skimmed over Gleam and passed for it being too young. Having it reach stability with the community momentum to compensate for being young relaxed my ecosystem worries (a little), and I took it for a spin.

Star of the Show

Gleam has quickly turned out to be an excellent choice made at the right time. It streamlined my development even though I had to write a lot of (FFI) boilerplate to get going.

As Simple as it Gets

Gleam has a simple-language philosophy. This means that the language itself is fairly small and contained (there’s no `if`!), which in turn makes it very easy to learn, and most importantly, extremely easy to understand 3rd party code.

Even with a language this young and some things that are not fully ready, I had a much better time than doing the same task with TypeScript.

Easy Refactor

As Nestful grows refactors are going to be needed. “Composable sync”, mentioned in the requirements, is an example of that.

If Nestful promises to be a place that hosts all the different things competing for my time, it better do that for things that need more than a list to be managed. Some projects do need the likes of Linear or GitHub, and I would like to be able to pull items from there and transparently display them to the user to be prioritized. They don’t need all of GitHub’s features to prioritize between fixing bug #233 and putting the car in the garage. When they actually reach fixing that bug they can click the item and Nestful will lead them right to GitHub.

The data layer is abstracted enough to achieve this, but you don’t really know what you need until you need it, especially if you avoid premature optimization like I do.

I am confident with Gleam having my back when it’s time to modify the data layer, helping me refactor correctly, even when it’s tricky. For example, Nestful has a feature that “bubbles up” items. It’s currently only used to show use deeply-nested due items in a single view (to prioritize between "bug #233 somewhere inside a project and “Put car in garage” somewhere inside house chores). Expanding this to more use cases is not trivial, and Gleam is here to help.

Fluffy and Cozy

Gleam is fun to write in. It’s a calming language if there ever was one. It’s soft to read and write (you’ll get it when you try it) and is overall a relaxing experience. That’s mostly thanks to its syntax choices.

Beyond that, it supplies the usual functional/immutable features you’d expect from a first release of such a language. Namely, to my liking, no nulls, errors as values, and pattern matching.

Enter Vleam

The cherry on the top is that I could adopt Gleam incrementally. I could add it piece by piece, replacing the TypeScript in my services, composables, and components. For that last one to be easy, I wrote Vleam.

Vleam is a set of tools (Vite plugin, Vue FFI, and LSP) that allows the usage of Gleam in Vue single-file components with full LSP and hot-reload support. Give it a try if you’re looking for a change and running Vue yourself. Easily done one component at a time.

Not Perfect Yet, But Overall Right

Gleam doesn’t have everything nailed quite yet. Some LSP features are sorely lacking (it’s rename for me), and the language could use a bit of introspection and reflection so I could avoid a neverending unwrapping of types and the chore of serialization.

Even with those rough spots, though, Gleam is still a great choice. It’s a breath of fresh air over the chore that is TypeScript, and is making big strides with every release.

Next, I’ll give it a shot on the backend.

Recently a software I make called Nestful had its desktop app released, and while I made it for a whole different reason, I use it a lot for outlining screenplays.

Nestful and Kishoutenketsu

Nestful was initially built to fill one purpose: be a task app that lets me compare tasks across different areas of my life. My daily job, my screenplays and my chores all compete for my time, yet are all siloed away, unable to be prioritized. Nestful solves this by nesting items in one another, allowing projects to be item of the same list, and inside have their own list to manage said project.

This turned out to be extremely useful for outlining, especially the Japanese-style structure of Kishoutenketsu, which is often used for Anime.

For those who are unfamiliar with Kishoutenketsu, it's a 4-act structure popular in Asia which originated in Japan, and is comprised of 4 acts. In Japanese they are called:

• 起 Ki - Introduction

• 承 Shou - Development

• 転 Ten - Turn (often translated as twist, but isn't necessarily a twist in the western sense)

• 結 Ketsu - Resolution

Kishoutenketsu is fairly flexible, with writers taking big liberties in the lengths of acts. The Promised Neverland employes a fairly common and clear division of 1/8, 1/2, 1/4, 1/8 for each of the acts respectively.

Outlining The Promised Neverland

I'll link below some videos about the structure if you want to learn more, but for now -- let's use The Promised Neverland's outline as an example:

First, in Ki, we are getting literally introduced -- to the characters, and to their environment. This is pure exposition, and is done by contrasting the unknown (numbers, gate) with the known (the children are happy),

This expands in Shou, where we're shown the abilities and faults of every major character as part of tests, and play. Note that almost every sequence serves more than one duty. The tests show not only who are the smartest characters, but also foreshadow the importance of their intelligence to the institution they're in. I've used the Japanese name for the game on tag, Onigokko, because its literal translation is "demon pretend", the one who's "it" pretends to be a demon. Shou then transitions brilliantly into Conny's leaving, where we have more character reveal and more environment contrast.

Ten starts with Conny's forgotten stuffed bunny. Emma and Norman run after her with it, reach the forbidden gate from the cold open, and cross it. They explore the very different environment, and find dead Conny. They then hide from what they soon find out are actual demons, and we get the twist -- their raised in a farm as food food. In this case the twist is truly a twist as we know it in the west, but it doesn't have to be -- in fact, it's not sufficient. What's needed is a turn in the story. In this case, the twist changed the perspective. But it can be, for example, a significant turn of events that changes goals without revealing information, as in some of Miyazaki's films.

Ketsu is very straightforward, showing the characters dealing with the shock, and planning for the future -- tying in what they went through in the episode.

Nesting Kishoutenketsu

So far you may think that although Kishoutenketsu may be interesting, outlining it is no different than any other index card outline, and all I have in that screenshot is a digital version of that.

You would be right, until we click on an item in that outline. Here’s how it looks when we click “Ten”:

Everything in Nestful is an Item, and items can be put inside of other items. This is useful to us because Kishoutenketsu is highly fractal. The structure is nested in itself, and the Ten act is the perfect example for that, with an item in the list for each of the sub-acts: Ki, Shou, Ten, Ketsu.

Now we can change Ten to be a board as well, rename the items, and outline the inner-acts in the exact same way. This is how it looks:

Flexibility and Beyond

This nesting method is flexible in two ways.

The first is its useful to other structures, or even no structure. Eventually a screenplay is big parts composed of smaller parts, which are themselves composed of yet smaller parts. This is independent of any structure, and you can mix and match different structures and layouts inside of others.

The second is that it only takes a list to do, so it can be done in a variety of tools. I find Nestful to be the most ergonomic one, but there are many other apps that have at least some nesting capability, even if not as central as Nestful's.

I hope this was useful to you! Before I add the Kishoutenketsu videos I promised, did you maybe notice this post itself has a certain structure? Maybe even this very paragraph?

Anyway, here they are:

Scheduling Sucks

Before we get into the solution, we must understand the problem: scheduling. That is because scheduling, and prepare to be shocked, takes time.

Scheduling is spending time in order to then spend time later. Supposedly in a more efficient manner, but that is impossible. Just ask any software development team and they'll tell you the unavoidable truth: humans are bad at estimating future work.

This means you often have to spend more time fixing mistakes and accommodating for changes in the schedule you came up with to efficiently spend your time.

Note, that's before you even touch the thing you actually want to do.

Solution Part I: The What

To avoid this sort of meta-timespending, Spontaneous Productivity defines a clear goal: decide what to do only just before you do it.

To achieve said goal, we need an evergreen list of priorities. A list in which tasks are always positioned according to their urgency. With that kind of list, instead of having a varied calendar with time-set activities spread across, you're going to have something like this:

The purple-blue events are all the activities that depend on other people, other resources or only available at certain times (also called "deps"), and are scheduled are usual. The rest is Spontaneous Productivity time.

Whenever you reach SP time, you open your evergreen priorities list, and do the top item. No planning, no worrying, no rescheduling. Spontaneous.

Solution Part II: The How

Obviously, we can't use any random list to achieve this. We have to have some sort of method to build a list that's ordered by priorities and, more importantly, that is evergreen -- meaning, it stays ordered.

Now I have good news, and bad news. I'll start with the bad.

The bad news is there's no way to create such a list. The good news is we can get pretty damn close.

We need 3 things to make this list happen:

1. Offload urgency indicators to task creation

2. Automatically order list according to urgency indicators

3. Be able to update said indicators

An urgency indicator is a piece of information, related to a task, that can be compared with equivalent pieces of information in other tasks. The best example is a due date. We can compare the due date of different task to see which one has less time remaining for completion.

There are many possible other indicators. For example, task completion percentage. A task that is mostly done is less important than one you haven't even started. Or maybe a consequences indicator can represent the cost of failing the task's completion. Not watching a movie you planned to is not as bad as missing an important job deadline. Especially if that job finances that movie streaming account.

Once we have a list of tasks with corresponding indicators we can order those tasks, and update that order as we update the tasks themselves. The way we sort that list depends on our own preferences, so no magic formula exists. However, here come the even better news.

Solution Part III: The Tool

Nestful is the first tool to implement the principle behind Spontaneous Productivity. While you can post-it your way through it, sooner or later it's going to get too complicated and slow to do. Thankfully, we have computers.

Nestful includes a set of useful features exactly for this. For example, Agenda view "bubbles up" all due sub-tasks so you won't miss anything, and arranges everything according to date. This is the due date indicator mentioned before.

The general nestability of tasks allows you to basically make each task its own full-blown kanban board, if you have more complex things to manage. This is with the strict principle of keeping one single list, even if you have very complex tasks.

Of course, there is much room to grow. From better repeatability options, to crazy things like bundling together tasks that happen in the same place, or using similar resources. I personally believe in the beauty of simplicity, so expect to see more things like the Agenda view mentioned above. A huge portion of the benefits hides among the simplest of solutions.

I hope you give Spontaneous Productivity, and in turn Nestful, a shot. If you don't like the latter, that's fine -- each has its own take. As for the former -- unless 90% of your day is meeting other people, you can make Spontaneous Productivity work. When you do, tell us how you did it so we can learn and improve our own approaches.

Please reach out with anything to contact@nestful.app