Tools

• JavaScript Package Managers: NPM, Yarn, PNPM, and Bun Compared

  If you’ve been writing JavaScript for any length of time, you’ve probably had opinions about package managers. Everyone has used npm because it’s the default. Maybe you switched to Yarn back in 2016 and haven’t looked back. These days, there are better options.

  That may seem like a bold statement, but bear with me. This article is a mix of opinions and facts. The package manager landscape has changed quite a bit in the last decade, and it’s worth exploring. Let’s break it down.

  NPM: The Default Everyone Knows

  npm is the package manager that ships with Node. It works. Everyone knows it. Node modules are straightforward to reason about, and security has been improving over the years.

  But npm has historically struggled with performance. That’s partly a design problem, it was so widely adopted that making fundamental speed improvements meant risking breakage for the massive ecosystem already depending on it. When you’re supporting millions of packages, you need to be careful in managing backward compatibility breaks, making optimization a lot harder.

  This performance gap is exactly what opened the door for alternatives.

  Yarn: The Pioneer That Over-Optimized

  Yarn showed up in 2016, created by Facebook, and it genuinely pushed the ecosystem forward. It parallelized downloads, introduced offline caching, and most notably, introduced lock files to JavaScript. npm eventually adopted lock files too, so Yarn’s influence on the broader ecosystem is undeniable.

  Lock files did exist for other languages before 2016, such as Ruby and PHP, but Yarn was the first JavaScript package manager to include it.

  The problem came with Yarn 2. It’s a classic case of over-optimization.

  Yarn 2 introduced Plug’n’Play mode, which replaces your node_modules folder with zip files. We’re on Yarn 4 now, and while you can swap between modes, if you’re in the zip mode it becomes genuinely painful to inspect the actual JavaScript code you’re installing. You have to unzip things, dig through archives, and it just adds friction where there shouldn’t be any.

  If you enjoy making JavaScript development harder than it needs to be, Yarn’s PnP mode has you covered. It’s your Toxic coworkers favorite tool.

  PNPM: The Clear Upgrade

  If you look at the benchmarks, pnpm wins in almost every common scenario. Running install with a warm cache, lock file, and existing node modules? Faster than npm. A clean install with nothing cached? 7 seconds versus 30 seconds. That’s not a marginal improvement.

  Speed isn’t even the best part. pnpm uses hard links from a centralized store instead of copying packages into every project’s node_modules. Depending on the size of your projects, you can save up to 70% of your disk space compared to npm. If you’re working on multiple JavaScript projects (and who isn’t?), that adds up fast.

  pnpm also handles the node_modules structure in a way that’s strict by default, which means your code can’t accidentally import packages you haven’t explicitly declared as dependencies. It catches bugs that npm would let slide.

  So pnpm is the clear winner, right? Well, there’s one more contender we haven’t talked about yet.

  Bun: The Speed Demon

  Bun was released in 2023, and noticeably faster than pnpm.

  The reason comes down to architecture. pnpm is written in TypeScript and runs on Node, which means every time you run pnpm install, your computer has to start the V8 engine, load all the JavaScript, compile it, and then ask the operating system to do the actual work. That’s a lot of overhead.

  Bun is a compiled binary written in Zig. It talks directly to your kernel, no middleman, no V8 engine slowing down every tiny decision. On top of that, Bun is hyper-focused on optimizing system calls. Instead of doing file operations one at a time (open file A, write file A, close file A, repeat a thousand times), it aggressively batches them together. The result is speed improvements not just in disk operations but in everything it does.

  Earlier versions of Bun had an annoying quirk similar to Yarn, it used a binary lock file that was difficult to manually audit. That’s been fixed. Bun now uses a readable lock file, which removes the biggest objection people had.

  Which begs the question… ?

  So Why Isn’t Everyone Using Bun?

  The short answer: it’s complicated. Bun isn’t just a package manager, it also replaces Node as your runtime. If you’re using Bun as your runtime, using it as your package manager makes total sense. Everything fits together.

  But most teams are still on Node. And when you’re on Node, pnpm is the clearer choice for everyone involved. A new developer joining your team sees pnpm and immediately knows, “Oh, this is a JavaScript project, I know how this works.” Bun as a package manager on top of Node adds a layer of “wait, why are we using this?” that you have to explain.

  Maybe that changes in the future as Bun’s runtime adoption grows. I’m sure the Bun team is working hard to make that transition as smooth as possible. But the reality right now is that most JavaScript projects are running on Node.

  My Recommendation

  If you’re starting a new project or looking to switch:

  • Using Bun as your runtime? Use Bun for package management too. It’s the fastest option and everything integrates cleanly.
  • On Node (most of us)? Use pnpm. It’s faster than npm, saves disk space, and is strict in ways that catch real bugs. Your team will thank you.
  • Still on npm? You’re not doing anything wrong, but you’re leaving performance and disk space on the table for no real benefit.
  • On Yarn PnP? I have questions, but I respect your commitment.

  The JavaScript ecosystem moves fast, and if you haven’t revisited your package manager choice in a while, it might be worth running a quick benchmark on your own project. The numbers might surprise you.

  Feb 18, 2026 / Tools / Development / javascript

  Enjoyed this?

