4 ms·

We use phoenix for a few years or so, and it’s very decent. I disagree strongly with the crowd that says it’s the best thing since sliced bread, it’s, well, jus

We use phoenix for a few years or so, and it’s very decent. I disagree strongly with the crowd that says it’s the best thing since sliced bread, it’s, well, just a framework. It has the basics for oldschool mvc and real-time stuff, and for the rest you just write regular elixir code. It has some weird naming quirks and, to my taste, a bit too much macro magic but nothing that can’t be learned in a few days. I don’t mean to downplay the humongous effort that goes into building any framework that doesn’t suck. Phoenix very much doesn’t suck. But it simply got all the basic right and then the true benefits come from it running in elixir/beam, which means you can skip all the job runners, redises, microservices etc. I don’t know where you got the idea from that something is up with it. It’s chugging along great.

namaria 4y ago
>I don’t mean to downplay the humongous effort that goes into building any framework that doesn’t suck. I think you captured something I've been mulling about recently. The perception of software quality should be on an inverted scale, like incident severity where zero is the worst possible outcome. Software can't be better then "works well, has little accidental complexity". But it can be much worse than that. People rave about pieces of software that do their job and get out of the way because they're so rare, and not because they are magical unicorns that cook you breakfast and give you massages. But because they fulfill expectations at a reasonable cost.
spapas82 4y ago
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.
- sodapopcan 4y ago
  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).
  - spapas82 4y ago
    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 https://www.spapas.net/2019/07/25/declarative-ecto-query-filters/ https://www.spapas.net/2019/07/25/declarative-ecto-query-fil... 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...
    - josevalim 4y ago
      Quick feedback: 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.

namaria 4y ago

>I don’t mean to downplay the humongous effort that goes into building any framework that doesn’t suck. I think you captured something I've been mulling about recently. The perception of software quality should be on an inverted scale, like incident severity where zero is the worst possible outcome. Software can't be better then "works well, has little accidental complexity". But it can be much worse than that. People rave about pieces of software that do their job and get out of the way because they're so rare, and not because they are magical unicorns that cook you breakfast and give you massages. But because they fulfill expectations at a reasonable cost.

spapas82 4y ago

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.

sodapopcan 4y ago
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).
- spapas82 4y ago
  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 https://www.spapas.net/2019/07/25/declarative-ecto-query-filters/ https://www.spapas.net/2019/07/25/declarative-ecto-query-fil... 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...
  - josevalim 4y ago
    Quick feedback: 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.