Nvim
Anybody knows a comprehensive comparison of Django and Phoenix, thanks for the help.
- Where are they similar?
- Where do they differ the most?
- When would you use/recommend either?
- Anything else you’d like to share?
Trending in Discussions
As the title says, please share what you’ve been up to with Elixir. Whether that’s been learning it, looking into it, making stuff with i...
New
The obligatory hello world thread!
Who are you and where are you from? :stuck_out_tongue:
New
@chrismccord : I just saw the Extract AGENTS.md from Phoenix.new into phx.new generator commit to the phoenix project.
My initial shotgu...
New
I was working on an Ecto migration and I needed a timestamp. So, for the nth time, I looked up the different data types for timestamps, a...
New
There has been a thread to discuss the Stack Overflow Developer Survey on this forum every year since 2018, so here’s yet another one for...
New
I just stumbled on a newly redesigned elixir-lang.org. :tada: It looks like @Software_Mansion did the work, and I think it is generally a...
New
Fly’s CEO posted this recently - Turn And Face The Strange · The Fly Blog
It says that Fly is going all-in on sprites, which is a worry ...
New
Other Trending Topics
Hey, I’m Jesse and I’m the main contributor behind Dexter, a full-featured, lightning-fast Elixir LSP optimized for large codebases. It s...
New
Beam Bots (or just BB for short) is a framework for building fault-tolerant robotics applications in Elixir using familiar OTP patterns. ...
New
Hello everyone. After busy few months I am happy to announce v0.1.0 of Emerge & Solve.
They are GUI (Emerge) and State management (S...
New
Corex is an accessible, unstyled UI component library for Phoenix that integrates Zag.js state machines using Vanilla JavaScript and Live...
New
Emily is an Elixir library that runs Nx computations on Apple’s MLX. Install it as the default Nx backend and Nx, defn, Axon, Nx.Serving,...
New
While I am working on the Language Agnostic Code Audit SaaS, which uses MetaAST (spoiler: I am expecting it to be in a good shape for ann...
New
Latest Phoenix Threads
Chat & Discussions>Discussions
Latest on Elixir Forum
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #blog-post
- #phoenix_html
- #iex
- #graphql
- #ai
- #genstage
- #elixirconf-us
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #security
- #hex










First 10 of 82 Posts
adrianrl
Phoenix should be faster, at least by default, and a better choice for apps that require concurrency; streaming, real-time collaboration, long-running services… However Django is more established, there are a lot of jobs, books and tutorials.
I think Django is more complete by default, and thus it may be overwhelming at first, it may be worth considering alternatives like Flask, but overall both are easy to understand. I’d suggest you to spend a week with both frameworks building the same project (a simple one), and chose the one that makes you more productive.
AstonJ
I’ve edited your post to try and follow the format for these kinds of threads - hope you don’t mind
mikemccall
Based on my current experiences here is my take. I don’t have a comprehensive guide, but beyond handling web request and mostly following mvc they are not all that similar. Django has models and an ORM phoenix uses schemas with Ecto. Django’s use of “apps” fall in line with using contexts but each django app has it own mvc file structure. Which I have to admit I like. Django is also bloated with features and can serve a very wide range of web projects out of the box. It comes with a ready to go admin. Phoenix is explicit while django is implicit. I applaud both Phoenix/Elixir and Django for the excellent documentation.
Both communities are generally pleasant. Phoenix doesn’t take on user land solutions. For example authentication/authorization. Phoenix leaves the decision up to you, while django comes with it (including password upgrading). The elixir phoenix community hasn’t quite caught up with some of the other popular django apps such as Wagtail and saelor. But it will.
That being said django does not even come close to providing the ease of use when working with realtime. The phoenix team has done an amazing job adding realtime capabilities (my biggest pull to phoenix). With phoenix you also get the benefits with running on the beam. Phoenix has liveview which is very nice. I’ve already seen community members of django, crystal, and laravel implement their own versions. But those will not be as scalable.
Overall my default is elixir/phoenix. It’s fast and enjoyable. There are more than enough community packages to rival django. While “user land” decisions are not made for you by the framework itself, the community has fantastic libraries. The elixir community is full of some really smart experienced people. Pow is a good example of this. The elixir community is very happy to guide you in the right direction. You will not only learn and become a better developer, but you will start to realize those framework abstractions aren’t as hard as they might seem.
All that said, phoenix is probably closer to Flask than Django.
If a client needs cms capabilities, e-commerce or they really can’t be sold on elixir I go with django. Otherwise, elixir and phoenix all the way! Hope that helps.
dimitarvp
You already were given excellent answers. My really short version is this:
Do you want to have most of what you need ready-made and able to be put in your project with small initial friction? Go for Django.
Do you want to build part of the required functionality (like authorization and CMS) yourself, while retaining full control on what is going on below the hood? Go for Phoenix.
Have in mind though: apps made with implicit/magic frameworks always come with a high maintenance burden. They allow you to start quicker but you pay off those savings in the future, many times over. A lot of Rails and Django apps are an example of this phenomena.
Nvim
Thanks @AstonJ, good job!
abitdodgy
What about libs like Pow? Don’t they remove some of this DIY burden?
leaf
There are already pretty good answers here.
Django(
advantages in my opinion):Comes with admin panel which is very good and have an excellent support.
Include it’s own ORM.
Session support is very good.
Each feature will be broken down into smaller apps by default.
third party library support is good.
More jobs.
Django rest framework is very good for building api’s.
Disadvantages:(
In my opinion)Bloated with lot of extra features.
deployment is little difficult.
No dedicated forum as good as this one.
No built in modules like Gen servers to handle jobs processing.
Phoenix:
Excellent:grinning:
Fast
Not bloated
Excellent built in tools for RTC
Genservers are great to have.
Ecto is very good.
But at the end It all comes down to your needs.
You are building e commerece website . Instead of building admin panel from scratch go with Django saves you a lot of time.
You are building app with lot of background job processing and real time communication go with phoenix.
Hope this helps..
peerreynders
FYI: There is a Python by O’Reilly Humble Book Bundle for the next 5 days.
albydarned
Lots of great points in this thread!
If you’re set on Python as a language, I would highly recommend Flask. You’ll start very bare bones, but in the end you will have a great app with only the pieces you really need. I’ve built many apps in Flask and always been pleased with the results. It is very well documented and easy to get going.
Django is great, but gets a bit bloated and hard to maintain when so much is automagically done IMO.
Nvim
Django appears to have the upper hand in both official and unofficial documentation.