When would you use plain Phoenix and when Phoenix with Ash?

Since Ash is new, I’d use it for experimental projects and learning. After some hands-on experience, you’d be able to decide for yourself in future projects.

I have difficulty coming up with an example where I wouldn’t use Ash after using it for a year. Ash is doing a lot for you, but in the end, it is just resources and actions. A resource can represent pretty much anything, and actions are how you interact with it.

It’s a lot to learn at the beginning, but I feel it pays off very well in the long term.

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.

At the end of the day, Phoenix has very few opinions on how you build your actual application. In my opinion, delegating that decision to them is essentially deciding on “no decision”. I think it is pretty unlikely that phoenix will ever ship with Ash, but stranger things have happened

maybe not by name “ash” for whatever reason (although I don’t see a conflict, I also run mix ecto.gen.migration in a phx project, sooo)…, but I guess in terms of functionality like 80% could be done as a core lib at least, and then full focus with the rest of the stuff, like phx.gen.live being aware of either the more manual ecto-way or the more declarative ash-way.

If this just works natively, I think the majority of users of phoenix will start using ash without thinking it as an “or” decision like it feels today (its not technically correct but feels like that) - it rather would be an upgrade thats worthy some phoenix 1.9 keynote or sth like that.

But at the end of the day I believe its just more fun to explore new ideas or iterate on standalone things instead of fine-tuning the integration story, especially when lots of great feedback starts rolling in. Still I’d like to be “that” guy nagging in this area of focus, since a “unification” in many cases also brings more benefits to all partners than what anyone would achieve on its own, basically only a piece of the cake is yours but the cake itself is much larger in itself + more people to enjoy it with right there. I hope this somehow makes sense and please be assured I only argue about this at all because I think ash is a great project to begin with, so kudos to you

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 think I get your point here, but bear with me a bit!

First, phoenix is a framework and a library at the same time. It expands around a basic mix projects and adds the “$_web” layer ontop of it for some kind of interactions with the world. But it also provides the basic structure (contexts in the mix project and web stuff) and tooling (like predefined tailwind/esbuild) and fullstack goodies (like the generators, my primary way of working, that work on the web and non-web parts). And apart from the excellent toolings, it assembles Plug/LiveView/Ecto/… (each excellent on its own) into one seamless experience.

compared to (previous vanilla) phoenix+liveview, surface really tried to optimize the “user interaction” part ontop of the raw technology and made great progress on several specialized areas along the way. now we have a liveview on steroids (compared to back then) and the benefits even reached into other frontend areas (like deadviews now also enjoying Heex).

compared to (current) phoenix+ecto, ash really tries to trim down the context boilerplate into declarations and this indirection allows to have additional functionality like plug’n’play lego blocks because of added standardizations/knowledge internally to build upon. now we have a domain layer on steroids and can make progress in specialized areas along the way (iE: admin dashboard like django ootb, or APIs of different kinds without manual wiring/repetition, or…) so the benefits reach into other layers like frontend areas even.

so from my view its literally the same situation just from a different angle this time

I think we’re going to have to agree to disagree on this front For some context, Surface is 15k lines of code in a single package designed to make a specific segment of your application better. Which is not disparaging to surface at all, its an excellent tool and “how many lines of code” is an extremely crude measure of scope.

In comparison, Ash is an entire ecosystem that does (I think based on this conversation) a lot more than you think it does. Using only the current published packages (there are a few that are not yet), Ash consists of 114189 lines of code. Again, I’m not suggesting “lines of code” is by any means a metric we should care about, I’m only trying to use it as a very crude illustration that Ash covers significantly more ground. A footprint that will only continue to grow.

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.

@Kin Also my apologies for not answering your question directly, but as the author of Ash I think there might be some (real or perceived) bias in my answers, so I’ll stay out of it and let others give you their thoughts.