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.
https://youtu.be/10VBTcN8gAo?feature=shared&t=133
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.
When I opened your website first thing I saw was "Get the book" and it's a big red flag for me. No, I don't think I will.
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.
> 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.
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.
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?