Forem: Slee Woo

Finally learned how to close Neovim. Still can't leave

Slee Woo — Fri, 01 May 2026 11:07:42 +0000

There's a famous joke: I've been using Vim for years because I don't know how to close it.

Now I finally learned how to close it.

But still can't leave.

A brief museum of editors I loved

Before Neovim there were others. There are always others.

Zend Studio, for the veterans who remember. The IDE that came with a PHP license and a sense of seriousness. It knew what a project was before "project" meant a folder with a package.json.

Eclipse, the cathedral next door - workspaces, perspectives, a plugin for every problem and three more for every solution. If you were coding in the 2000s, Eclipse wasn't your editor; it was your operating system.

RubyMine, when Ruby was the future and autocomplete that actually understood your models felt like a small miracle. JetBrains in general - heavy, opinionated, smarter than you, willing to tell you so.

Sublime. The editor that taught a generation of us that startup time is a feature. Command-P was a religious experience in 2013.

Then the Electron wave. Atom first, then VS Code. Suddenly your editor was a browser, your browser was an editor, and somehow we all just accepted that 400MB of RAM was fine for typing.

I used all of them. I liked all of them. I was, briefly, each of those people.

Wonder how things would've gone if Zed had been around in 2015.

The plugins, sharpened over years

Here's what nobody tells you about a decade in one editor: you don't accumulate plugins, you accumulate positions. A plugin isn't a feature you installed, it's a decision you made about how you want to work, frozen into a line of config.

Every keymap is a small vote you cast against your past self.

Every leader-key combination is a sentence you taught your hands to speak.

Ten years of that and the editor stops being software. It becomes a dialect.

People quote that line - perfection is achieved not when there is nothing more to add, but when there is nothing left to take away. And the older I get, the more I think the real version is even quieter: an ideal tool is one where there is nothing left to drop. Everything that's still there earned its way back, after you tried to remove it and missed it.

My Neovim config is like that now. Not because I designed it. Because time did.

Five attempts

I tried to switch to Zed about five times in the last year.

Zed is genuinely great. Fast in the way Sublime was fast, but with the modern stack underneath. And the v1 release, with the agents finally something you can switch off and ignore - that removed the last excuse I had.

Every time I opened it, wanted the switch to work.

Every time, after a few hours, I was back in Neovim. Not because Zed did anything wrong. Because my hands kept reaching for things that weren't there in the same shape, and the small constant friction of that translation just... wore me down.

One attempt is curiosity. Five is something else. Five means some part of me keeps pulling me back, and I can't quite negotiate with it.

Vim-mode is not Vim

Yes, Zed has a vim mode. Yes, it's technically excellent. The keybindings work. The motions are there. On paper it's a perfect bridge.

Emotionally it's a different room.

It's the difference between speaking a language and being translated into it. The surface matches. The underneath doesn't. You can feel the seam, even when you can't point at it.

The part I can't transfer

Here's the sad part - and I don't even know if "sad" is the right word, I still can't quite name this feeling.

None of this transfers.

Ten years of muscle memory, ten years of config decisions, ten years of "oh I fixed that annoyance in 2019 and forgot it was ever annoying" - there's no export button for that. You can't git clone a decade of embodiment into a new editor.

And that's what it is, really. The editor isn't an application I use anymore, it's a prism I think through. Switching isn't learning a new tool, it's relearning the angle at which my thoughts come out.

It's not age. I don't think it's age. A kid who's been deep in one editor for three years has the same thing in miniature. It's just what happens when a tool stops being external.

So

I still use Neovim.

Zed is on my machine. I open it sometimes. I'll probably try again - a sixth attempt, a seventh.

Both editors are great. That part I'm sure of. The rest of it, the why-can't-I-just-switch part, I'm still sitting with.

If you've felt this about any tool - an editor, a shell, a keyboard layout, a language you can't quite leave - I'd love to hear it. I suspect this isn't really a Neovim post. I suspect it's a post about how the things we use long enough start using us back.

And not sure that's really a problem.

In the AI Agents Era, Why Waste Time Building a Framework?

Slee Woo — Wed, 11 Mar 2026 14:44:40 +0000

There is no answer to that question. Because the question is about the result - a pragmatically calculated, measurable, expected result.

