Article summary
Functional programming has been successful through React and its derivatives on the front end. Why can’t we embrace it for the full stack? The solution for traditional model-template-view applications can be functional, too. A good incumbent is the Elixir language with Phoenix framework.
There are plenty of reasons why Rails is still relevant in the year 2017, including institutional knowledge and market saturation. Rails is highly opinionated, and in 2017, the framework’s purpose is in question.
This is not a feature-for-feature comparison. It is not a pitch for functional programming. These are a few explanations of why Phoenix is a good alternative to the status quo, and one big reason why the framework can’t beat Rails yet.
Orthogonality
I’ve spent a small amount of time on Phoenix, but I’m impressed by how much it reads like Ruby without the cruft (think in? vs. include?). The basis of this success lies in Elixir’s pattern matching, piping, and chaining functions. Simply put, Phoenix is a framework composed completely of modules and functions. It tries hard to provide best practices, but it leaves the programming to you. For example, the release notes of Phoenix 1.3 state that code generators exist for learning. Developers are left to create a more complete solution.
Compilation and Speed
One of the biggest gripes I have with Ruby on Rails is that it’s a dynamic language. Some common test cases exist in Rails applications to confirm method existence. Runtime errors become compile time errors in Elixir. Compilation is parallelized in Elixir, so recompiling Phoenix is not a burden.
Phoenix Channels outperforms Rails Action Cable in speed and performance. In comparison, Rails also suffers from memory leaks. I have worked on a project in the past where memory leaks have appeared in production on Rails. Mitigating those risks as a framework feature is a welcome change.
Library Support
Now to the part of Phoenix that isn’t great: application library support. In a recent project, this issue prevented us from choosing Phoenix. Two libraries found with Rails are not up-to-date with Phoenix: Devise and Active Admin. Both Devise and Active Admin have Phoenix analogies, Coherence and Talon, but neither is maintained to the latest version of Phoenix.
This is no fault of the library’s owner, but it only shows how far Phoenix has to go to gain ubiquity. Maintaining an open-source library is hard, and keeping up-to-date dependencies on a part-time project is harder. Rails’ ubiquity for applications is still a large driver of its community support.
Takeaway
Phoenix is a great library with a strong roadmap ahead. At ElixirConf 2017, Chris McCord stated that the roadmap for Phoenix 1.4 is to focus on monitoring and metrics, key features that will help strengthen the framework’s credibility for larger institutions and projects.
The important takeaway to remember in terms of Phoenix Framework itself is that it is not Rails, so searching for direct analogies may not lead to direct yes-no answers. However, in deciding which framework to use on a client project, the choice is mutually exclusive. Rails exists now as a framework with commonality and saturation of tools and libraries. Without those requirements, there is a world elsewhere to explore cutting-edge frameworks like Phoenix.
While Phoenix isn’t as library-rich as Rails right now, a quick search will return all of the exciting projects it’s been successful on already. If third-party library support isn’t a necessity, then consider greenfielding with Phoenix. In short, I hope to see more support internally at my workplace and externally in the community going forward.