Why AlpineJS Deserves a Flowchart Engine
The origin story. Ron Northrip shows Zac a future package using a ReactFlow-powered tool for visualizing app data structures. Zac falls down the research rabbit hole, realizes Alpine has no equivalent to ReactFlow, and decides to build one with Claude.
Part of AlpineFlowIt started, as most dangerous ideas do, with a friend showing me something cool.
Ron Northrip pulled up Draftsman, a project he'd been building with ReactFlow. Without giving too much away — Ron's still cooking — imagine being able to visually see your application's entire data structure. Models, relationships, how everything connects. Not in a migration file you have to squint at, but laid out as an interactive flow diagram where the architecture actually makes sense. It's the kind of tool that makes you wonder how you ever lived without it.
I'd seen flow diagrams before and always found them interesting in that "I should really look into how those work" kind of way that developers say about things they never actually look into. Watching Ron build something genuinely useful with one, though? That was the push I needed.
So I did what any reasonable person would do. I fell into a research spiral that consumed my evenings for weeks.
"Why Doesn't This Exist for Alpine?"
ReactFlow's documentation is fantastic. Seriously, if you've never read through it, it's worth your time even if you don't use React. I studied how nodes and edges interact, how viewports manage panning and zooming, how the coordinate systems work together. The architecture is elegant, and the xyflow team clearly put a lot of thought into making it approachable.

The more I learned, the more one question kept poking at me like an unread notification I couldn't swipe away:
Why doesn't this exist for AlpineJS?
React developers have had ReactFlow for years. It's polished, well-documented, and battle-tested. Vue developers have options too. Alpine? Nothing. If you wanted a node-based UI and you were building with Alpine, your choices were basically "switch frameworks" or "good luck with raw SVGs."
That felt like a gap worth filling.
Alpine Can Handle More Than People Think
There's this quiet assumption in parts of the community that Alpine is just the thing you pair with Livewire for a little interactivity. A sprinkle of x-show here, an x-on:click there. Don't get me wrong, that's a huge part of what makes it great. It's lightweight and it stays out of your way.
Alpine is sneakily one of the most extensible JavaScript frameworks out there — the Clark Kent of frontend libraries. The directive system, the magics, the stores, the plugin API — it's all designed to be built upon. Caleb Porzio truly is a mastermind. He built a framework that feels simple on the surface yet has serious depth underneath, and I don't think enough people are taking advantage of that.
I wanted to prove what Alpine could do. Not with a to-do app. With a full flowchart engine.
I Didn't Set Out to Replace ReactFlow
Let me be clear about this because I think it matters. AlpineFlow isn't an attempt to dethrone ReactFlow. The xyflow team has done incredible work, and they made a decision that made everything I'm about to describe possible — they open-sourced their core under the MIT license.
That generosity is the foundation AlpineFlow stands on. The package credits xyflow and ReactFlow as direct inspiration, and that's not a footnote buried in a README. It's the whole reason this project exists. Open source making more open source possible. You love to see it.
I can read React fairly well, and I'm no stranger to Vue, though I've never used React regularly enough to feel comfortable building with it. That's not a knock on React — it's just not where I spend most of my time. I reach for the TALL stack about ninety percent of the time. Laravel, Alpine, Livewire, Tailwind. That's where I'm most productive, and that's where I wanted this kind of tooling to exist.
The goal was never "ReactFlow but in Alpine." It was to take the concepts ReactFlow proved work, rebuild them on Alpine's architecture, and make the whole thing feel like it belongs there. First-party. Native. Like Alpine always had this and we just hadn't noticed.
Enter Claude (Yes, Really)
Here's where the story takes a turn that would've sounded absurd a couple of years ago.
I knew what I wanted to build. I had the xyflow core to study. I had Alpine's plugin API to work with. Translating a React-based rendering engine into Alpine's directive-driven model, though, isn't something you knock out over a weekend. It's a fundamental rethinking of how the pieces fit together.
So I partnered with an AI.
Claude — built by Anthropic — became my collaborator on AlpineFlow. Not in the "generate some boilerplate and pray" sense. More like "let's spend six hours debating how Alpine's reactivity model should map onto viewport transformations" kind of collaboration. We went back and forth on architecture decisions, argued about API design, and worked through problems together. It turns out AI is a pretty solid pair programming partner, especially when you don't have to share your snacks.
This entire blog series is co-authored, and we're being upfront about that. Not as a gimmick, but because I think developers deserve honesty about how software gets built now. AI didn't replace the vision, the taste, or the product decisions. It did, however, make it possible for one person to take on a project that probably should have required a team. Think of it less like Skynet and more like a really patient coworker who never gets tired and never steals your lunch from the fridge.
What AlpineFlow Actually Solves
If you're building with Alpine — or really any lightweight frontend that isn't React or Vue — and you need a node-based UI, here's what your life has looked like:
Switch frameworks. Adopt React or Vue just for one feature. Bring in a build system you don't need, learn patterns you won't use anywhere else, and maintain a chunk of your app in a completely different stack. Sounds fun, right?
Roll your own. SVG, math, drag events, zoom calculations, connection routing. From scratch. I'm sure it'll only take a couple of weekends. (Narrator: it would not take a couple of weekends.)
Use a generic library. Something framework-agnostic that gives you low-level primitives but none of the developer experience you actually want. Hope you like writing boilerplate.
AlpineFlow is the option that didn't exist before. Drop in a plugin, write directives you already understand, and build flow-based interfaces that feel native to your stack.
And because Alpine is so lightweight, AlpineFlow isn't locked to the TALL stack either. If you're using Alpine anywhere — with any backend, any setup — it just works. That's the beauty of building on something small and flexible instead of something opinionated and heavy.
This Is Just the Beginning
This post is the origin story. The "why" before the "how." In the posts that follow, we'll dig into the features that emerged when we stopped trying to match ReactFlow and started asking "what if we went further?" We'll talk about WireFlow, the Livewire companion that makes this all feel seamless in the TALL stack. And we'll be honest about the dead ends, the bad ideas, and the moments where AI genuinely helped — and where it absolutely did not.
If you're an Alpine developer who has ever looked at ReactFlow and thought "I wish I could have that," this series is for you.
We're just getting started. Pull up a chair.
AlpineFlow is open source. More details coming soon. Follow along as we build in public — one human and one AI, side by side.