I learned to not deviate too much from the “defaults” of the ecosystem anymore.
- For the short-term, the benefits can be huge when just pulling together any productivity boost available at the time, definitely true
- For the mid-term, you often end up needing those customizations anyway, just that you do it now another abstraction indirection or drop down to the original thing, so its just added complexity because of more stuff to think about in total
- For the long-term, the best ideas from the community ends up in the default way ideally. Like, Surface did some awesome things and then we got Heex + live components in phoenix liveview natively after a while when they joined forces. This is when an idea really succeeds for me.
… also add ontop that there are many many engineers here that already struggle with the learning curve of elixir/phoenix/liveview when they start out, and I really hesistate to add anything else ontop for now. Also the “there is no magic” and straightforward functions within phoenix really do help beginners to “get” it, and I argue only after this point it even makes sense to talk about what ash brings to the table and why its good.
I have patience and will wait until ash is no longer “AshPhoenix” but natively/seamlessly integrated as optional component within phoenix itself, and I can choose to create some Context with a flag either plain ecto or with ash, just like I can choose to have my frontend generator phx.gen.live or phx.gen.html 
if this is not the roadmap, fine for me too, but then I will probably never use it personally, since I won’t deviate from the phoenix baseline defaults anymore.
