| 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. |
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.