- way less out of the box. you’ll have to spend sometime getting a boilerplate up and running, especially if you’re making APIs, as with solutions like pow aren’t the best for that use case
- having your tests run instantly and webpack or node running on the same process is just life changing
- there is no equivalent of something like Django REST framework for Phoenix, which is annoying, but writing Phoenix is quite productive so it’s all pretty trivial
- ecto has a huge learning curve if you’re coming from the Django ORM
- you will miss the admin panel, and solutions out there are really janky. stuff like Kaffy, ExAdmin... they’re awful.
- documentation is really low tier compared to Django, especially when it comes to Phoenix. I was spoiled by how good the Django docs are and with Phoenix it’s been mostly digging through old forum threads for basic stuff. Docs assume a lot of prior knowledge about the elixir ecosystem, making it hard for beginners, unlike rails and Django. Their docs need a lot of work.
- community can be a little elitist or idealistic. Try asking how to get JWT auth running on elixir forums, watch it get shot down in minutes because “jwt is insecure”. they can be very friendly but also very unhelpful, sometimes lacking pragmatism
- unmaintained packages left and right
- being able to send email asynchronously or do websocket stuff without worrying about memory leaks is just glorious. doing that in Django channels, deploying to production was just a cycle of crossing my fingers worrying that the slightest bug would take down the entire runtime. python async absolutely sucks garbage
I can’t understate that last point. I’ve deployed multiple socket apps with Channels to production, and it’s always been a major pain in the ass on the long run. I spent months debugging a memory leak in Django Channels that only happened in production. Turns out an external package, sentry-python, wasn’t playing nice with ASGI. Async Django is painful and slow. I wouldn’t wish it on anyone.
I have more thoughts written down somewhere, but this is off the top of my head.
All in all: it’s been interesting, very fun. There’s tradeoffs to make, especially in productivity and documentation, but I feel they’re all worth it. Today’s apps demand speed, real-time, and concurrency. Django just feels stuck in a time warp from the last decade and Django channels isn’t progressing fast enough (add that async python is painful).
Maintainability and reliability is important for me as a solo maker. I want a resilient web app that can operate without babysitting, I'm a full time student.
Performance matters to me as well. I can't have a memory leak taking down my runtime every hour, or a slow request causing midnight support emails.
Elixir is just pleasantly fast at everything: unit tests are async, the server is concurrent, everything is just blazing..
Realtime is important for me because you don't always need it, but when you do, it's nice to have it. Knowing that Phoenix has a rock solid implementation makes me use it more. It helps me effortlessly make next-gen products.
Elixir and Phoenix come with performance/reliability guarantees, maintainability and new capabilities like flawless real-time that make it all worth it for me. This is my next upgrade to my stack and I’m really happy with it so far.
Trying to live up the Django docs is a big challenge given that Django was started by folks at a big newspaper. I think clear documentation is a core value to that project.
I agree that the automatic Hex docs are often a little sparse - they often just document the library API and don't give examples.
If you are trying to port websocket code to Elixir/Phoenix I'd recommend the "Real-Time Phoenix" book (
https://pragprog.com/titles/sbsockets/real-time-phoenix/). It has some hard won knowledge in it (I don't know the author, I just enjoyed the book).
I'm the author of Real-Time Phoenix. I appreciate the commenter's kind words.
If you ever need any help with content in the book, or a sounding board for Phoenix questions, feel free to DM me on the forums. I appreciate your points and generally agree with them, even the not-so-good ones.
> documentation is really low tier compared to Django, especially when it comes to Phoenix. I was spoiled by how good the Django docs are and with Phoenix it’s been mostly digging through old forum threads for basic stuff. Docs assume a lot of prior knowledge about the elixir ecosystem, making it hard for beginners, unlike rails and Django. Their docs need a lot of work.
Are there any concrete areas of the Phoenix/Elixir docs that you could point to? I'd love to make some doc PR's to make it more understandable, especially to Elixir beginners.
> there is no equivalent of something like Django REST framework for Phoenix, which is annoying, but writing Phoenix is quite productive so it’s all pretty trivial
It's not quite ready yet, but I'd recommend keeping an eye on https://www.ash-elixir.org/
It'll even generate an admin for you: https://www.youtube.com/watch?v=aFMLz3cpQ8c (although I haven't used django so I can't compare it to that, although I hear good things about django's admin)
> community can be a little elitist or idealistic. Try asking how to get JWT auth running on elixir forums, watch it get shot down in minutes because “jwt is insecure”. they can be very friendly but also very unhelpful, sometimes lacking pragmatism
Yeah this makes me sad sometimes.
> Maintainability and reliability is important for me as a solo maker. I want a resilient web app that can operate without babysitting, I'm a full time student.
Great point! Have you written about your web app anywhere? I think solo development of an application is a really interesting space that I'd like to investigate further at some point.
1) I don't know if I can pinpoint it... I have some notes, but it's mostly just little moments of frustration with the docs here and there. Functions that are undocumented, the docs glossing over important parts of the framework, etc. Can't put my finger on it, it's just constant frustration. I'm eager also to contribute to the docs: but specifically a tutorial for API development. This is an area where the docs are severely lacking.
Best practices is also another one. I feel they take too little opinions on how to use the framework, and it's difficult to find a best practices source (think a book like Two scoops of Django). This can be jarring to beginners.
I get that they're trying to be configuration first, but... People who use frameworks like Phoenix are trying to escape the freedom of systems that take too few opinions.
Phoenix strikes me as trying to be Flask but also trying to be Rails. I'm not sure it gets that middle ground right.
On the prior knowledge assumption: the tutorials for Phoenix assume too much Rails knowledge. Where Rails takes a beginner friendly approach with RailsGuides, Phoenix immediately assumes you're moving from Rails and the docs can be confusing for that reason.
The docs are sometimes made exactly for people who use Rails and that's very annoying for everyone else.
2.I'll be keeping an eye on Ash, that looks fantastic. An API framework that feels like Rails or DRF would be a killer app.
As a note, it's also baffling to me that Phoenix is trying to go the Rails route and completely ignoring modern API development. There's zero tutorials, just a generator. I really don't believe in LiveView: moving the UI state to the server is just a recipe for disaster.
I feel if Phoenix doesn't try to move where the industry is heading (API-first), they'll rapidly fall into irrelevance. Rails can afford to take that risk, they're too big to fail.
Phoenix and Elixir can't. They're too small and the incentives to move are not huge. They didn't kill Rails.
4. I haven't written extensively about it, but you can read my journey at my Twitter account (link in profile). I haven't been too active though, taking a break.
The best external Phoenix API tutorial that I've seen is https://lobotuerto.com/blog/building-a-json-api-in-elixir-wi... (which the author has done a great job of keeping up to date), but I think many people would have a hard time finding this blog post. And I 100% agree that it would be great to have a "Building a Phoenix-powered API" section in the official documentation (and I believe the Phoenix team would accept such a contribution).
> 4. I haven't written extensively about it, but you can read my journey at my Twitter account (link in profile). I haven't been too active though, taking a break.
Cool, just followed you! Although I'm not really very active on Twitter either, I mostly just interact with whatever @elixirlang retweets (which I read via the Elixir Slack).
Hey there! I'm the author of Ash Framework, happy to answer any questions you have. A few people have deployed to production with Ash and are seeing good results, but it is definitely at the "sharp edges" phase, where its great if you're okay with hanging out in our discord and troubleshooting, and even better if you're the kind of person who can dive in and PR whatever change is needed.
Hi Zach! I was just checking out Ash today, really liking what I'm seeing. I won't be trying it out just yet (don't have the Elixir skills just yet to contribute/troubleshoot extensively) but you can be damn sure I'll be keeping an eye on it.
This thing looks mind-blowing, and could be the future of the Elixir ecosystem. Keep it up!
Very kind of you to say! Getting it out of Alpha has definitely taken longer than I initially expected, probably something any other OS maintainer would have told me, but we're getting closer! Mostly need to make a few big documentation/testing pushes and then it should be ready. I want to redo the website and create a "book style" documentation site that has all the extension documentations in one place.
> I feel if Phoenix doesn't try to move where the industry is heading (API-first), they'll rapidly fall into irrelevance. Rails can afford to take that risk, they're too big to fail.
Phoenix with Absinthe is great for GraphQL-based API-first systems.
With Absinthe GraphQL, you don't need to to use much of the Phoenix's controllers/views/templates. You write GraphQL resolvers instead of Phoenix controllers and they talk to your Phoenix contexts which either using Ecto to communicate to DB, or talk to other services / APIs.
GraphQL subscriptions are event simpler, you either auto-trigger them from mutations, or trigger them programmatic from your code using Absinthe.Subscription.publish/3.
IMO it's best to implement Web UI using Phoenix LiveView and mobile/offline/desktop/SPA UIs and publicly-facing APIs using Absinthe GraphQL.
My initial thoughts...
- way less out of the box. you’ll have to spend sometime getting a boilerplate up and running, especially if you’re making APIs, as with solutions like pow aren’t the best for that use case
- having your tests run instantly and webpack or node running on the same process is just life changing
- there is no equivalent of something like Django REST framework for Phoenix, which is annoying, but writing Phoenix is quite productive so it’s all pretty trivial
- ecto has a huge learning curve if you’re coming from the Django ORM
- you will miss the admin panel, and solutions out there are really janky. stuff like Kaffy, ExAdmin... they’re awful.
- documentation is really low tier compared to Django, especially when it comes to Phoenix. I was spoiled by how good the Django docs are and with Phoenix it’s been mostly digging through old forum threads for basic stuff. Docs assume a lot of prior knowledge about the elixir ecosystem, making it hard for beginners, unlike rails and Django. Their docs need a lot of work.
- community can be a little elitist or idealistic. Try asking how to get JWT auth running on elixir forums, watch it get shot down in minutes because “jwt is insecure”. they can be very friendly but also very unhelpful, sometimes lacking pragmatism
- unmaintained packages left and right
- being able to send email asynchronously or do websocket stuff without worrying about memory leaks is just glorious. doing that in Django channels, deploying to production was just a cycle of crossing my fingers worrying that the slightest bug would take down the entire runtime. python async absolutely sucks garbage
I can’t understate that last point. I’ve deployed multiple socket apps with Channels to production, and it’s always been a major pain in the ass on the long run. I spent months debugging a memory leak in Django Channels that only happened in production. Turns out an external package, sentry-python, wasn’t playing nice with ASGI. Async Django is painful and slow. I wouldn’t wish it on anyone.
I have more thoughts written down somewhere, but this is off the top of my head.
All in all: it’s been interesting, very fun. There’s tradeoffs to make, especially in productivity and documentation, but I feel they’re all worth it. Today’s apps demand speed, real-time, and concurrency. Django just feels stuck in a time warp from the last decade and Django channels isn’t progressing fast enough (add that async python is painful).
Maintainability and reliability is important for me as a solo maker. I want a resilient web app that can operate without babysitting, I'm a full time student.
Performance matters to me as well. I can't have a memory leak taking down my runtime every hour, or a slow request causing midnight support emails.
Elixir is just pleasantly fast at everything: unit tests are async, the server is concurrent, everything is just blazing..
Realtime is important for me because you don't always need it, but when you do, it's nice to have it. Knowing that Phoenix has a rock solid implementation makes me use it more. It helps me effortlessly make next-gen products.
Elixir and Phoenix come with performance/reliability guarantees, maintainability and new capabilities like flawless real-time that make it all worth it for me. This is my next upgrade to my stack and I’m really happy with it so far.