I find this a pretty unconvincing comment, bordering on bad faith. A lot of vaguely defined negatives with no details.
> Deploying Phoenix is a nightmare when compared to Laravel.
It ships with a Dockerfile which is simple to deploy if you know docker at all. How is this a nightmare exactly?
> In Phx you have to reinvent a lot of things and often, of course, choosing the wrong path.
Like what? Give examples. I find the ecosystem pretty well developed, actually.
> Also, Phoenix is bad in environments with bad wi-fi.
Do you mean the (optional) liveview, which your preferred framework Laravel is in the process of also implementing with blade/livewire?
Programmed in a reasonably defensive way, Liveview will perform and behave mostly like any SPA application - often better, because there's less front end code to load up front. Of course, in cases where internet access is known in advance to be bad, it should probably not be used. This will be a pretty rare case, though.
> The experience with 1.6 and 1.7 rc was bad
The RC process was long, yes, but how can you fault the framework for this? What could they have done differently? It sounds like you wouldn't be happy either way?
> PHP is made for sloppy web programmers (like me).
I think I know why you didn't have a great experience with Phoenix.
I actually found it informative. It gave me a quick overview of the issues with this famous web framework that I would probably not find anywhere else.
Genuinely curious, but which part was informative of anything other than one users opinion? I'm a huge fan of elixir and found it to be one of the easiest languages[1] I've learned to date, so I'm definitely biased, but I'm struggling to find anything in GP's post that is informative in an objective way (outside of the tutorial thing that presumably posts more content).
I believe I could replace php/laravel with elixir/phoenix in GP's post and be subjectively just as correct in stating my opinion.
[1] the easiest standard library to learn...the OTP library is often treated as a core part of the language and that did take a fair amount of learning before it clicked.
Yes, it is a bit of a ranty comment. Yes, it shares their opinion alone. That is quite clear. And yes, there might be different opinions out there.
But in the midst of their opinion, they raise awareness to a point not much talked in the tutorials or other material I've seen about Phoenix: it might seem easy, but has it's drawbacks. Drawbacks which could be easily avoided by power users, but might not seem obvious to a newcomer. That's it. The rest is description of such drawbacks, from the poster's perspective.
I find this informative because it is information that I haven't seen anywhere else. Not in tutorials, not in presentations, not in any other place I've seen people talking about the subject.
Of course after thinking for a while it becomes obvious that a framework built on such a "different" platform with it's own unique patterns and quirks would of course fit such a description. Any tech could, depending where you're coming from. That's OK. And it is also OK that enthusiasts of any tech would not present themselves in such a harsh way. It's all good.
> "different" platform with it's own unique patterns and quirks
Much of what OP listed was a criticism directed at LiveView, the 'Live App' functionality, not Phoenix, the web framework. Live Apps are not exclusive to Phoenix either, as there are now imitators for every other web framework now, which at least speaks to its broader appeal amongst developers. So the criticism could be leveled towards the far less mature 'Live App' libraries on PHP/Python/JS/C# and so on and on:
As for lack of documentation, I find this a strange criticism to level at the Elixir ecosystem. It's documentation tooling is very good, and so libraries are typically very well documented, and often include 'doc tests' which double as both examples of usage and inline unit tests. You can simply launch the REPL (called IEx) and type `h <module>.<name of function>` and get documentation for any function.
As for the language, I think immutability and using GenServers could be a little counter-intuitive to people used to mutating variables inside of loops and using shared singletons, but elixir-lang.org and Exercism provide very approachable learning materials for understanding the language.
> they raise awareness to a point not much talked in the tutorials or other material I've seen about Phoenix: it might seem easy, but has it's drawbacks.
> the OTP library is often treated as a core part of the language and that did take a fair amount of learning before it clicked.
For me, probably the 2 most foreign concepts coming in with a non-functional mindset were GenServers and tail-recursion. They require a shift in mindset about how to handle state and do flow control. These two things would be stumbling blocks to beginners, especially someone who claims to prefer "sloppy" code
Ah yeah sorry, you're right. It was actually the GGP talking about OTP that inspired me to write the comment, but it is actually relevant to the immutable aspect of Elixir (which is something you don't really see outside FP) as GenServer provides a way to keep state via named processes the way someone might use global variables or singletons.
tail-recursion is just an implementation detail...but with recursion, I find non-programmers struggle no more with them than simple loops. It's only programmers who develop a strong familiarity with loops that feel some sense of unnecessary friction. Neither are more than code that says "do this thing until this condition is met"
I agree. As I said it’s those programmers coming in from non-functional languages (likely the majority). When you’re conditioned to using for loops with mutation, it can feel strange to use these new patterns. I think comprehensions, map, and reduce are becoming more common in other non-functional languages, so maybe newer programmers would instinctively reach for these first.
> informative [...] of the issues with this famous web framework
The conflation of LiveView with Phoenix web framework is dangerous misinformation. LiveView is just a subset of Phoenix, with very specific trade-offs and unfamiliar programming patterns compared to usual web development. I've found Phoenix to be very productive for regular web programming.
> Deploying Phoenix is a nightmare when compared to Laravel.
It ships with a Dockerfile which is simple to deploy if you know docker at all. How is this a nightmare exactly?
> In Phx you have to reinvent a lot of things and often, of course, choosing the wrong path.
Like what? Give examples. I find the ecosystem pretty well developed, actually.
> Also, Phoenix is bad in environments with bad wi-fi.
Do you mean the (optional) liveview, which your preferred framework Laravel is in the process of also implementing with blade/livewire?
Programmed in a reasonably defensive way, Liveview will perform and behave mostly like any SPA application - often better, because there's less front end code to load up front. Of course, in cases where internet access is known in advance to be bad, it should probably not be used. This will be a pretty rare case, though.
> The experience with 1.6 and 1.7 rc was bad
The RC process was long, yes, but how can you fault the framework for this? What could they have done differently? It sounds like you wouldn't be happy either way?
> PHP is made for sloppy web programmers (like me).
I think I know why you didn't have a great experience with Phoenix.