Or something right, if you enjoy working on them as much as you indicate

At the end of the day, though, a HUGE % of B2B companies fall into 1 of 2 buckets:

1. A domain-specific, context aware, edit-history-enabled pretty replacement for an Excel spreadsheet that powers an entire industry
2. A domain-specific, context aware, edit-history-enabled pretty replacement for a single python script + an Excel spreadsheet that powers an entire industry

Find an industry with such a spreadsheet-driven workflow, and:

• put the spreadsheets in a database
• access it with CRUD
• track modification history from form submissions
• use domain knowledge to empower better visualizations

and you have a successful startup! For more advanced usecases, encode the script in a background job framework and you’re good to go.

This is clearly a very common need, so I am grateful that Phoenix (+ Oban) cover these usecases thoroughly, in case I end up working on such a project again, though I do avoid them as well.

The only generator I use day to day is mix ecto.gen.migration everything else is build as I need it. None of the generators produce even close to what we have for our admin panel and structuring. That has been my experience with generators (rails, django, phoenix, etc…) for the last 8 years.

At the end of the day, generators are just a way of copying somebody else’s code into your project. That will always require that your code style/conventions/structure match theirs to work out of the box.

I would rather copy my own project’s code with its own existing style/conventions/structure, so I essentially only use generators very early on in a project, to get the latest dependencies/configuration/wiring from the excellent phoenix generators, since phoenix and especially liveview is still iterating fast (though we are due for a liveview 1.0 soon so I expect this to slow down dramatically).

By the time I have a roughly working initial project setup, I’ve modified these generated defaults and conventions to suit my needs enough that I can copy my own code as a “template”. I pretty much only use the ecto migration generator from there on out, mostly so that I don’t have to generate my own timestamps for migration names. (Even then I write most migrations in pure SQL, so completely replace the migration DSL inserted into those files.)

One reason I ditch the generators very early on is because I never actually want to use Phoenix’s namespacing/context conventions, so pretty much any initial codebase I write quickly strays from their conventions, you may get more milage if you follow them.