4 ms·
While I agree that Ecto is macro heavy, I don’t agree with this assessment for Phoenix. Macros in Phoenix are mostly contained within the router and then Plug (
by josevalim 4y ago
While I agree that Ecto is macro heavy, I don’t agree with this assessment for Phoenix. Macros in Phoenix are mostly contained within the router and then Plug (which is a thin contract).
Perhaps there are other factors that make Phoenix harder to grasp in your experience but I hope pointing out that it may not be macros help peel some of the complexity away.
Furthermore, if you get a bad stacktrace in either Phoenix or Ecto, please open up a bug report. Macros should not and do not imply bad stacktraces. In a very simplistic way, you can think of the Elixir compiler as a huge macro, and it still strives for great error messages and stacktraces. Many Elixir building blocks are implemented with macros too, and we have great error messages and traces there, and we aim for the same in Ecto and Phoenix.
- throwawaymaths 4y agoMy history is that I'm probably one of the few people that did plug before Phoenix, and there are a few places where Phoenix can break your brain when you're coming to it... The organization (templates, views, controllers) is out of whack from what one "normally" does in elixir, and some of the "use X" to set defaults make it really hard to deviate from Phoenix back to what you would expect from elixir (Module.Alias.Alias => module/alias/alias) and some things are "basically impossible", like if you want to organize to Controllers.ABC instead of ABC.Controller. Router helpers are also kind of a truck. It took me years to understand why you would want them and I still often just hardcode routes in the templates. Some things in Phoenix are relatively hard if you want to have multiple endpoints in the same app without doing an umbrella. On the other hand they say consistency is the hobgoblin of the small mind, so I might be guilty as charged in my quest for consistency