Ah yes! I wrote a very extensive comment about phoenix vs django and forgot one of the biggest drawbacks of phoenix and ecto: the very very heavy macro usage. This is really problematic. When using Django and get an exception you can see the line that threw and (usually) understand the problem. When using phoenix if the error is on some macro related code, you are lost.
Also in Django you can easily follow the code to understand what's going on under the hood. This is not very easy in phoenix since macros are involved.
Don't get me wrong I understand that macros are used to make the code more ergonomic and avoid repeating stuff. However macros are so complicated and out of my league that I don't even try understanding them.
You should not need an IQ of 150 to understand a web framework. That's the reason phoenix w could never be widely adopted. People need a tool not a way to show off their intelligence.
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.
My 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
I was with until your unnecessary last comment, but I'll respond anyway.
Macros are a pretty important feature of Elixir that helped get it wider adoption. Without them, things become incredibly verbose. While I totally agree they can be hard to grok, there is absolutely nothing magical about them as they are expanded at compile-time. You can call `Macro.expand` on any AST and see the static code it generates.
Otherwise, with a good, well-documented framework like Phoenix, the majority of users should be able to just use it as-is without needing to show off their intelligence by diving into the underlying implementation ;) <3
PS, I've never had a problem when there's an error in a macro. The line in my app that failed is always in the stack-trace which is all I ever need to debug (though I do wish is drew my eye to it somehow).
I know about the verbosity, Erlang is notorious for that. I'd still prefer it over macros. Java is also very verbose, that wasn't a problem with it's adoption :)
Unfortunately for phoenix, when I started learning it I needed to rely on source code to understand some stuff. Trying to walk around the macro stuff was not a cool experience.
Also I did have some macro related errors most related to ecto and its syntax. See this article to understand the problem
Ecto has its own, undocumented syntax. If people from the elixir irc (including the always helpful Jose Valim) wouldn't help me I'd be never be able to guess that thingie...
1. The blog post is great and it shows there is indeed complexity around dynamic filters. I would love to see a solution that tackles it all the way down to form rendering :)
2. All of the Ecto API/syntax used in the blog post is documented, afaik.
3. You mentioned in another comment that Ecto does not support associations in queries, but it does: `join: c in assoc(p, :comments)` and that takes care of the ON condition and anything else you configure.
Thank you for your kind words Jose, going all the way to the form (and table/list) rendering is the ideal for me and would greatly improve my phoenix experience!
Was that syntax documented 3 years ago? I don't really remember but definitely even if it was I couldn't find it. Also you should agree that it's non intuitive.
Finally, you are right about assoc, I don't use it because I prefer the left_join/on syntax but that's not a correct argument .
Also in Django you can easily follow the code to understand what's going on under the hood. This is not very easy in phoenix since macros are involved.
Don't get me wrong I understand that macros are used to make the code more ergonomic and avoid repeating stuff. However macros are so complicated and out of my league that I don't even try understanding them.
You should not need an IQ of 150 to understand a web framework. That's the reason phoenix w could never be widely adopted. People need a tool not a way to show off their intelligence.