Image for post
Image for post

5 reasons you should use Phoenix instead of Rails in your next project

Elvio Vicosa
Nov 23, 2017 · 5 min read

Whenever I started a new project in the past, Rails was my standard tool to go with. Having been using it for almost a decade, it was the perfect tool to get something done, in the most efficient and productive way.

I have to confess that for many times I tried to use something different. I played with Erlang, go and node.js, but none of them gave me the “developer happiness” experience I was used to get from Rails.

When I started building Statictastic (a SaaS application for static site hosting, publishing and content management for teams), I used Phoenix to build its MVP and compared how Rails development speed.

Sticking to Rails meant I was compromising performance, since most of the technologies I mentioned above performed better than Rails; that wasn’t a problem at all, the “developer happiness” was more important than performance for me.

Two years ago I stumbled upon Phoenix, a web framework written in Elixir. I was able to develop a web application in a similar way I was used to develop using Rails, but with a “tiny” difference: Phoenix was fast, way faster than Rails.

After having used it in a few projects, where some of them were complete migrations of Rails projects to Phoenix, it quickly became my default tool to build web applications, putting Rails in the second position.

This post is about the 5 reasons that made me switch and why you should consider using Phoenix instead of Rails in your next project.

1. Common concepts

  • The directory structure
  • The naming conventions
  • The database migrations
  • The use of dependencies
  • The ActiveRecord features
  • The ERb templates
  • The form helpers
  • The built-in support for testing

Those things are directly connected to the “developer happiness” effect that Rails has in developers. Why should you consider using another framework that doesn’t offer the things that you are used?

Well, the good news is that Phoenix not only provides the features to all those topics, but it also makes it simple to Rails developers to understand. Let’s compare some of the features:


get '/books', to: 'books#index'
get '/books/:id', to: 'books#show'


get "/books", BookController, :index
get "/books/:id", BookController, :show


class CreateBooks < ActiveRecord::Migration[5.0]
def change
create_table :books do |t|
t.string :title
t.text :description
t.decimal :price
t.string :image_url


defmodule Storex.Repo.Migrations.CreateStoreBooks do
use Ecto.Migration
def change do
create table(:store_books) do
add :title, :string
add :description, :text
add :price, :decimal
add :image_url, :string


<section class="book-list">
<ul class="grid">
<% @books.each do |book| do %>
<li class="grid-item">
<div class="book book-small">
<h2 class="book__title"><%= book.title %></h2>
<span class="book__price"><%= book.price %></span>
<% end %>


<section class="book-list">
<ul class="grid">
<%= for book <- @books do %>
<li class="grid-item">
<div class="book book-small">
<h2 class="book__title"><%= book.title %></h2>
<span class="book__price"><%= book.price %></span>
<% end %>

2. Simplicity

...pipeline :browser do
plug :accepts, ["html"]
plug :fetch_session
plug :fetch_flash
plug :protect_from_forgery
plug :put_secure_browser_headers

Although Phoenix generated that code by default, a developer can still understand what happens when a request is performed and where to perform changes to influence the way a request is handled.

The fine balance between clarity and abstraction is present in every component of Phoenix and you will find yourself browsing the framework code to learn more about its features, as also a point of inspiration.

3. Productivity

Phoenix go further on providing developers two types of productivity:

Short term

Long term

4. Fast, really fast!

[info] GET /
[debug] Processing with StorexWeb.PageController.index/2
Parameters: %{}
Pipelines: [:browser]
[info] Sent 200 in 191µs

Yes, that’s correct, you are seeing µs response times.

You can also see the journey that enabled Phoenix to run 2 million clients in a single server:

Pretty neat, hun?

5. Scalable

Phoenix applications are able to adapt themselves to changes in load and available resources. Even under heavy load, a Phoenix application is able to accept and handle more incoming requests, even if that means increasing the response times in order to keep accepting traffic. The same applies to running your Phoenix application in different types of machines (e.g. one with a single core and other with 40 cores), where the Erlang VM makes sure to map the concurrency of your application to the machine parallelism, so that you don’t have to tweak it manually.

Those things are only possible because Phoenix runs on top of the Erlang VM.

Free e-mail course: Migrating from Ruby to Elixir

I created a free e-mail course that covers the following topics:

  • Is Elixir the right choice?
  • How to get the development team up to speed
  • How to start your first Elixir project
  • How to reduce migration risks and delivering a successful project
  • How to get management onboard and promote Elixir inside the company

Visit to get instant access to it.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch

Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore

Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store