• Switching to mise for Local Dev Tool Management

  I’ve been making some changes to how I configure my local development environment, and I wanted to share what I’ve decided on.

  Let me introduce to you, mise (pronounced “meez”), a tool for managing your programming language versions.

  Why Not Just Use Homebrew?

  Homebrew is great for installing most things, but I don’t like using it for programming language version management. It is too brittle. How many times has brew upgrade decided to switch your Python or Node version on you, breaking projects in the process? Too many, in my experience.

  mise solves this elegantly. It doesn’t replace Homebrew entirely, you’ll still use that for general stuff but for managing your system programming language versions, mise is the perfect tool.

  mise the Great, mise the Mighty

  mise has all the features you’d expect from a version manager, plus some nice extras:

  Shims support: If you want shims in your bash or zsh, mise has you covered. You’ll need to update your RC file to get them working, but once you do, you’re off to the races.

  Per-project configuration: mise can work at the application directory level. You set up a mise.toml file that defines its behavior for that specific project.

  Environment management: You can set up environment variables directly in the toml file, auto-configure your package manager, and even have it auto-create a virtual environment.

  It can also load environment variables from a separate file if you’d rather not put them in the toml (which you probably want if you’re checking the file in).

  It’s not a package manager: This is important. You still need poetry or uv for Python package management. As a reminder: don’t ever use pip. Just don’t.

  A Quick Example

  Here’s what a .mise.toml file looks like for a Python project:

  [tools]
  python = "3.12.1"
  "aqua:astral-sh/uv" = "latest"
  
  [env]
  # uv respects this for venv location
  UV_PROJECT_ENVIRONMENT = ".venv"
  
  _.python.venv = { path = ".venv", create = true }
  

  Pretty clean, right? This tells mise to use Python 3.12.1, install the latest version of uv, and automatically create a virtual environment in .venv.

  Note on Poetry Support

  I had to install python from source using mise to get poetry working. You will want to leave this setting to be true. There is some problem with the precompiled binaries they are using.

  You can install global python packages, like poetry, with the following command:

  mise use --global poetry@latest
  

  Yes, It’s Written in Rust

  The programming veterans among you may have noticed the toml configuration format and thought, “Ah, must be a Rust project.” And you’d be right. mise is written in Rust, which means it’s fast! The project is stable, has a ton of GitHub stars, and is actively maintained.

  Task Runner Built-In

  One feature I wasn’t expecting: mise has a built-in task runner. You can define tasks right in your mise.toml:

  [tasks."venv:info"]
  description = "Show Poetry virtualenv info"
  run = "poetry env info"
  
  [tasks.test]
  description = "Run tests"
  run = "poetry run pytest"
  

  Then run them with mise run test or mise r venv:info.

  If you’ve been putting off setting up Make for a project, this is a compelling alternative. The syntax is cleaner and you get descriptions for free

  I’ll probably keep using Just for more complex build and release workflows, but for simple project tasks, mise handles it nicely. One less tool to install.

  My Experience So Far

  I literally just switched everything over today, and it was a smooth process. No too major so far. I’ll report back if anything breaks, but the migration from my previous setup was straightforward.

  Now, I need to get the other languages I use, like Go, Rust, and PHP setup and moved to mise. Having everything consolidated into one tool is going to be so nice.

  If you’re tired of Homebrew breaking your language versions or juggling multiple version managers for different languages, give mise a try.

  The documentation is solid, and the learning curve is minimal.

  Feb 11, 2026 / DevOps / Tools / Development / Python

  Enjoyed this?

