Why you should use Ash?

The chapter argues for Ash by comparing it with vanilla Phoenix over the life of a project, not just at the start. The authors say Ash becomes more valuable as systems grow, because it keeps domain rules in one place and reduces the pressure of scattered custom code.

Reading notes

#

• Some objections to Ash come from its small but growing community, such as fewer tutorials, harder-to-read documentation, and fewer experts.
• The authors say Ash’s creator and core team are active in the Elixir Forum and that support has been fast.
• They treat Ash’s new concepts, declarative style, and perceived magic as part of its design, not as flaws.
• Their main comparison is not starting a project, but managing it as it matures with more complexity.
• In their experience, vanilla Phoenix made later onboarding harder because key knowledge stayed in long-term contributors’ heads.
• Ash gives each resource a clearer structure, and the describe macro helps document resource information.
• They say Ash lowers code duplication by making resources a single source of truth for migrations, APIs, validations, and policy logic.
• They also argue that using one resource definition for multiple outputs reduces maintenance over time.
• The chapter presents Ash’s declarative approach as a way to define what is needed and let the framework handle the implementation details.