9 ms·

I've got experience in both Phoenix and Django and I disagree. In my view, Phoenix is the less clean one: Django does not generate anything through scaffolding

I've got experience in both Phoenix and Django and I disagree. In my view, Phoenix is the less clean one: Django does not generate anything through scaffolding like Phoenix. Your CRUD (and auth and forms and everything more or less) is generated by overring the built-in Django classes or the classes offered by the packages. Nothing gets thrown away in real production; you use your class hierarchy to change it to your requirements. I know that inheritance and polymorphism seems like a 90's technology but this actually is a solved problem in web frameworks and does work excellent. On the other hand, I agree with you that everything that Phoenix generates through its phx.gen generators are for demo purposes and will get thrown away eventually. This, along with the fact that everything is a function results in having to re-invent the wheel multiple times in your project without any saferails on how to actually architecture it. Should I use a context? What to put there? What's the point of views? Oh views are removed now? So, unless you are really very careful or have much experience/guidance this will result to a total mess. The batteries included aspect of Django means that if you are a novice developer and follow the best practices you'll get a fine project without too much effort. It isn't really about the batteries, it's about the fact that you'll know how to implement each thing you need in a web project. I can confirm to that that because we've got 12-year old production running Django projects which were developed by a totally novice Django developer (me). Try to do that in Phoenix (still being a novice developer). Now I don't want to abolish Phoenix. It's a fine framework considering its age and its popularity and number of people contributing to. However you must be very careful before considering to use it for a real project that will be used and supported for the years to come, expecially if your alternative is something as proved as Django. Personally, I use Phoenix only on projects where its real-time capabilities will be the protagonist.

AlchemistCamp 4y ago
> “On the other hand, I agree with you that everything that Phoenix generates through its phx.gen generators are for demo purposes and will get thrown away eventually.” The parent didn’t say that and it’s not true in my experience writing Phoenix apps over the past six years. I usually add to the generated contexts, controllers or now live views, but I often leave the migrations as is. Even when making a migration to edit an existing schema, I still use the Ecto generators. The _only_ thing I’ve often thrown away large parts of was the template. I’ve taken over about as bad of a Phoenix app as you can imagine (made by a rotating cast of outsourced contractors over years, no use of Ecto relations, no use of “resources” (just get and post), not using built-in validations, pinned to a version of LiveView from two months after its initial release… and using jQuery to drive it). Due to Elixir’s immutable, functional nature, rehabilitating the code base has actually been a bit easier than some Django apps I’ve seen. The most painful part has been unraveling the jQuery. IMO, Django still hasn’t caught up with 2014 Rails.
- freedomben 4y ago
  My experience as well. The generated code is absolutely kept and used (excepting the template, but even that serves as a nice example to follow for people who are newer). Mainly the only changes are to add validation code and some business logic here or there depending on how complex the behavior needs to be (again mainly validation). The generated code is a big help, and we still use it for every new model despite being able to easily add new stuff manually.
