I make a living providing consulting, training and writing books for Ruby on Rails and Phoenix (hint: please send an email to [email protected] if you want to hire me). 50% of the time I’m hired as a firefighter to fix an existing project. In the other 50% I’m hired to help creating a web application on a green field. In those cases many clients ask if they should use Rails or Phoenix for their new project. I live in both worlds and would like to share some light into this not trivial decision.
Phoenix is not just a faster Rails written in Elixir
Most developers assume that Phoenix is a re-implimenation of Rails in the functional programming language Elixir. Make no mistake! It is not. It’s creator Chris McCord originally did recycle a couple of Rails ideas but just the ones he liked. For many technical problems the Phoenix community came up with different solutions. Many times with better ones.
What’s the Deal with the BEAM?
Ruby is an object-oriented programming language. It is an interpreted language which was created by Yukihiro Matsumoto who had productivity and fun in mind when inventing it. Elixir on the other hand is a functional programming language (created by José Valim) which runs on Erlang virtual machine (BEAM). It is compiled into bytecode for the BEAM. The BEAM runs as a single operating system process but is kind of a world in itself.
The BEAM runs 24x7 on the server. A Ruby (on Rails) process only runs when the web server starts it to answer a request. So if you for example want to do something every hour you have to use cronjob to trigger it on a Rails system. On a Phoenix system this will be taken care of by a little Elixir program in the BEAM.
From a Phoenix perspective the Rails approach ActionCable (https://medium.com/rubyinside/action-cable-hello-world-with-rails-5-1-efc475b0208b) to push messages from the server to the client is laughable slow, error prone and doesn’t scale well. It needs a redis server to tackle the problem. In a Phoenix project this all gets done by the BEAM.
In case you are running a really big web application the BEAM has one really interesting trick up it’s sleeve: It scales super easy over many servers. Scaling is not a source of headaches for Phoenix projects. Talking about scaling and speed: Did I mention that the WhatsApp server run on the BEAM too?
Functional vs. Object-Oriented
Sometimes Elixir looks a little bit like Ruby. In my opinion this is misleading because Ruby is object-oriented and Elixir is functional. Totally different worlds! If you are a seasoned Ruby developer it will take you some time to get the feeling for Elixir.
But as I felt in love with Ruby many years ago I felt in love with Elixir too. The worst part of my job is switching between those too worlds. Each of them makes totally sense in itself and is just beautiful. But you don’t want to code Ruby AND Elixir. Pick one and stick with it!
ActiveRecord vs. Ecto
ActiveRecord is the tool of choice in the Rails world to work with the database. Ecto is the tool of choice for that in the Phoenix world. Both offer validation but are otherwise very different. ActiveRecord feels like a Ruby object. If you know Ruby it feels just right to use it. You have to think very little about it and you don’t need to understand SQL at all to use it. Using Ecto on the other hand requires a basic understanding of SQL. Ecto is a little bit rougher on the edges.
In my opinion ActiveRecord is the secret sauce of Rails. Rails is fun because of ActiveRecord. I don’t see that close relationship between Ecto and Phoenix. Ecto is great but Phoenix would still be great without Ecto. Rails wouldn’t be without ActiveRecord.
gems vs. packages
A gem is a piece of 3rd party software which can be easily integrated into your Rails project. Most Rails developer have a set of gems they like to use with all their projects (e.g. acts_as_list or devise). gems are like salt and pepper for a cook. Have a look at https://www.ruby-toolbox.com to get a feeling of the huge size of the gem ecosystem.
Gems are a quick way to integrate functionality. The main problem with gems are software upgrades. Assuming you have a Rails 4.2 application and want to upgrade to Rails 5.1. Than you have to make sure that the gems you are using still work on Rails 5.1. The more gems you use the higher is the chance that you’ll run into a problem. Often a maintainer loses interest into his/her creation or doesn’t cover your specific case. I have seen endless client projects with exactly that problem. Everything came to a standstill because 2 years ago a gem was included which is not maintained any more.
Today I often prefer to write a functionality myself than to use a gem. But that is a narrow line to walk on.
In Elixir land those 3rd party software pieces are called packages. The package ecosystem is by fare not that big as the gem ecosystem. Have a look at https://elixir.libhunt.com/categories to get an idea. Because of the way Phoenix and Ecto work packages are more future proof than gems. But you’ll have to ask me again in a couple of years about this.
Speed
That one can be answered quick and painless: Phoenix is fast. Must faster than Rails.
But to be honest: That kind of speed is very rarely needed. I build the business network https://www.vutuv.de with Phoenix because of this but most projects don’t have the need for this extrem speed. Most times it is good enough to just add one more server or add some caching.
Development Speed
It takes about the same amount of time to write a web application in Phoenix and Rails. There is no development speed advantage in any of them.
Of course you’ll experience a deceleration when you switch from Rails to Phoenix the first time. As you would the other way around.
Stability
It took me a long time to believe/understand it but the BEAM is super stable. Erlang is more than 20 years old and the developers of Erlang go to great pains to ensure that it stays stable.
Ruby is not unstable. But I’ve had problems during upgrades from one Ruby version to the other (see the gem problem). I’ve never experienced an upgrade problem with Elixir.
Zero Downtime and Hot Deployment
For most web applications a short downtime during software upgrades is not a problem at all. Most companies throw too much money at this problem when a downtime of 1–2 minutes wouldn’t harm them at all. But sometimes there are cases where you really need a zero downtime deployment.
Zero downtime can be quite a challenge with Rails. It is easy as pie with Phoenix. The BEAM has build in functionality for this. You can hot replace code. For me that was a dream come true.
Full disclosure: When an upgrade involves a database migration a zero downtime gets more complex for both worlds.
David vs. Chris
Most open-source software projects are run by more or less big core teams. So is Ruby on Rails and Phoenix Framework. But not everybody is equal in those core teams. The founders always have super powers. They keep defining the direction and they are important for public visility.
DHH (David Heinemeier Hansson) created Rails and has been given talks about it ever since. He is a natural show man. In my opinion he got a little bit lazy in the last 2–3 years. His RailsConf keynotes used to be eye opener experiences. I haven’t felt that in his last two keynotes.
David has a talent to create visibility. He is not just a software guy but also a race car driver and a photographer. But his ability to create visibility for a software project or a book (he wrote a couple of non software books too) is hard to match.
David has the aura of being arrogant. But I understand that. The Rails community is way bigger than the Phoenix one. There is no way David can chat with everybody at a RailsConf as Chris can do at an ElixirConf.
Not that money is a great indicator of success but David became a double digit millionaire with his company Basecamp which runs a Ruby on Rails stack.
Chris McCord created Phoenix and has been given talks about it ever since too. Chris came from the Rails community but couldn’t solve a couple of problems with Rails. So he used Elixir to (re-)invent a better wheel. You can feel that he is currently more involved in Phoenix than David is with Rails. At conferences Chris is kinder to newbies. He is more down to earth than David.
Chris works at DockYard.
BTW: Brian Cardarella (CEO) built an impressive Phoenix team at DockYard.
Visibility
Rails is a lot more visible than Phoenix. There are more books about Rails (shameless plug: my new Rails 5.1 book), more screencasts (it all started with the famous “Blog in 15 minutes” screencast) and more trainings.
My favourite indicator? Does Peter Cooper run a news letter about a specific topic? He does on Ruby (http://rubyweekly.com) but not on Elixir (yet?).
But you are reading this post. So you’ve heard of both projects. That speaks volumens about visibility of Rails and Phoenix.
The Main Problem of Both Frameworks
All of my clients have a hard time to find good developers. For Phoenix and for Rails. Phoenix might be even a little bit harder.
And that is a big problem. What good is a perfect framework when you don’t find good developers?! You probably get better results with top notch PHP developers who use PHP than with mediocre Ruby developers who use Rails.
Is Rails or Phoenix better for you?
In my opinion Phoenix offers a slightly better technology but I also think that this is not key for a successful project. Important is the number of available developers and how good they know their framework. So when you start on a green field you have to ask yourself “Will it be easier for me to find good Rails or good Phoenix people?”. Most times it will be easier to find Rails people.
If you are knee deep into an existing Rails project take extra caution before moving to Phoenix. The grass is always greener on the other side. I’ve seen very successful switches but many times those were made by rock stars.
If you have a team of talented Rails developers who like to learn new stuff then my advise is to start a side project with Phoenix. See how it works out before you make the decision to move your bread and butter project.
In the rare case that speed and/or zero downtime is a showstopper for your project than you’ll have to pick Phoenix.
Important: None of them is a bad choice!
Shameless Plug
Please send an email to [email protected] if you need Rails or Phoenix consulting or training. And please follow my Twitter feed at https://twitter.com/wintermeyer
Hacker Noon is how hackers start their afternoons. We’re a part of the @AMIfamily. We are now accepting submissions and happy to discuss advertising & sponsorship opportunities.
To learn more, read our about page, like/message us on Facebook, or simply, tweet/DM @HackerNoon.
If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!