But building is about the process.

It's about that zen. That quiet delight when you finally solve something that's been annoying you for years. Maybe it annoys only you. Maybe you're solving a problem that doesn't exist for anyone else. But now it's solved, and you get your couple minutes of glory.

Now you can ditch all those validation libs - each with its own syntax, its own limitations - and just write TypeScript that gets validated at runtime:

export default defineRoute(({ POST }) => [
  POST<{
    json: {
      email: TRefine<string, { format: "email" }>;
      age: TRefine<number, { minimum: 18 }>;
    }
  }>(async (ctx) => {
    const { email, age } = ctx.validated.json;
    // validated before reaching here - no lib syntax, just TypeScript
  }),
]);

And the breeze seems here to stay. But no - another annoyance starts to rise from the depths.

After your 100th route, looking at a file-based routing tree is like a nightmare.
What are all these files? They belong to what? Which is the master (handler), which is the servant (helper)?

And the answer comes in the form of a question: why not organize routes as directories, with a handler file inside? Wait, but that's a lot of folders!

Ok, let's sketch how it would look compared to the actual mess...

Ten minutes later: holy structure. What the order!

api/
  users/
    [id]/
      index.ts      ← handler for /api/users/:id
      helpers.ts    ← clearly not a route

A couple of weekends of spare time later: another annoyance is behind. Another minute of glory.

So, is the breeze here forever? For a couple of hours perhaps, but...

Why the heck are routes limited to monolithic segments like posts/:id?
How do you cover simple paths like posts.json or posts/1.json in a single route?
Should you create a separate route for each? That's crazy!

Time for a new zen. Turns out path-to-regexp v8 is finally state-of-the-art in routing - so flexible, so delightful to integrate. And here it is, the new Power Syntax for routes:

book{-:id}-info           ➜ /book-info or /book-123-info
locale{-:lang{-:country}} ➜ /locale, /locale-en, /locale-en-US
api/{v:version}/users     ➜ /api/users or /api/v2/users

So far so good.

Now, finally, a comfortable weekend! Or not?
Wait - forgot to wire auth middleware into the latest routes.
A couple of Neovim strokes and we're good.

A couple of Neovim strokes later: wait, how could I forget about auth middleware, it's essential!
And how is it that in the 21st century you still have to manually wire middleware into each route?
That's nonsense, that's anti-progress!

One wasted weekend later: who said stylesheets can be cascading but middleware cannot?
It's that easy - create a use.ts in any folder and all underlying routes automatically wire the exported middleware. No imports. No repetition.

api/
  admin/
    use.ts          ← auth runs for every route under /admin
    users/
      index.ts      ← inherits automatically
      [id]/
        index.ts    ← inherits automatically

No more wasted weekends because someone forgot to wire something.
Now they'll be wasted for far more reasonable reasons.

And one more annoyance has been harming the breeze for years.
Whatever tricks or hacks tried to get a clean, type-safe, validated round-trip from client to server - none fully satisfies.

Then a perfectly legal question hits: once there are typed validation targets on the server, why not use them to generate typed clients? Wait, even better - TypeBox runs perfectly in the browser, so why not use the same validation routines on the client?

import fetchClients from "_/front/fetch";

// fully typed, validated client-side before the request is even sent
const user = await fetchClients["users/[id]"].GET([123]);

A couple of weekends later: so productive now with type-safe, client-side validated fetch clients!

Time for some rest, finally. Wait - a customer asks for an OpenAPI spec for their API.
Ok, let's quickly wrap a script that gets all routes and generates the spec...

Multiple "quickly wrap a script" iterations later: how can such a simple task need so much manual work?
No way, there has to be an automated solution. And another zen is on the road - taking the AST-parsed routes with their params, payloads, and responses, and gluing them together into an automated OpenAPI 3.1 spec generator.

And that zen doesn't come alone. It's accompanied by the sincere wow of customers who discover they got detailed OpenAPI for free.

And that's pretty much a lot - much more than any pragmatically calculated result expected from an apparently pointless effort.

Because the real result is the sum of all those micro-achievements that push you forward.

And no - the breeze isn't supposed to arrive once and stay forever.
It lives in the movement, not the stillness.