josevalim 4y ago
> Django does not generate anything through scaffolding like Phoenix I was one of the co-authors of Devise, which is an integrated authentication solution for Rails (similar in spirit to Django), and you will easily find people who swear that the code generation solutions are miles better. That’s because eventually they’d want to customize how the framework or library work and then, instead of simply being able to change the code, you need to find the exact hook or configuration to get the behavior you want. Eventually, you end up with hodgepodge of changes that you can only understand when looking at the framework and your code side-by-side. Perhaps this is one of the topics where there is no “superior” answer, besides personal preferences and past experiences. I totally understand why someone would prefer Django or Devise, but our premise is that eventually you will want to customize it, therefore giving you control upfront is the better way to go about it. However, I would say it is incorrect to say they are for demo purposes in both Phoenix and Django cases, as there is plenty of evidence otherwise. It is also a matter of framework philosophy. Phoenix aims to give all the necessary foundation for building applications, and then not get in your way, rather than owning all aspects of your application lifecycle. I believe frameworks like Ash (which also runs on Phoenix) take the latter approach. > Oh views are removed now? To clarify, Views are not removed. Phoenix is still MVC. The difference is that the templates in your view are defined via `use Phoenix.Template`, rather than `use Phoenix.View`. You can migrate (or not) at your convenience.
- AlchemistCamp 4y ago
  Is there a channel where we can share suggestions for the upgrade guide? I think it would save people some time if the phx 1.6 -> phx 1.7 upgrade instructions started with the following two steps: 1.) Upgrade LiveView to 0.18.x (with link to https://hexdocs.pm/phoenix_live_view/changelog.html#0-18-0-2022-09-20 https://hexdocs.pm/phoenix_live_view/changelog.html#0-18-0-2...) 2.) Update web.ex macros for Phoenix Component (with link to https://hexdocs.pm/phoenix_view/Phoenix.View.html#module-replaced-by-phoenix-component https://hexdocs.pm/phoenix_view/Phoenix.View.html#module-rep...) Then the upgrade doc will work and people won’t get stuck trying to follow those instructions with a Phoenix 1.6 app using whatever version of LiveView they had before.
  - 4y ago
college_physics 4y ago
> I use Phoenix only on projects where its real-time capabilities will be the protagonist Yep, that feels sound advice (and motivation). I would add more broadly "federation capability" (in the style of the fediverse / activitypub but also wherever that decentralization path might take us in the near future) as an important dimension to look into. Remains to be seen if the "telecoms/erlang" pedigree of elixir is a critical element in this respect. There are already some important projects based on elixir [0] [1] but also some django based efforts [2] [3]. [0] https://bonfirenetworks.org/docs/architecture/ https://bonfirenetworks.org/docs/architecture/ [1] https://docs.joinmobilizon.org/administration/install/source/ https://docs.joinmobilizon.org/administration/install/source... [2] https://docs.funkwhale.audio/stable/installation/ https://docs.funkwhale.audio/stable/installation/ [3] https://docs.jointakahe.org/en/latest/installation/ https://docs.jointakahe.org/en/latest/installation/
- freedomben 4y ago
  It is only sound advice if you already know Python/Django really well and don't mind context-switching your language. If you know Elixir/Phoenix well, you can easily crank out simple sites that don't use any real-time stuff as well as any other framework, and you get the added benefit of blazing fast (pre-compiled) templates and a highly robust database connection pool. Personally I prefer to keep as much as possible in the same language/ecosystem rather than having to straddle.
  - college_physics 4y ago
    sticking within a single capable ecosystem is optimal here-and-now but your mileage might vary as we go forward. its always hard to forecast but even if you discount alot of the ML/AI hype, its quite likely that 2-3 years from now expectations will be for much "smarter" services. whether delivering such upgrade can be achieved with microservices and API's or whether a platform can deliver functioning "monoliths" that compete also in such a new landscape is not clear (not to me anyway)
bboygravity 4y ago
> I use Phoenix only on projects where its real-time capabilities will be the protagonist. As a web user (not dev) I would say real-time (as in super fast?) should always be the protagonist? To me that's the most important factor that makes the difference between nice and shtty website.
- spapas82 4y ago
  Not really. Real time is not the same as super-fast. You can be real time but super slow or super fast using traditional request/response web apps. When I mentioned real-time I was talking about apps that need to use web sockets to have fast client-server communication. There aren't many apps where this is required (or worth it).
- traverseda 4y ago
  Real time like a chat app, or a video game or something. Not just a fast site. Seems like most "real-time" sites are slower as they have a harder time taking advantage of caching and the like, or use a lot of slow client-side javascript that inevitably works poorly. Basically if you need the server to be able to change the data a user is currently looking at, collaborative multi-user stuff mostly. Liveview could be great if you're building google docs, but you could probably build youtube using just a more traditional framework like django.
  - mixmastamyk 4y ago
    Been looking at CRDTs lately for this, sounds like Elixir would be a good fit. Although what I've seen before has used C++ or Rust? to compile to wasm for the graphics part of the front end. Do all these technologies work together well?
    - AlchemistCamp 4y ago
      Phoenix has used CDRTs going back to version 1.2 when Phoenix Presence was introduced. Here's a podcast about it (2016): https://changelog.com/podcast/208 https://changelog.com/podcast/208
noloblo 4y ago
Elixir haskell and erlangs concurrency and parallelism story far outweigh any imperative pythonic benefits or idioms IMHO
- Daishiman 4y ago
  Concurrency is a pet use case for 99% of projects. Library ecosystem is the primary and dominant factor when choosing general-purpose technologies and Python has it beat.
  - deleted 4y ago
    [deleted]
  - noloblo 4y ago
    In a multi core world concurrency and parallelism are no longer pet use cases. Unfortunately The slowness of python, gil and really bad design choices of Asyncio in python 3 relative to how elegant parallelism and concurrent programming is in Racket, haskell, elixir and erlang make python a non starter for many basic use cases
    - noloblo 4y ago
      https://edisciplinas.usp.br/pluginfile.php/5023569/mod_resource/content/1/functionalprogrammingwithelixir-160823015455.pdf https://edisciplinas.usp.br/pluginfile.php/5023569/mod_resou... elixir fp pdf that helps clarify why is more elegant than python or cpp
    - Daishiman 4y ago
      This is absolutely not true, because most of the industry uses Python for web services and serving web pages is still the same thing as it was 20 years ago. You scale by bringing in more processes. Multicore concurrency is still a pet use case because high performance is still a minority of applications and async programming is not necessarily faster, per many benchmarks. Most companies will rewrite the high-performance component in the proper manner and continue to do everything else the way they did.

AlchemistCamp 4y ago

> “On the other hand, I agree with you that everything that Phoenix generates through its phx.gen generators are for demo purposes and will get thrown away eventually.” The parent didn’t say that and it’s not true in my experience writing Phoenix apps over the past six years. I usually add to the generated contexts, controllers or now live views, but I often leave the migrations as is. Even when making a migration to edit an existing schema, I still use the Ecto generators. The _only_ thing I’ve often thrown away large parts of was the template. I’ve taken over about as bad of a Phoenix app as you can imagine (made by a rotating cast of outsourced contractors over years, no use of Ecto relations, no use of “resources” (just get and post), not using built-in validations, pinned to a version of LiveView from two months after its initial release… and using jQuery to drive it). Due to Elixir’s immutable, functional nature, rehabilitating the code base has actually been a bit easier than some Django apps I’ve seen. The most painful part has been unraveling the jQuery. IMO, Django still hasn’t caught up with 2014 Rails.

freedomben 4y ago
My experience as well. The generated code is absolutely kept and used (excepting the template, but even that serves as a nice example to follow for people who are newer). Mainly the only changes are to add validation code and some business logic here or there depending on how complex the behavior needs to be (again mainly validation). The generated code is a big help, and we still use it for every new model despite being able to easily add new stuff manually.

josevalim 4y ago

> Django does not generate anything through scaffolding like Phoenix I was one of the co-authors of Devise, which is an integrated authentication solution for Rails (similar in spirit to Django), and you will easily find people who swear that the code generation solutions are miles better. That’s because eventually they’d want to customize how the framework or library work and then, instead of simply being able to change the code, you need to find the exact hook or configuration to get the behavior you want. Eventually, you end up with hodgepodge of changes that you can only understand when looking at the framework and your code side-by-side. Perhaps this is one of the topics where there is no “superior” answer, besides personal preferences and past experiences. I totally understand why someone would prefer Django or Devise, but our premise is that eventually you will want to customize it, therefore giving you control upfront is the better way to go about it. However, I would say it is incorrect to say they are for demo purposes in both Phoenix and Django cases, as there is plenty of evidence otherwise. It is also a matter of framework philosophy. Phoenix aims to give all the necessary foundation for building applications, and then not get in your way, rather than owning all aspects of your application lifecycle. I believe frameworks like Ash (which also runs on Phoenix) take the latter approach. > Oh views are removed now? To clarify, Views are not removed. Phoenix is still MVC. The difference is that the templates in your view are defined via `use Phoenix.Template`, rather than `use Phoenix.View`. You can migrate (or not) at your convenience.

AlchemistCamp 4y ago
Is there a channel where we can share suggestions for the upgrade guide? I think it would save people some time if the phx 1.6 -> phx 1.7 upgrade instructions started with the following two steps: 1.) Upgrade LiveView to 0.18.x (with link to https://hexdocs.pm/phoenix_live_view/changelog.html#0-18-0-2022-09-20 https://hexdocs.pm/phoenix_live_view/changelog.html#0-18-0-2...) 2.) Update web.ex macros for Phoenix Component (with link to https://hexdocs.pm/phoenix_view/Phoenix.View.html#module-replaced-by-phoenix-component https://hexdocs.pm/phoenix_view/Phoenix.View.html#module-rep...) Then the upgrade doc will work and people won’t get stuck trying to follow those instructions with a Phoenix 1.6 app using whatever version of LiveView they had before.
- 4y ago

college_physics 4y ago

> I use Phoenix only on projects where its real-time capabilities will be the protagonist Yep, that feels sound advice (and motivation). I would add more broadly "federation capability" (in the style of the fediverse / activitypub but also wherever that decentralization path might take us in the near future) as an important dimension to look into. Remains to be seen if the "telecoms/erlang" pedigree of elixir is a critical element in this respect. There are already some important projects based on elixir [0] [1] but also some django based efforts [2] [3]. [0] https://bonfirenetworks.org/docs/architecture/ https://bonfirenetworks.org/docs/architecture/ [1] https://docs.joinmobilizon.org/administration/install/source/ https://docs.joinmobilizon.org/administration/install/source... [2] https://docs.funkwhale.audio/stable/installation/ https://docs.funkwhale.audio/stable/installation/ [3] https://docs.jointakahe.org/en/latest/installation/ https://docs.jointakahe.org/en/latest/installation/

freedomben 4y ago
It is only sound advice if you already know Python/Django really well and don't mind context-switching your language. If you know Elixir/Phoenix well, you can easily crank out simple sites that don't use any real-time stuff as well as any other framework, and you get the added benefit of blazing fast (pre-compiled) templates and a highly robust database connection pool. Personally I prefer to keep as much as possible in the same language/ecosystem rather than having to straddle.
- college_physics 4y ago
  sticking within a single capable ecosystem is optimal here-and-now but your mileage might vary as we go forward. its always hard to forecast but even if you discount alot of the ML/AI hype, its quite likely that 2-3 years from now expectations will be for much "smarter" services. whether delivering such upgrade can be achieved with microservices and API's or whether a platform can deliver functioning "monoliths" that compete also in such a new landscape is not clear (not to me anyway)

bboygravity 4y ago

> I use Phoenix only on projects where its real-time capabilities will be the protagonist. As a web user (not dev) I would say real-time (as in super fast?) should always be the protagonist? To me that's the most important factor that makes the difference between nice and shtty website.

spapas82 4y ago
Not really. Real time is not the same as super-fast. You can be real time but super slow or super fast using traditional request/response web apps. When I mentioned real-time I was talking about apps that need to use web sockets to have fast client-server communication. There aren't many apps where this is required (or worth it).
traverseda 4y ago
Real time like a chat app, or a video game or something. Not just a fast site. Seems like most "real-time" sites are slower as they have a harder time taking advantage of caching and the like, or use a lot of slow client-side javascript that inevitably works poorly. Basically if you need the server to be able to change the data a user is currently looking at, collaborative multi-user stuff mostly. Liveview could be great if you're building google docs, but you could probably build youtube using just a more traditional framework like django.
- mixmastamyk 4y ago
  Been looking at CRDTs lately for this, sounds like Elixir would be a good fit. Although what I've seen before has used C++ or Rust? to compile to wasm for the graphics part of the front end. Do all these technologies work together well?
  - AlchemistCamp 4y ago
    Phoenix has used CDRTs going back to version 1.2 when Phoenix Presence was introduced. Here's a podcast about it (2016): https://changelog.com/podcast/208 https://changelog.com/podcast/208

noloblo 4y ago

Elixir haskell and erlangs concurrency and parallelism story far outweigh any imperative pythonic benefits or idioms IMHO

Daishiman 4y ago
Concurrency is a pet use case for 99% of projects. Library ecosystem is the primary and dominant factor when choosing general-purpose technologies and Python has it beat.
- deleted 4y ago
  [deleted]
- noloblo 4y ago
  In a multi core world concurrency and parallelism are no longer pet use cases. Unfortunately The slowness of python, gil and really bad design choices of Asyncio in python 3 relative to how elegant parallelism and concurrent programming is in Racket, haskell, elixir and erlang make python a non starter for many basic use cases
  - noloblo 4y ago
    https://edisciplinas.usp.br/pluginfile.php/5023569/mod_resource/content/1/functionalprogrammingwithelixir-160823015455.pdf https://edisciplinas.usp.br/pluginfile.php/5023569/mod_resou... elixir fp pdf that helps clarify why is more elegant than python or cpp
  - Daishiman 4y ago
    This is absolutely not true, because most of the industry uses Python for web services and serving web pages is still the same thing as it was 20 years ago. You scale by bringing in more processes. Multicore concurrency is still a pet use case because high performance is still a minority of applications and async programming is not necessarily faster, per many benchmarks. Most companies will rewrite the high-performance component in the proper manner and continue to do everything else the way they did.