Three Things I’m Liking about Phoenix

A colleague recently got me excited about Elixir and the Phoenix web framework. Now I’m not building telephone networks anytime soon, but I’m always intrigued by a new web framework to see on which fronts they’re pushing the envelope. I’ve worked a lot with Rails over the past few years and did some Django before that. I may even have touched a Java web app a long time ago, but that is best talked about in whispers. Phoenix is a great chance to explore what a web framework is today.

1. Changesets

How about that, the first thing isn’t even in Phoenix itself, but in Ecto, the default database library. It does a bunch of things different to ActiveRecord (some due to the fact that Elixir is just a different beast than Rails), but by far the coolest in my opinion is changesets. Let’s look at an example:

@required_fields ~w(title author release_date isbn)
@optional_fields ~w(description)
def create(model, params \\ :empty) do
model
|> cast(params, @required_fields, @optional_fields)
|> slugify_field(:title, :slug)
end

The create function here returns a changeset. The cool thing is that we do not validate the model, we validate the changeset instead. This allows us to check for required fields and whitelist other fields right where it matters. And something like creating a slug, which we might only want to do on create, can be added to this changeset. The changeset for updating might be completely different.

The advantage of this is that we’re not modifying the model we have before we have checked the changes. Of course immutability is a big thing in Elixir, so doing that wouldn’t even make sense. But this might be a good idea in other languages as well. You could view the changes you’re making to a model as a completely separate entity and process, before giving it to the database to actually change your data.

2. Views

You may be thinking: Rails has views. But let’s be honest, Rails has templates which it calls view because then it can be an MVC framework. But now that the pressures of pretending to be MVC for the sake of the acronym have waned, it’s time to call them what they really are.

Phoenix has separated Views from Templates. Templates are html documents with some code in them. Views are modules which are responsible for rendering the Template. That makes it an awesome place for view-logic. Rails provides helpers for this, which ended up somewhere globally, and that’s a stink if there ever was one.

Views in Phoenix mean you can write Elixir functions that you can cleanly call from your template. This keeps your template clean from code and other templates don’t need to worry about helpers that magically appear there.

3. JavaScript asset pipeline

Sprockets is kind of cool. And it was a big thing that attracted me to Rails from Django, where nothing was built into the framework. But there are so many JavaScript build tools now and they are all tied more closely to the npm/bower ecosystems (why there are two ecosystems is a whole other thing). Rather than trying to integrate JavaScript into Elixir, Phoenix ships with Brunch to manage assets, but you can swap it out for your favourite buildtool.

I have to admit I wasn’t familiar with Brunch to begin with, but it seems to work fine. It builds modern JavaScript out of the box and allows me to use CSS preprocessors. I really like that Phoenix focusses on what it does best: be an Elixir web framework. But I also really like that there are modern tools for static assets available out of the box. Having cake? Eating cake? Both? Count me in!


The server-side web framework gets little time in the spotlight with all the front-end frameworks flying around these days. But it’s good to see that there’s still innovation happening. Not all good ideas have already been found and there’s improvement happening every day. And I haven’t even touched on all of the other cool things Phoenix is doing. It’s still an awesome time to work on the server side of things.