I’ve been playing with a toy Phoenix project lately, and manually tore out the Postgres Repo stuff, but kept Ecto because initially I wanted to generate UUIDs and it was convenient for that. Now I’m finding Ecto’s Schema and Changeset modules very convenient for request parameter validation–they let me build up a list of validation errors and send that back to the client.
Phoenix’ modular nature is quite nice for exploration and finding serendipitous uses.
I will try and make the time to add a Goals/motivation section to the Raxx readme in the next few days that I can reuse. For the moment my talk from elixir daze I think is my best explination.
For this conversation maybe I will try approaching from another direction. Quote from the original question.
@ricosuaveyatusabe what was the trigger for you to ask about lightweight alternatives, when you were already familiar with Phoenix?
@Crowdhailer
Doing things really quick for illustrating examples and things like that. Not having to spend time in explaining Phoenix or just assuming the reader already understand Phoenix. Just coding something simple like get("/users) calls i_dont_care.gimme_users(). This helps me coding examples in the most language agnostic way.
They’d probably accept a template that is full of commented code that says things like Uncomment this to do Blah <link here> and so forth. 
In the meantime, a colleague scratched our own itch during our last hackday using exgen which seems to be either very unmaintained or very stable - a quickie PR made it work for us and we now have that very minimal phoenix(+statix, +our stuff like circle, nomad job files) core we can build out a service from. Works quite nicely and saves me from going through the trouble of somehow tacking more options on phx.new 
Yup, it’s probably the same. The hard part here, of course, is not creating the solution but maintaining the templates
I’ve been thinking about these discussions, and it occurs to me that a good way to describe Phoenix might be as a thin & light framework built over a rich & powerful set of libraries.
That’s a less-verbose and perhaps easier-to-understand way of making the point that Phoenix does not hide things behind “too much” magic, does not have “too much” coupling between components–thus not “too hard” to figure out how components are used, and remove them or tweak the usage of them.
I am always about to say “Phoenix is a handful of libraries and some conventions expressed in the skeleton code it generates” but then I’m afraid that “convention” might have bad associations since Rails…
Just tried it.
.
./mix.exs
./rel
./test
./test/support
./test/support/conn_case.ex
./test/test_helper.exs
./lib
./lib/api
./lib/api/application.ex
./lib/api/error_view.ex
./lib/api/router.ex
./lib/api/endpoint.ex
./lib/api.ex
./README.md
./config
./config/dev.exs
./config/config.exs
./config/deploy.exs
./config/test.exs
Are the relevant Phoenix parts we spit out. Also, in api.ex we just have the controller and router macros left. cloc counts it at 180 lines of Elixir code.
To me, the best thing is: it’s still Phoenix! And we can grow templating and channels and whatnot right back.