- Can build entire app (with SPA-type experience on the FE) in a single codebase
- No need to build any HTTP APIs
- Periodic tasks and managing in-memory state is super easy in Elixir. Eventually you might want to stick state somewhere which survives restarts (eg redis) but for the sake of moving quickly Elixir makes this really easy
- Newer versions of Phoenix/LiveView support html components so building out UIs now feels as nice as some of the tools in the FE ecosystem
Elixir makes state management very easy by default. Elixir implicitly encourages you to write code in-terms of state, events and transitions - so managing game state can be done using the default tools/abstractions. When I write LiveView components I usually end up building a state-machine.
The way I've seen this play out in reality is that a lot of the "presentational logic" required by the templates gets computed in the "Django Views" layer (akin to the "controller" layer in traditional MVC). So in the end Django views both perform business/service logic and presentational logic.
I took it for granted after doing Django for several years but after doing a lot of web development in a more explicit MVC paradigm (Elixir and Phoenix in this case), my old Django code didn't really separate the web layer from the business logic layer. If I write more Django in the future I'll definitely be more aware of this but in many cases the framework (Templates, Forms, Models, Django-apps) don't really encourage this type of in-app architecture.
Main reasons are:
- Can build entire app (with SPA-type experience on the FE) in a single codebase
- No need to build any HTTP APIs
- Periodic tasks and managing in-memory state is super easy in Elixir. Eventually you might want to stick state somewhere which survives restarts (eg redis) but for the sake of moving quickly Elixir makes this really easy
- Newer versions of Phoenix/LiveView support html components so building out UIs now feels as nice as some of the tools in the FE ecosystem