• 2026: The Year We Stop Blaming the Tools

  Here’s a hard truth we’re going to have to face in 2026: sometimes the bottleneck isn’t the technology, it’s us.

  I’ve been thinking about how we use tools, how we find the merit in their use. We have access to increasingly powerful tools, but their value depends entirely on our understanding of them.

  A hammer is useless if you don’t know which end to hold. The same goes for AI assistants, automation frameworks, and the growing ecosystem of agentic systems.

  The rapid adoption of tools like OpenClaw’s agentic assistant tells me something important: people and companies are starting to see the real potential in building autonomous systems. Not just as toys or experiments, but as genuine productivity multipliers. That’s a shift from where we were even a year ago.

  I think 2026 will be the year we see more widespread adoption of genuinely useful tools. The Gartner hype cycle is really interesting and how it applies or doesn’t to AI adoption, but I won’t cover it here. I’d like to write more about that in future articles.

  The companies that build genuinely useful tools will be the ones that survive. They’ll be the ones that understand the value of tools and how to use them effectively. They’ll be the ones that embrace the future of work, where humans and machines work together to achieve more.

  It’s not about replacing humans. It’s about humans getting better at wielding the tools we’ve built. That’s always been how technology works. This time is no different.

  Feb 1, 2026 / AI / Tools / automation / 2026

  Enjoyed this?

• The Rise of Spec-Driven Development: A Guide to Building with AI

  Spec-driven development isn’t new. It has its own Wikipedia page and has been around longer than you might realize.

  With the explosion of AI coding assistants, this approach has found new life and we now have a growing ecosystem of tools to support it.

  The core idea is simple: instead of telling an AI “hey, build me a thing that does the boops and the beeps” then hoping it reads your mind, you front-load the thinking.

  It’s kinda obvious, with it being in the name, but in case you are wondering, here is how it works.

  The Spec-Driven Workflow

  Here’s how it typically works:

  1. Specify: Start with requirements. What do you want? How should it behave? What are the constraints?

  2. Plan: Map out the technical approach. What’s the architecture? What “stack” will you use?

  3. Task: Break the plan into atomic, actionable pieces. Create a dependency tree—this must happen before that. Define the order of operations. This is often done by the tool.

  4. Implement: You work with whatever tool to build the software from your task list. The human is (or should be) responsible for deciding when a task is completed.

  You are still a part of the process. It’s up to you to make the decisions at the beginning. It’s up to you to define the approach. And it’s up to you to decide you’re done.

  So how do you get started?

  The Tool Landscape

  The problem we have now is there is not a unified standard. The tool makers are busy building the moats to take time to agree.

  Standalone Frameworks:

  • Spec-Kit - GitHub’s own toolkit that makes “specifications executable.” It supports multiple AI agents through slash commands and emphasizes intent-driven development.

  • BMAD Method - Positions AI agents as “expert collaborators” rather than autonomous workers. Includes 21+ specialized agents for different roles like product management and architecture.

  • GSD (Get Shit Done) - A lightweight system that solves “context rot” by giving each task a fresh context window. Designed for Claude Code and similar tools.

  • OpenSpec - Adds a spec layer where humans and AI agree on requirements before coding. Each feature gets its own folder with proposals, specs, designs, and task lists.

  • Autospec - A CLI tool that outputs YAML instead of markdown, enabling programmatic validation between stages. Claims up to 80% reduction in API costs through session isolation.

  Built Into Your IDE:

  The major AI coding tools have adopted this pattern too:

  • Kiro - Amazon’s new IDE with native spec support
  • Cursor - Has a dedicated plan mode
  • Claude Code - Plan mode for safe code analysis
  • VSCode Copilot - Chat planning features
  • OpenCode - Multiple modes including planning
  • JetBrains Junie - JetBrains' AI assistant
  • Google Antigravity - Implementation planning docs
  • Gemini Conductor - Orchestration for Gemini CLI

  Memory Tools

  • Beads - Use it to manage your tasks. Works very well with your Agents in Claude Code.

  Why This Matters

  When first getting started building with AI, you might dive right in and be like “go build thing”. You keep then just iterating on a task until it falls apart once you try to do anything substantial.

  You end up playing a game of whack-a-mole, where you fix one thing and you break another. This probably sounds familiar to a lot of you from the olden times of 2 years ago when us puny humans did all the work. The point being, even the robots make mistakes.

  Another thing that you come to realize is it’s not a mind reader. It’s a prediction engine. So be predictable.

  What did we learn? With spec-driven development, you’re in charge. You are the architect. You decide. The AI just handles the details, the execution, but the AI needs structure, and so these are the method(s) to how we provide it.

  Jan 31, 2026 / AI / Programming / Tools / Development

  Enjoyed this?

