Hacker News Reader

> 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.

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-2...)

2.) Update web.ex macros for Phoenix Component (with link to 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.

I updated my example Docker / Phoenix app from 1.6 to 1.7 this morning.

I put it all into 1 commit: https://github.com/nickjj/docker-phoenix-example/commit/3733...

There were a number of things not covered in the upgrade guide. Lots of small changes between what the new app generator provides, csrf tokens being set in a different way, etc..

Please open up an issue.

Okay! Will do.

With Phoenix 1.7 being released, will there be a new edition of "Programming Phoenix"? The latest one covers Phoenix 1.4, which is already slightly outdated. I think having an up-to-date book would be of great value for Phoenix beginners :)

The same publisher has a "Programming Phoenix LiveView" book, which is probably your best bet at this point.

I don’t think 1.7 is officially out yet as it’s sitting at rc-3.

It's been released yesterday :) https://phoenixframework.org/blog/phoenix-1.7-final-released

Nice.

It didn't seem to have really made the frontpage of HN despite a lot of votes.

> instead of simply being able to change the code, you need to find the exact hook or configuration to get the behavior you want.

I don't think that this is a bad thing. This is the purpose of a framework. To extend its functionality. If I wanted to re-write everything (or change the generated scaffolds) then I'd skip the framework and use libraries directly.

I'd like to point out the biggest problem with scaffolding: Let's suppose I use scaffolding to generate a scema / database table in phoenix, along with all the bells and whistles. I'm happy; instant code. I customize all the scaffolds as I like (i.e change html layouts, fix the schema/migration for fks, fix the queries, improve forms etc). I'm happy; everything works as I like. After 1 hour I notice understand that my table is missing a field. I'm sad. Now I've got two equally sad options:

* Delete everything that phoenix has generated for me, drop the schema, re-generate the scaffold (with the new field) and re-apply all my customizations or * Add the field myself by adding a migration, adding it to the schema, fixing the tests, adding it to changesets, fixing the templates, fixing the queries and praying I haven't forgotten anything.

Now I'm very sad.

What would happen in that case (forgot a field in the database) in Django? Add the field to the model and re-run the migrations. That's it. Happy days!

> You can migrate (or not) at your convenience

Yes, I know that the views are still there but my understading is that they won't be generated anymore (so the steer is to not use them anymore, at least for new code). However, my main argument was that Django is better at holding your hand to produce acceptable code even if you are not experienced with the framework nor you have mentoring. The fact that now you have even more options (i.e you can use views if you want and think you need them) strengthens that argument.

If you need to change it, you would add it to the migration, schema, and then in the necessary templates. Some fields are private, read-only, etc. so you would change your templates accordingly. Some fields you want to change via a button press, others via a form, and so on. The whole point is that you can evolve the generated structure based on your needs.

> (i.e you can use views if you want and think you need them)

I was mostly speaking about existing applications. New applications have a clear path forward.

I don’t think this strengthens your argument the way you think. I _bet_ Django also has features that were used in the past and are no longer favored now, but still supported for backwards compatibility. This is in no way a phenomenon exclusive to Phoenix.

If your argument is that a configurable framework is easier than code gen for beginners, I agree. But that said, you don’t seem to be acknowledging the fundamental tradeoff which cuts both ways. Ultimately it depends on how close you want to stay to the paved path. I’ve built enough web products at this point that I’d rather have auth primitives than a configurable framework as the latter will be way more complicated than necessary to meet my needs.

For me it comes down to keeping business logic out of my framework. The logical extension of the framework + hooks model can be seen in something like Drupal. You can get amazing volumes of functionality launched quickly, but the UX is ERP-like in its rigidity. Obviously Django is not like this in the large, and the auth/admin stuff are much higher power-to-weight ratio than anything in Drupal, but it’s an interesting case study in looking at the implications of drawing different logical boundaries between framework and application.

> “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.

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.

> 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/

[1] https://docs.joinmobilizon.org/administration/install/source...

[2] https://docs.funkwhale.audio/stable/installation/

[3] https://docs.jointakahe.org/en/latest/installation/

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.

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)

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

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.

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

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.

>> Most companies will rewrite the high-performance component in the proper manner and continue to do everything else the way they did.

they do and when they need it is not in python or asyncio wonder why it is usually in cpp,java,erlang,elixir,haskell ?

Nobody's writing production Haskell or Erlang for this save maybe a half-dozen companies; it's all C++ or Java, and it represents a very small minority of the code as critical paths are usually tiny slivers of a codebase.

isn't that changing with elixir seeing a huge resurgence and haskell with tweag/well-typed/serokell success stories?

https://edisciplinas.usp.br/pluginfile.php/5023569/mod_resou... elixir fp pdf that helps clarify why is more elegant than python or cpp

> 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.

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.

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?

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

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).