What is your ultimate goal though? Smaller .beam files? Performance gains? Easier to recover from exceptions (I don’t quite get that.) Another coding style? (I think we can all agree this is subjective but worth the effort regardless if you find yourself more productive in the end.) I understand the argument for a Plug replacement that deals better with sockets and channels – carrying easily accessible metadata at all times if I got it correctly – but outside of that I seriously can’t understand what is it that Raxx does better (and I think I spotted Jose or Michal saying the next Plug / Phoenix will address these issues Soon™).
I have been reading your posts and comments last month or so and I still cannot understand what is your objection to Phoenix. I am not raining on your parade. Maybe I am just dumb and can’t grasp the idea. Will you help me understand? (I did read your threads here btw, but not your blog.)
Maybe you don’t but you have been repeating that Raxx is better suited for certain use cases and I am yet to see something that will convince me of this claim. Do you have a quick and self-explanatory example that shows when Raxx is a better fit than Plug / Phoenix?
As @cdegroot mentions, you can very easily reduce Phoenix’s generated files and still use most of it (and most of its “boilerplate” are optional convenience helpers anyway, they are not mandatory the way Rails makes most of itself mandatory if you wanna use it).
This is not about democracy or consensus. Give us pieces of info that help people make an informed decision. Alternatives are good, they challenge the thinking of people and make them see new horizons.
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.
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
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…
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.
You’re right of course that the conventions are important, they make it easy to tie together the libraries and contribute to the “framework’ish” part being so small.