• Everyone crashing out over OpenCode situation. Why not just use Claude Code (2.1+)? Or you know, there’s AMP. AMP exists too, and it looks equally interesting to me.

  Jan 19, 2026 / AI / Tools / Development

• Claude Code has been working great for me. OpenCode looks interesting, but uh, Opus 4.5 access is necessary for real work. I’m not doing any sketchy workarounds to get it running, and API pricing isn’t appealing either. So for now, OpenCode stays firmly in the “interesting” category.

  Jan 19, 2026 / AI / Tools

• Claude Cowork: First Impressions (From the Sidelines)

  Claude Cowork released this week, and the concept seems genuinely useful. I think a lot of people are going to love it once they get their hands on it.

  Unfortunately, I haven’t been able to get it working yet. Something’s off with my local environment, and I’m not entirely sure what. Claude Desktop sometimes throws up a warning asking if I want to download Node and I usually say no, but this time I said yes. Whether that’s related to my issues, I honestly don’t know. I did submit a bug report though, so hopefully that helps.

  Here’s the thing that really impresses me: Anthropic noticed a trend and shipped a major beta feature in about 10 days.

  That’s remarkable turnaround for something this substantial. Even if it’s not working perfectly for everyone yet (hi, that’s me), seeing that kind of responsiveness from a company is genuinely exciting.

  I’m confident they’ll get it sorted before it leaves beta. These things take time, and beta means beta.

  I have explored using the CLI agents outside of pure coding workflows and so I think there’s a lot more flexibility there than you might expect.

  For now, I’m watching from the sidelines, waiting for my environment issues to sort themselves out.

  Jan 17, 2026 / AI / Tools / Claude

  Enjoyed this?

• OpenCode | The open source AI coding agent

  OpenCode - The open source coding agent.

  Jan 16, 2026 / AI / Programming / Tools / links / agent / open source / code

• Amp

  Amp is a frontier coding agent that lets you wield the full power of leading models.

  Jan 16, 2026 / AI / Programming / Tools / links / agent / automation / code

• Tinderbox: The Tool For Notes

  Jan 14, 2026 / Tools / links / notes / digital organization

• Why Airtable Killed Google Sheets for Me

  It’s 2026, you should probably stop using Google Sheets or Microsoft Excel for most things. What follows is my attempt at explaining why Airtable (and other similar products) are better.

  Data Integrity Actually Exists

  In Google Sheets, a cell can be anything. A string, a date, a number, whatever you accidentally paste into it. There’s no real way to enforce data types beyond formatting tricks or functions that break when someone inevitably ignores them.

  In Airtable, you define what a column is. It’s a date field. It’s a number. It’s a single select. And it stays that way. No more spreadsheets slowly devolving into data hellscapes where row 47 has a phone number stored as text and row 48 has it as a number.

  Relationships Without the Visual Basic Nightmare

  Want to connect data across multiple sheets in Google? Get ready to write formulas. You’re essentially writing code, Visual Basic or Apps Script, just to link your tables together.

  In Airtable, relationships are native. You click a few buttons, link two tables, and boom, you’ve got the equivalent of a SQL join without writing a single line of code. The data stays connected, and you can traverse those relationships naturally.

  Attachments That Don’t Suck

  Google Sheets handles attachments by letting you paste a link to a file somewhere else. Maybe it’s in Google Drive, maybe it’s on some random server. Either way, it’s just a URL sitting in a cell.

  Airtable lets you drag files directly into a cell. They get thumbnails. They’re actually attached to the record. Sure, on the backend it’s probably still stored in a bucket somewhere, but the interface abstracts all that away. It just feels like the file belongs there. Good file, that’s a good boy, go sit in your cell.

  Views That Make Sense

  In Sheets, you get a grid. Maybe you can set up a filter view if you know how. That’s about it. Airtable gives you options out of the box: grid view, Kanban board, calendar, gallery, timeline.

  You can look at the same data in completely different ways depending on what you’re trying to accomplish. Want to see your projects as cards on a board? Done. Want to see them as events on a calendar? Also done. No formulas, no hacks. Notion has entered the chat

  Automation Without Writing Production Code in a Spreadsheet

  This one really gets me. Want to automate something in Google Sheets? Time to open Apps Script and write JavaScript. I hope you’re comfortable debugging code that has no unit tests, no version control, and will silently break at 2 AM when you’re asleep.

  Airtable’s automation is point-and-click. Set a trigger, define actions, connect to integrations. It’s like Zapier or n8n built right into your database. When this field changes, send that notification. When a record is created, add it to another table. No code required.

  The Row Editing Experience

  This might seem minor, but it’s not. When you want to focus on a single row in Google Sheets—really dig into one record and edit multiple fields—you’re clicking into cells and scrolling horizontally to find column 30 while trying not to lose your place.

  Airtable has an expanded record view. Click on a row and it opens up vertically, showing you every field in a clean, organized layout. You can actually see what you’re editing. Nice.

  ---

  Look, Google Sheets isn’t going anywhere, and we should all probably be happy it still exists….. but yeah, the spreadsheet paradigm had a good run and it’s time to move on.

  For anything that resembles actual data management, where you need integrity, relationships, and a UI that doesn’t fight you, Airtable (or Notion, or similar tools) should be your first choice.

  What do you think? Have I missed anything?

  Jan 11, 2026 / Productivity / Tools / Airtable

  Enjoyed this?

