I feel as though this website does a poor job of telling me what the framework actually does. There's the mostly-fluffy marketing lead text, followed by an overly-complicated configurator to generate a project.
What can I actually do with this? What problems does it solve? Where is it located relative to other solutions in the same space? What is that space?
I've talked about this a few times and this is the shortest answer to this question. The first part of this talk may help explain concisely where Ash fits at a higher level.
Ash Framework was created to solve a fundamental problem in (web) application development for business apps. When you build a new app, you want to focus on the valuable, innovative parts - what's visible above the waterline of the iceberg. However, modern web applications require an enormous amount of "below the waterline" functionality that's essential but not where you want to spend your time.
Running a consultancy and building various client projects highlights this challenge. Everyone wants to focus on the core, valuable features, but must also deal with relatively boring, commodity problems that have been solved countless times before. This often means reinventing the wheel, which clients understandably see as low-value work.
Authentication is a perfect example - most customers don't even specify login functionality as a feature. Similarly, admin interfaces are considered table stakes for modern applications. The list is extensive: admin UIs, observability, security, and more. All important, but time spent there can feel wasteful when you'd rather be innovating.
Ash's primary goal is to keep you focused on the innovative work above the waterline while minimizing time spent below it. The framework accomplishes this by modelling your domain and deriving everything else.
This is not a new problem. It is exactly what a web application framework like, e.g. django has been handling for one and a half decades.
What does it do that django doesn't?
A lot of competitors to django have also fallen behind because they either railroad you too much (e.g. by making immutable assumptions about how you want authentication to work which often end up being faulty) or go too far in the other direction and require an excess of boilerplate. This is a very subtle and tricky trade off that most newcomers to the space fail badly at.
But you aren’t required to use Phoenix with an Ash project. Ash will happily work as a standalone CLI, terminal app or some other Elixir web framework that comes out tomorrow.
The forms https://hexdocs.pm/ash_phoenix/AshPhoenix.Form.html seem even more low level than Django forms, and those are notorious for being too low level and annoying to work with. This to me seems to run counter to the tagline. Compare with iommi for Django where you can truly "derive the rest" from the domain model to get forms and tables.
There is definitely room for the Phoenix Form helpers to do more. Iommi looks like a really interesting approach I hadn't seen before.
For example AshAdmin (https://github.com/ash-project/ash_admin) takes these ideas further and generates a full super admin interface for you. It's a bit clunky and you should ultimately write your own admin, but it lets you focus on the important parts first.
For anyone else who hasn't seen it Iommi's motivation and docs are here:
Yea, the thing with the transparent APIs thing in iommi is that there's an admin and you can customize it just as much and as detailed as your own code. So you don't get the thing with the Django admin where you get a rough thing first and then spend hours and hours customizing and then when you hit the limit, you have to throw all that away and start from scratch. I hate that.
You can literally take 100% of the iommi admin config and copy paste it into your own custom edit forms or tables or whatever it is. It's the same config language.
Unlike Django, Ash is not a web framework, it’s an *application* framework.
One way to think of it is that it’s a flexible and extensible domain modelling language that also happens to derive an Elixir application which can be called from Phoenix web UI (or something else like an API, a terminal UI or even an MCP server.
This is a default pitch for a framework, which is at least as old as Ruby on Rails (an today it sounds more like a pitch for low-code platform than a framework). Is this framework's approach different from RoR/Django in any way, or it is just filling the vacuum in Elixir ecosystem?
Ash was definitely inspired by Rails but takes the seed of those ideas much further. So far that it starts feeling like a flexible and extensible domain modelling language and application configuration tool. It also happens to produce a working Elixir application using the best of the Elixir ecosystem.
It's funny that you say it sounds like low-code, because we've often said it's low-code tool but for software engineers. So when you inevitably hit the wall of a proprietary no-code/low-code platform, Ash can let you extend the framework or just solve the problem by writing functions as you like.
Once you appreciate the Ash way though, be warned! It's very hard to go back...
The gap it solves is having an opinionated, UI agnostic way of building your application layer. Phoenix has very limited opinions on how to write your application, and the team has stated that "Phoenix is NOT your application". Ash basically is your app, and Phoenix is the web frontend.
...do you think the book is like a money grab or something? We put it big on the site because a bunch of our users were excited about it and found value from it. The book doesn't even remotely pay for itself.
> ...do you think the book is like a money grab or something?
Yes. Regardless of what you intended, IMHO, it comes off as a money grab, and the fact that it glows and "Get the book" is in that high contrast purple doesn't make it better. Maybe it's just me, but I would suggest making it less conspicuous.
edit: and the book image causes a content layout shift when it loads
I appreciate the perspective. Honestly for us it was just something that our whole user base was mega excited about, and so we made a big deal about it. It seemed like a positive that there was a book available (especially given that young-ish frameworks benefit from some level of legitimacy, given that it's a Prag Prog book etc.). I never even considered that it would rub people the wrong way honestly.
I think I'll probably keep it front and center for now, given that the book will be launched out of beta in the near future, but I can see how it might give the wrong idea, and will reconsider its placement going forward
About books: I had a horrible experience in the past with Trailblazer, the Ruby library.
The documentation was horrible, and only had extremely basic examples. The recommendation to any question I saw online was always to buy the book for almost anything. The goal of the bad docs was clearly to encourage people to buy the book. That rubbed me off and it felt like a cash grab.
And of course I'd buy a book and donate for a library I'd want to support, but for Trailblazer's case it's the opposite, I never voluntarily chose to use it and actually would like it to die.
Coming to the site from an aggregator (and needing to be convinced to use Ash, rather than coming there directly and already knowing I want to use ash) I found the book a little weird to be so front and center.
I would have really hoped for a small code snippet or screenshot showing how powerful the framework was. And a book a little further down from that would be nice. But "pay to learn" before "here's a quick snippet on why ash is neat" would have made me more excited for this thing I hadn't heard of before, and who's website I was visiting to learn about.
---
Seeing a book first gave me a different impression -- like one of the old snooty languages/tools from twenty years ago that was really enterprise-only.
I can tell that's not the vibe Ash is aiming for, but it's what I picked up!
(Somehow, I also couldn't find the documentation link on the first two tries. But that's also my eyes being weird and missing the sticky header where it clearly says Documentation!)
I've got to be honest. The comment you're replying to is spot on.
The headline, "Model your domain, derive the rest" is fine by itself. But the paragraph underneath is just dismissible drivel; sure, I could click through the links to more detail, but you've not given me a reason to do so... you've not set the hook. Once I did click through the links, I'm either in the documentation, which is way too much, or at YouTube, etc. The opening paragraph doesn't give me enough reason to click through the links, and if I do I'm given what feels like a firehose.
I appreciate that's pretty harsh assessment of your landing page, but that's exactly how it strikes me and I think you need to hear it if your goal is really to capture audience. That landing page should give me the gist of what you do, several short paragraphs outlining the higher level features... I dunno, call them "selling points"... something that can give me cause to care enough to dig into some details. Once I care, then sure... I'll dive into the docs or watch a video.
As for the book ad other comments talk about: it's fine. I would expect that people that know what Ash Framework is also come to the page and having that out front isn't a problem and speaks to the existing community.
Personally, I already know what Ash Framework is, so I know you have some good selling points that could be summarized and that would be of interest to people. You just need to get them out front in as pithy a way as possible.
That's really helpful feedback and there are few comments mentioning exactly this and you're right, we can definitely explain more up front on the landing page so it's more obvious.
> Running a consultancy and building various client projects highlights this challenge. Everyone wants to focus on the core, valuable features, but must also deal with relatively boring, commodity problems that have been solved countless times before. This often means reinventing the wheel, which clients understandably see as low-value work.
So wordpress or prestashop should be enough for 95% of your needs if you're a consultancy.
Absolutely, if your customers want websites or ecommerce shops, then that's totally true.
The context here is that Alembic builds custom business applications where these problems have not typically been solved before. We want to spend most of our development time on the core business problem not rebuilding things like Content management systems or Ecommerce shopfronts.
Rails are definitely inspiration for the way Ash DSLs are used to model your business domain, but Ash takes this idea way further.
Ash models nouns and relationships like ActiveRecord does, but it also models Domains (think DDD bounded contexts) and Resources with the verbs or "actions" of your system.
It also lets you configure generated APIs and your data layer (eg Postgres) so it doesn't stop at just how an ORM may typically model your data.
Always cracks me up. In previous life I worked in creative agency and we had a Project Manager called Ruby. Sometimes parties were getting out of hand and she got a nickname Ruby on Rails when she dropped a baggie on the table and made herself two lines (rails) with company credit card.
We've always had trouble with this. The closest thing to Ash I've seen elsewhere is an ORM. It's not an ORM though.
Ash is a declarative application framework. You define your application logic using Ash.Resource, which model things like state, but most importantly actions.
Another analogy is that it's similar to GraphQL, but lowered down to the backend layer. It's a declarative, typed application description and implementation framework, that you can derive a GraphQL from (amongst many other things).
Another way to think of it is a whole ecosystem of packages that standardize the vast majority of things you want to do when building an Elixir backend, instead of trying to kludge together a bunch of different tools. Pagination, sorting, filtering, authentication, authorization, all builtin and designed to work together.
That's certainly more helpful, yeah! My biggest complaint is that that's really not particularly obvious from the home page; I didn't realise the highlighted words in the lead were links, and they're all to a diverse set of locations, which I'm unlikely to check out if I just want a ten-thousand-foot view of the framework.
I'd suggest putting a description similar to your last paragraph on the home page, and including a brief example of what that translates to. Phoenix's website [0] does this beautifully: within the first page of scroll, I immediately know what it does and how it looks, and the following pages of scroll give me the detail I need to evaluate it properly.
Yes, this is a good description. The way I explain it is that "Ash is a declarative, composable application framework."
It is the middle layer between DB (Ecto) and Phoenix (with or without LiveView) -- where your actual application lives.
The difference between a Resource and a Model (or ActiveRecord) is Models typically define attributes and relationships vs a Resource defines attributes, relationships, actions (read, write, destroy, custom...), behaviours (i.e. multi-tenancy, jobs) and what I call facets (i.e. JSON api, GraphQL).
When you read the code for a Resource, you grok all of this in a nice, consistent way (we have 100* resources - all are consistent). This is because of the DSL.
When compiled, it all boils down to a Struct that you can easily inspect. That Struct enables all kinds of stuff.
I hear what you say. I personally blame the flurry of BS js "frameworks" that have more effort put in their Apple-wannabe front page than in actual practical engineering. I think they've setup a weird standard for framework front page that this one seems to follow.
I don't blame the Ash guys, I blame the people who created the trend and those supported who it. I look at you, JS community.
What can I actually do with this? What problems does it solve? Where is it located relative to other solutions in the same space? What is that space?