The best of Rails in Phoenix (part 1)
There are many parts of Phoenix that will make you, the long-time Rails developer, smile and feel right at home.
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:
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
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.
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.
Mix is Elixir's own task running system, and from Rails developer's perspective it's like
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.