• The Markdown Mode Manifesto

  Google Docs is for grandma. Markdown is for actual work.

  I know that sounds harsh, but hear me out.

  Developers love Markdown because it’s extremely portable. It’s just a text file with some agreed-upon formatting symbols.

  No proprietary binary format, no vendor lock-in, no mysterious corruption when you open it in a different app. If you want your writing to survive the digital apocalypse, Markdown is your best bet.

  This isn’t a post explaining what Markdown is, the point of this post is simpler:

  Google Docs sucks for anyone who wants real Markdown support, and I wish Google would actually fix this.

  Their current “Markdown support” is a joke. When Google Docs detects something that looks like a heading, it helpfully deletes your Markdown syntax and converts it to rich text. Thanks, I hate it.

  It’s basically impossible to write in Markdown in Google Docs because the app fights you every step of the way. The only real support they offer is exporting to Markdown format. That’s not what I want. I want to write in Markdown, not just export to it after the fact.

  In a real Markdown editor like Obsidian or 30 other options, you can toggle between source view and preview. You see the raw text with all its formatting symbols, then flip to see the rendered result.

  It’s clean, it’s simple, it works. In Google Docs? There’s no source view. It’s only rich text, forever and ever, amen. They built the whole thing to mimic Microsoft Word, and that’s all you get.

  I don’t need another Word clone. I’ve got, brought to you by Copilot Word, if I want Word.

  I would gladly sacrifice whatever bloated features necessary to get rid of all that stuff I don’t care about, as long as it has real Markdown support.

  What “Real Support” Would Look Like

  • A source/preview toggle (like literally every other Markdown editor)
  • Stop auto-converting my syntax into rich text formatting
  • Let me paste Markdown without it being “helpfully” transformed
  • Native .md file handling, not just export

  Is that so much to ask?

  All this is to say: we probably need a new product entirely. Google’s not going to rebuild Docs from the ground up, and Microsoft’s not going to make Word understand that some of us don’t want 47 ribbon tabs and a formatting pane that takes up half the screen.

  But, you know, whatever. I guess the best we get these days is another VS Code clone.

  If you’re a fellow Markdown Apostle stuck in a rich-text world, I feel your pain. Until then, I’ll be over here editing in Obsidian for some things and Cursor for others.

  Jan 10, 2026 / Writing / Tools / Markdown / Google-docs

  Enjoyed this?

• Cabina.AI: All-In-One AI assistant platform | Best AI chat workspace for you needs

  Free access to GPT-4 O1, Claude, LLama, Runway, Flux, Lumalabs, Stability, Gemini & more. Chat with PDF (RAG), analyze files, AI transcribe audio, generate video & images, AI Summarizer & In-Paint editor: all AI tools in one place. Generate AI content easy or compare LLMs in one chat or test & improve your prompts. Start free with Cabina.AI workspace now

  Jan 7, 2026 / AI / Tools / links / chat / platform

• Just discovered DB Pro, a new desktop app for SQLite and LibSQL databases. Looks pretty promising. Meanwhile, I’m still waiting for DataGrip to get proper LibSQL support. Come on JetBrains, just give me Turso already!

  Jan 6, 2026 / Sqlite / Databases / Tools

• Shadcn Studio - Shadcn UI Components, Blocks & Templates

  Accelerate your project development with ready-to-use, & customizable 1000+ Shadcn UI Components, Blocks, UI Kit, Boilerplate, Templates & Themes with AI Tools.

  Jan 6, 2026 / AI / Programming / Tools / links / library / UIkit