You can incrementally add client side only UI elements as you need - and if you want to use something more complex there are escape hatches which let you use your frontend framework of choice which can then hook into the LiveView process across the socket.
When it comes to refactoring, the fact that Elixir is compiled helps a lot - there are a set of mistakes you make during a refactor which the compiler will just catch for you.
If I were tasked with building an app with a similar feature set in another language or runtime Id have to bring in a whole set of technologies and infrastructure that would make it challenging. The killer feature of Elixir (and Phoenix/LiveView) is not just that you can do all this in the same app writing backend code, its that the scalabilty characteristics of the runtime mean that you can push it really far once you are live.
Im excited to read through some of the codebase as a good example of a LiveView app.
Tailwind feels like the correct abstraction on-top-of css which works for 90% of use-cases.
I struggled with css for many years but Tailwind has actually helped me improve my css - when I'm forced to write plain old css, my mental model of how everything works is much better. The fact that Tailwind has become so popular is a smell that css is slightly too low-level for most developers.
Phoenix has a much smaller footprint than Django. I would put Phoenix closer to Flask in terms of how much work the framework does for you. Phoenix has lots of generators which make hooking into the database layer very easy and bootstrapping new endpoints is also fast in Phoenix. Django makes more decisions for you (authentication, permissions, admin, the ORM to name a few).
In the Phoenix ecosystem you bring each of those pieces in as you please (auth generator, Ecto + other libraries etc). So I would say if your really want to move fast, you will still get further, faster with Django - but the trade-off (as other posts here have alluded to) is that once you need to implement custom features or optimisations you will often fight against Django (or need to wade-through half a dozen classes in some inheritance tree to find the right hook).
Another big difference between Phoenix and Django is that building websocket services in Phoenix is an absolute breeze. The Elixir runtime maps perfectly onto any type of messaging service.
Great article. It sounds like the same journey I’ve been through - initially enjoying Django and it’s ORM, then starting to wrestle with the fact that the data layer is hidden from the programmer. Ecto really is the perfect abstraction, and it’s made me a better programmer when I go back and interact with the Django ORM.
I came to Elixir from another untyped language (python) but I've never had any issues.
Elixir code often relies heavily on pattern matching return values (ok/error tuples or Structs) so that helps along with typespecs.
The fact that the language is compiled is also a big help when it comes to avoiding run-time errors while developing locally.
The other thing I appreciate about elixir coming from python (more specifically Django) is that most application-specific code is just modules and functions. There is none of the indirection and abstractions-upon-abstraction I used to have to grok in big python codebases.
