I think it’s better to leave Phoenix un-opinionated about your domain implementation as it currently is. I don’t think that it should include ecto related things or Ash related things. Phoenix is a web framework. It makes sense that many parts of Surface made their way into Phoenix because they have overlapping domains, whereas Ash and Phoenix are actually solving two different problems. Because phoenix has stayed un-opinionated about these things, people are free to bring in things like Ash, or not, or use other application building tools as they see fit.

Phoenix ships with a low level(but very high quality, I’m a huge fan of Ecto) tool for interacting with data, not any kind of application development tooling. People often refer to Ecto as an ORM, but it doesn’t really fit that bill.

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.

To be fair, I too am not seeing Phoenix ever making tighter integrations with libraries like Ash but for what it’s worth nothing is stopping any of us in the community to make Ash-aware Phoenix code generators.

And I get what you are saying, standardization brought in by Ash really opens up the doors to make stuff like Django does, which could be a huge win.