The best of Rails in Phoenix (part 1)

SeriesPhoenix on Rails clock3 min read

There are many parts of Phoenix that will make you, the long-time Rails developer, smile and feel right at home.

Code organization

You can count on consistent code organization in Phoenix projects as much as with Rails. The structure is also centered around the MVC, but it fits your web apps into the realm of Erlang and OTP. Here's how directories from Rails map to ones in Phoenix:

app/assets/javascripts -> web/static/js
app/assets/stylesheets -> web/static/css
app/controllers        -> web/controllers
app/models             -> web/models
app/views              -> web/views, web/templates
config                 -> config
config/locales         -> priv/gettext
db                     -> priv/repo
lib                    -> lib
public                 -> web/static/assets
test                   -> test
vendor                 -> web/static/vendor

As you can see, the directories are structured differently than with Rails, but the important part is that the conventions are there.


You get to work with familiar URL helpers like users_path. This, just like in Rails, allows to pass records as arguments and to change paths in router without having to refactor the whole app.

Also, you can define RESTful routes using the familiar resources helper.


After starting a new Phoenix project, you end up with a complete, configurable setup for dev, test and prod environments. This may seem obvious for Rails developers, but for instance in Node, there's no single convention and boilerplate around this and it's up to developer to assemble and configure each stack.

Environments integrate back to the package manager. This means each project dependency, just like gems in your good old Gemfile, can be included only for specific environment(s) instead of all. This optimizes the production runtime.

Asset management

There's an out-of-the-box solution for asset management and production building in both frameworks. Here, however, the similarities end because Phoenix hands the job over to an existing library (Brunch), while Rails keep on trying on their own with the (in)famous Asset Pipeline.

As I'm focusing more on similarities than feature comparisons in this article, I'll stop here for now. The bottom line is that both frameworks will feed your browser with unminified, live-rebuilt assets during development and they both will build you a production-ready minified, fingerprinted and concatenated bundles.

Update: Here's the follow-up comparison article: Rails asset pipeline vs Phoenix and Brunch.

Running tasks

Mix is Elixir's own task running system, and from Rails developer's perspective it's like bundle, rake and rails joined together. That's because, besides allowing to define and run project-wide tasks, Mix covers some commands that Rails include in its own binary. And it handles dependency management. Here's how some common Rails commands map to Phoenix:

bundle install           -> mix deps.get
bundle update            -> mix deps.update
rails generate migration -> mix ecto.gen.migration
rails generate model     -> mix phoenix.gen.model
rails generate scaffold  -> mix phoenix.gen.html
rake db:create           -> mix ecto.create
rake db:migrate          -> mix ecto.migrate
rake assets:precompile   -> mix phoenix.digest (+ brunch build)

Update: Here's the follow-up comparison article: Phoenix vs Rails: Mix and Rake tasks.


Unless you expect Elixir itself to be a Ruby clone or subset, rest assured that Phoenix borrows a lot of the best from Rails and you will feel right at home after making the first contact with it.

Read part 2 »