Ash Framework: Declarative Elixir Web Apps • Rebecca Le, Zach Daniel & C. Alexander • GOTO 2026
Rebecca Le and Zach Daniel, co-authors of the Ash Framework book, discuss how their Tunez-based guide was built to introduce concepts in the order a real project needs them, how writing it forced the addition of generator-based testing to Ash, and why Ash's extensibility, Cinder's rapid development, and AI-assisted onboarding make its steep but flattening learning curve worthwhile.
Ash Framework: Building Declarative Elixir Apps Through Extensibility, Testing, and a Book-Driven Design
Origins of the Book
Rebecca Le and Zach Daniel describe the book as the guide Rebecca wished she had when she started with Ash, back when it was around version 1.0 and the pieces existed but their relationships were unclear. Rebecca, a core team member focused on the outer UI layer and documentation, wrote the progression deliberately: a music-database app called Tunez is built in small steps, and authentication, policies, and testing are introduced at the point a real project would need them, rather than front-loading the hardest material. Zach, who describes himself as a decent programmer and a great framework author rather than a great author, credits Rebecca with most of the book’s quality, and notes that the process drove several book-motivated enhancements to the framework.
Learning Curve and Progression
Christian admits he failed to learn Ash several times, mostly because he tried to model relationships and policies before he had an application at all. The book’s sequence, which models the domain first and derives the rest, is presented as a deliberate counterpoint to frameworks where users, roles, and permissions must be modeled on day one. Zach reports the learning curve is steep at the DSL and concepts stage, but flattens afterward: Ash authentication uses the same policies and actions a developer already knows, and nested forms, which normally require significant effort in Phoenix, are handled through helpers in Ash Phoenix covered in chapter eight.
Extensibility as the Core Bet
A key theme is that extensibility was a goal from the start. Zach contrasts Rails as “omakase” (convention over configuration) with Ash as a Chipotle bowl, where a base set is provided but serious use cases add extensions. Examples include event-driven extensions that rewrite actions to emit events, Ash TypeScript for generated front-end bindings, and Ash AI for MCP servers and AI tooling. Because the foundational building blocks (domain modeling, resources, actions, policies) are stable, the book’s core material has remained valid even as the ecosystem evolved quickly. Zach notes a commitment to keep book-covered material working for at least a year, and reports that the policies guide had confused Discord users until they read it several times, which he sees as evidence that context-free reference dumps are unhelpful.
Testing Forced New Framework Features
The most striking account is about testing. Ash deliberately offered no testing guidance, reasoning that apps are just Elixir apps. Users kept asking for it, and the team tried factories and action tests, but their guidelines were undocumented. Writing the testing chapter revealed that the approach could not be explained as things stood, so the team built generator-based test data support that now ships with Ash. Zach admits he had avoided forming an opinion on testing and that the book proved his reluctance unfounded. Rebecca and Christian tie this to the value of testing core actions: since policies are applied automatically across queries via the SAT solver, testing declarations becomes natural and reliable.
Cinder and Ecosystem Contributions
Rebecca built the first version of Cinder, a data table library that auto-generates filter UI from resources and runs queries to populate tables, in roughly a week. Its design grew out of repeated work on filters, search, pagination, and export across client projects. Zach’s company, Remedy, a telehealth platform with extensive tabular data, had a half-baked in-house version that was replaced with Cinder, deleting a large amount of code. Zach frames this as one of the most rewarding aspects of framework authorship: benefiting from contributions by others, such as James Harden’s Ash Authentication. Christian echoes this, describing a migration where importing Postgres tables and generating resources let him delete large domain modules and rely on resources and actions.
The One-Line API and the Lightsaber
Zach recounts a client whose API layer became an afterthought, a single line of code once the modeling was complete. He is candid that this power is double-edged: a line that does a lot must be understood, hence his lightsaber analogy, where mastery takes investment but yields great effectiveness.
AI and Onboarding
The conversation closes on AI’s effect on onboarding. Zach manages roughly 70 engineers, some of whom have never learned Elixir and are delivering on Ash projects in under three weeks, aided by a large corpus of Ash examples and AI tools that explain why code behaves as it does. He observes that basic “I got this error” questions have nearly disappeared from the Ash Discord, which he sees as a positive effect of AI on the community, reducing the burden that used to fall on volunteers helping people learn.
Takeaway
The guest consensus is that Ash rewards up-front investment: follow a structured book, build a real application, and understand how the pieces fit together.