PeARL Stack

PeARL Stack Logo

Phoenix · events · Ash · React · LiveView

The beginner-friendly, vibe-proof stack where the footguns have been locked away.


What is PeARL?

PeARL is an opinionated web application stack designed for maximum readability and maintainability. It combines battle-tested technologies in a way that prevents common mistakes rather than just documenting them.

┌─────────────────────────────────────────┐
│           React Components              │  ← UI you can see
├─────────────────────────────────────────┤
│              LiveView                   │  ← Real-time state
├─────────────────────────────────────────┤
│            Ash Domains                  │  ← Business logic
├─────────────────────────────────────────┤
│            PostgreSQL                   │  ← Your data
└─────────────────────────────────────────┘

Each layer can only call down. No spaghetti. No mystery re-renders. No “works on my machine.”


The Stack

Letter Technology Role
P Phoenix Web framework built for real-time, on the battle-tested BEAM
e events The entire API: pushEvent down, props auto-update up
A Ash Declarative domain modeling with deny-by-default permissions
R React UI components, as originally intended—reactive, not state-managing
L LiveView WebSocket state coordination, progressive re-renders

Why “events”?

The lowercase e is intentional. Events aren’t a proper noun—they’re the philosophy.

Your entire client-server contract is:

// React → Server (you send events)
pushEvent("create_todo", { title: "Buy milk" })

// Server → React (props auto-update)
<.react name="TodoList" todos={@todos} />
// When @todos changes, your component re-renders automatically

No REST. No GraphQL. No CORS. No API versioning. No caching bugs.

Just pushEvent up, props down.


The Thesis

Non-technical founders complete their apps more often with PeARL than with JavaScript stacks—even though JS “seems more familiar.”

Why?

  • Fewer footguns = less frustration = more founders finish
  • Explicit over magic = better understanding = confident iteration
  • Constraints = freedom (can’t accidentally bypass auth or expose sensitive data)
  • Server-owned state = simpler mental model = less debugging

Who is this for?

PeARL is designed for:

  • AI-assisted developers who generated something that works but don’t fully understand it
  • Non-technical founders building their first real product
  • Experienced devs tired of debugging useEffect loops and hydration errors
  • Teams who want readable code that new members can understand in days, not months


Built with technologies that have been running in production for decades.
Phoenix. Elixir. The BEAM. PostgreSQL.
Boring technology. Exciting results.