Replacing a 15MB Calendar Dependency With 76KB of Our Own

There's a specific kind of developer pain that comes from working with a third-party UI library that costs money, fights you on every style change, and somehow weighs more than your entire app's feature code combined. For us, that library was Bryntum Calendar. And after months of quietly suffering, we finally ripped it out.

Here's how we did it - and why the messiest tool in my toolkit ended up being the most useful.

The Vue Calendar Ecosystem Is Rough

Before I get into Bryntum specifically, I need to set the scene - because the whole situation only makes sense with that context.

If you're building a React app and need a full-featured calendar, you have real options. FullCalendar has solid React support. The path exists. In Vue - and especially Nuxt - the landscape is genuinely rough. You start googling and pretty quickly you're looking at libraries with last commits from 2021, wrappers around jQuery plugins, or things that technically have a Vue adapter but clearly weren't designed with Vue in mind. TypeScript support that ranges from "grudging" to "why did they even ship types." APIs that feel like they were designed by someone who hated documentation. Event handling that requires understanding three layers of abstraction before you can do anything useful.

So when we landed on Bryntum, it wasn't naive - it was "this is one of the few things that actually works." Except then it doesn't, kind of.

Bryntum is full-featured, no question. Recurring events, drag-and-drop, resource views - it does a lot. But a few months in you start finding the edges. The styling system is entirely its own world: custom theme engine, its own CSS variables, strong opinions about how everything looks. Want it to match your design system? You're not customizing it, you're fighting it - overriding generated class names and hoping nothing breaks. The TypeScript support has that same bolted-on energy as the rest of the ecosystem, autocomplete that ghosts you at the wrong moment. And it's a paid license, which is fine when you're getting value, but starts feeling heavy when you're spending two hours on a CSS change that should take ten minutes.

Then you ask the question you should've asked earlier: what are we actually getting for 15MB?

Turns out - a Gantt chart renderer, resource histograms, a spreadsheet module, a full enterprise scheduling engine. We were using maybe 10% of what we were shipping. Bryntum isn't a calendar, it's an enterprise scheduling platform, and we were awkwardly extracting the calendar slice while the rest came along for the ride. Forever. In our bundle.

Our in-house replacement ended up at 76KB. The whole thing - event rendering, date navigation, grid layout, all of it. Not because we did anything clever, but because we only built what we needed.

How We Built It (And What Helped)

We're already on Nuxt UI across the codebase, so the primitives were already there - buttons, inputs, dropdowns, popovers. The calendar-specific logic turned out to be the smaller part of what Bryntum was providing. We assembled what we needed from components we already trusted and wrote the calendar pieces ourselves. Styleable without therapy. Fits the design system natively. Still has some edge cases we're ironing out, but it's ours.

The part I'm both proud of and slightly embarrassed by: I used my own Claude Code plugin to help with the migration.

It's called auto-research, and it's my own take on an idea that's been floating around in certain corners of the AI/dev world. The lineage goes: Andrej Karpathy's thinking on autonomous research-driven coding -> pi-autoresearch as an early implementation -> and then this tweet from Tobi Lutke that kind of broke my brain a little. Tobi ran /autoresearch on Shopify's Liquid codebase and got 53% faster combined parse+render time and 61% fewer object allocations. His take: "This is probably somewhat overfit, but there are absolutely amazing ideas in this." That was enough for me to start building my own version.

I'll be the first to say mine is rough around the edges. But here's what it does - when you run /research <task>, it kicks off a six-step pipeline: parse the task, spawn 3-5 parallel subagents to investigate approaches (web search + codebase analysis simultaneously), synthesize and rank what they found, implement using Claude Opus, verify against your toolchain, then auto-fix failures up to a configurable retry limit. It also persists session state so if it gets interrupted you don't lose everything.

For the migration I used it to front-load the thinking. Instead of manually digging through Bryntum's event model and figuring out what Nuxt UI components could replace what - I described the task, let the subagents go wide, and got back a ranked list of approaches with actual tradeoff reasoning. The implementation was smoother because the research wasn't skipped.

Is it production-grade? No. "Scuffed and useful" is an accurate description. But that's a totally valid category of tool.

AI Is Putting Pressure on Bad Software

Here's the broader take: a lot of the component libraries teams have been locked into for years aren't actually good. They were just the least bad option at a time when building alternatives was expensive and slow. The switching cost was high, the build cost was higher, and so mediocre software got to keep collecting license fees.

AI is changing that math. I'm not saying it writes perfect code - it doesn't. But it's genuinely good at producing UI components that are visually clean, properly typed, and styled the way you actually want. The gap between "use the library" and "build it yourself" used to be enormous. That gap is shrinking fast, especially on the visual and styling side where a lot of these tools have always been weakest.

The pressure this puts on component providers is real. If your moat is "we did the hard work so you don't have to" - but that work is measurably easier now - you need something else going for you. We asked a simple question about our bundle. The answer was uncomfortable. And replacing it wasn't the massive project it would've felt like two years ago.

That's not an argument for building everything yourself. Sometimes the library is genuinely the right call. But the bar for "is it worth replacing" just got lower, and some things that cleared it before might not anymore.

The plugin's at github.com/ZainW/ai-plugins if you want to try it. Lower your expectations appropriately - it's a work in progress. Aren't we all.