phoenix

ques above, but Phoenix errs more on code generation and Rails more on configuration. Here is a practical example. Rails has a middleware stack that is part of all applications. This stack is hidden from you. Here is how the generator file for said application looks like: https://github.com/rails/rails/blob/d0d9e8e576b06c19f8507510... Phoenix has a similar stack (called plug) and the default stack is part of your application. Here is the generator file for it (it is not part of your app but used to generate it): https://github.com/phoenixframework/phoenix/blob/3c27a34c27c... You can look at these approaches and try to compare the pros and cons. --- My biased opinion: I have worked with both and I prefer the Phoenix approach. I understand someone may find having all steps in your endpoint noisy or daunting, but the plus side is that it takes a glance to see all steps a request goes through and you can tweak it in any way you want. When comparing to Rails, if you want to insert a middleware in the middle of the default stack, you need to explicitly say before or after which middleware. If you want remove something, you need to state the negation and say "I don't want to have this". Overtime this makes it hard for you to visualize what your application does, because you need to assemble the pieces in your head and use tools to print the stack for you. This also matters on releasing new framework versions. Because Rails has its own stack, if it changes the default middleware stack in any way, it can slightly change how your code. What if the middleware you were inserting before was moved up? Or removed altogether? Or maybe a middleware you deleted was replaced by another one, with similar functionality. Do you want to remove it too? This can lead to subtle differences of behaviour when upgrading. The code generation approach requires you to opt-in to the new features, which is, IMO, one of the reasons why Phoenix could avoid breaking changes in the last 8 years or so. This is in no way a knock on Rails. I am 100% confident the Rails team is aware of those trade-offs and could equally argue for their choices. It also isn't a binary choice either, both frameworks use both approaches, with some general preferences for one over the other.

ne takes <10s to run (compile, test, create and push image to a registry). This workflow is such a game-changer. It also allows, fairly easy, to do very complicated flows [1]. I've tried to get started with dagger but I don't use the currently supported SDK's and the cue-lang setup was overwhelming. I think I like the idea of a more sane syntax from dagger, but Earthly's approachability [2] just rings true. [1]: https://github.com/phoenixframework/phoenix/blob/master/Eart... [2]: https://earthly.dev/blog/platform-values/#approachability