Chapter 1
Introducing Phoenix

The web has gone real time. The days of clicking links to load full pages are over. Websites are as interactive as desktop applications these days, if not more so. Servers manipulate widgets on a page with small data exchanges. Pages ship form data up piece by piece as it becomes available instead of waiting for one massive update. Today’s web developers need a framework designed from the ground up around a real-time architecture, and Phoenix is that framework.

Ironically, most of the individual pieces from Phoenix can also be found in other places. You’ll find metaprogramming capabilities that remind you of Lisp and domain-specific languages (DSLs) that remind you at times of Ruby. Our method of composing services with a series of functional transformations is reminiscent of Clojure’s Ring. We achieved high throughput and reliability by climbing onto the shoulders of Erlang. Similarly, some of the groundbreaking features like channels and reactive-friendly APIs combine the best features of some of the best JavaScript frameworks but Phoenix makes it work at scale. This precise cocktail of features, where each feature multiplies the impact of the next, can’t be found elsewhere and that’s what makes Phoenix stand out. Phoenix just feels right.

After using (and writing about) frameworks spanning a half dozen languages across a couple of decades, we think the precise bundle of goodness that we’ll share is powerful enough for the most serious problems you throw at it, beautiful enough to be maintainable for years to come, and—most important—fun to code. Give us a couple of pages and you’ll find that the framework represents a great philosophy, one that leverages the reliability and grace of Elixir. You’ll have a front-row seat to understand how we made the decisions that define Phoenix and how best to use them to your advantage.

Simply put, Phoenix is about productive, concurrent, beautiful, interactive, and reliable applications. Let’s break each of these claims down.