# learn-phoenix-framework
**Repository Path**: pond-frog/learn-phoenix-framework
## Basic Information
- **Project Name**: learn-phoenix-framework
- **Description**: :fire: Phoenix is the web framework without compromise on speed, reliability or maintainability! Don't settle for less. :rocket:
- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: main
- **Homepage**: None
- **GVP Project**: No
## Statistics
- **Stars**: 0
- **Forks**: 1
- **Created**: 2025-06-30
- **Last Updated**: 2025-06-30
## Categories & Tags
**Categories**: Uncategorized
**Tags**: None
## README
# Learn Phoenix (Web App) Framework
Learn how to use Phoenix Framework to
**have _fun_ building _real-time_ web/mobile apps**
that are ***fast*** for "_end-users_", ***reliable***,
***scalable***, ***maintainable*** _and_ (_easily_) ***extensible***!
## _Why_?
As web/mobile app developers we _need_ to _leverage_
the work that other (_really smart_) people have done
instead of constantly building things "_from scratch_" all the time;
that is _why_ we use _frameworks_ to build our apps!
> See: "**Top 10 Reasons Why Phoenix**" (_further down this page!_)
There are _many_ frameworks to choose from
(_a **few** "popular" ones are mentioned **below**
in the "**Questions**" section_).
But if we go by what is "_popular_" we would
still be riding horses (_and carts_) everywhere
and no _progress_ would be made.
> **Note**: **all** the reasons "***Why***"
for ***Elixir*** _also apply_ to ***Phoenix***!
check them out: https://github.com/dwyl/learn-elixir#why
## _What_?
A web application framework ***without compromise***!
### Developer Joy
The biggest "_constraint_" in any technology project is _people_.
An "Entrepreneur"/"Founder" or "Product Owner" can have all the _good ideas_
in the world, if they are _unable_ to convert idea into _reality_,
it's _meaningless_.
### (Should I _Care_ About) Benchmarks?
_Obviously_, you should run your _own_ benchmarks on your own hardware/cloud
and make _informed_ decisions based on the _requirements_ of your app/product,
but ... when we _read_ the stats for how many ***concurrent users***
a Phoenix App can handle (_with live WebSocket connections_)
we were _blown_ away!
It means we can build our real-time app(s) with 90% fewer resources.
#### Performance Highlights
+ ***considerably lower latency*** and request response time than _anything_ else! (_thanks to Erlang's lightweight processes and ultra-efficient network/message handling_)
+ ***4x*** more requests-per-second than the
equivalent Node.js (_Express.js_) App.
+ ***9x*** more throughput than a Python 2.7 based app. (_blocking really sucks!_)
+ ***10x - 100x*** more requests handled than Ruby-on-Rails
(_depending on the type of app!_)
+ _Similar_ performance to **Go** on a _single server_,
but a _much_ simpler multi-server concurrency model,
so ***horizontal scaling*** across multiple data centers
("availability zones") is _much easier_! (_Erlang manages the resources
for multiple servers/processors as a single app "fleet"
and delegates requests/processing to them across clusters/zones_!)
All of this means that you spend _considerably_ less money
on Hardware/Cloud infrastructure so your app/company
can gain a ***competitive advantage*** on **cost**.
>If you are in the _fortunate_ position to be _considering_ using
something _way better_ for your _next_ project,
look no further than Phoenix!
> Read more: http://www.phoenixframework.org
## _Who_?
_Many_ people/teams/companies are _already_
using Erlang/Elixir and Phoenix and seeing phenomenal results!
Including: Adobe, BBC, Spotify, Pinterest, Discord (Gamer Chat App),
Groupon (Fave), Lonely Planet, Brightcove, Slack ...
See: https://github.com/doomspork/elixir-companies
### Who _Should_ Learn Phoenix?
+ People who want an _easy_ way of
building an app with all the modern conveniences of "generators",
built-in Database interface ("ORM") and ***Firstclass WebSockets***
for "real-time" while getting **_legendary_ reliability**.
+ Teams who need the developer productivity or Ruby-on-Rails or Django,
but want less "magic" (_i.e. want to **understand** how everything works!_).
+ Companies who want to spend 90% less on both developer
and infrastructure costs
so you can serve more people with fewer resources.
### Who Should _NOT_ Learn Phoenix?
+ Anyone who needs to use the "_most popular_" framework or language
(_for whatever reason_).
+ Companies who already have lots of legacy Java/PHP/etc.
and cannot invest the time to learn/use something new.
+ Developers who want "_job security_" bug-fixing unreliable code.
## _How_?
### Assumptions / Pre-Requisites?
#### Elixir
You _cannot_ build a Phoenix App without knowing Elixir.
If you are new to Elixir, "star" (_bookmark_) `this` repo
(_so you can return to it tomorrow_)
and then go to:
[github.com/dwyl/**learn-elixir**](https://github.com/dwyl/learn-elixir)
learn elixir until you feel like you understand the syntax,
then come back and learn Phoenix!
_Specifically_ you should focus on learning the Elixir "Basics":
+ types of data
+ atoms
+ pattern matching
+ maps
+ function definitions
+ modules
#### Node.js
Phoenix uses Node.js to compile
assets like JavaScript and CSS files (_using_ [Webpack](https://webpack.js.org/)).
Simply ensure you have Node.js _installed_. https://nodejs.org
You don't need to know Node to use Phoenix.
### Installation
If you've already learned some Elixir and installed Node.js, then
the first step to getting started with Phoenix is installation!
The Phoenix documentation is amazing, so we recommend following
[the official phoenix installation instructions!](https://hexdocs.pm/phoenix/installation.html)
You'll also need to install PostgreSQL, there is a tutorial of how to do so
linked in the Phoenix installation guide linked above, but you can also check
out our [`learn-postgresql`](https://github.com/dwyl/learn-postgresql) repo
for instructions, and raise an issue if you have any trouble!
While a _basic_ understanding of JavaScript _can_ be useful at times,
you don't _need_ to _know_ how to use Node to use Phoenix.
> If you're curious _why_ they chose Brunch.io over "_alternatives_",
the short answer is: Simplicity & Speed!
see: http://brunch.io/docs/why-brunch
> **Note**: Phoenix v1.4 (_unreleased at the time of writing_)
uses WebPack for asset compilation,
see: [CHANGELOG.md](https://github.com/phoenixframework/phoenix/blob/0bdb5b001915e437c2d2cf1b77a1c532ce45cde2/CHANGELOG.md#phxnew-installer)
### _Next_?
_Familiarize_ yourself with the "Up and Running" (_official_) guide:
https://hexdocs.pm/phoenix/up_and_running.html#content
### _Practical_ Examples?
Once you have phoenix installed
and followed the _official_ "up and running" guide,
come back and try these **_beginner-friendly_ examples**:
+ **Counter** (_realtime shared counter using Phoenix LiveView_):
[https://github.com/dwyl/**phoenix-liveview-counter-tutorial**](https://github.com/dwyl/phoenix-liveview-counter-tutorial)
+ **Todo List** (_step-by-step tutorial showing how to build a fully functional TodoMVC clone_):
[https://github.com/dwyl/**phoenix-todo-list-tutorial**](https://github.com/dwyl/phoenix-todo-list-tutorial)
+ **Chat** (_realtime UI/UX using WebSockets_):
[https://github.com/dwyl/**phoenix-chat-example**](https://github.com/dwyl/phoenix-chat-example)
+ **Encryption** (_security_):
[https://github.com/dwyl/**phoenix-ecto-encryption-example**](https://github.com/dwyl/phoenix-ecto-encryption-example)
+ **Append-only Log** (_how to store your App's data_):
[https://github.com/dwyl/**phoenix-ecto-append-only-log-example**](https://github.com/dwyl/phoenix-ecto-append-only-log-example)
### Book?
We _recommend_ that people ***buy*** (_or borrow_)
[@chrismccord](https://github.com/chrismccord)'s book:
"Programming Phoenix"
see: https://pragprog.com/book/phoenix14/programming-phoenix-1-4
[](https://pragprog.com/book/phoenix14/programming-phoenix-1-4)
The authors are _individually **impressive**_ and _collectively_
they _comprehenisively_ cover Phoenix like nobody else _can_!
Chris _created_ Phoenix, José created Elixir
and Bruce is ultra-experienced technical author
with _many_ successful books to his name!
(_i.e: the book is the obvious choice for how to learn Phoenix!_)
### Video Intro by José Valim (_Creator of Elixir_)
[](https://youtu.be/MD3P7Qan3pw "Click to watch!")
https://youtu.be/MD3P7Qan3pw
[](https://youtu.be/srtMWzyqdp8 "Click to watch!")
https://youtu.be/srtMWzyqdp8
## Resources
+ Elixir vs Ruby Showdown - Phoenix vs Rails: https://littlelines.com/blog/2014/07/08/elixir-vs-ruby-showdown-phoenix-vs-rails
+ Benchmark: https://github.com/mroth/phoenix-showdown
# _Our Top 10_ Reasons _Why_ Phoenix
> "_**Phoenix** provides the **productivity** of Ruby-on-Rails
with the **concurrency** and **fault-tolerance** of **Erlang**_."
0. Beyond all the (_fantastic_) technical benefits,
what attracts _us_ to Phoenix is the ***Great Community***
of people around the world who are _excited_ about making Phoenix
an _amazing_ tool for building web apps!
Having [_welcomming_ people](https://github.com/phoenixframework/phoenix/issues/1624) who will
+ help you when you get stuck, patiently explaining things
+ answer questions (_both
["**noob**"](https://elixirforum.com/t/defimpl-phoenix-param-to-override-to-param-causes-functionclauseerror-no-function-clause-matching-in-phoenix-param-rumbl-video-to-param-1/3987)
and "**advanced**"_) and
+ ***openly discuss*** (_your_) _**ideas** for **improvements**_.
see: https://elixirforum.com/t/phoenix-v1-3-0-rc-0-released/3947
1. Phoenix uses the **Elixir** programming language which means your
app is compiled and run on the ***Erlang Virtual Machine*** "BEAM".
Erlang is a battle-tested highly fault-tolerant VM used by
_many_ telecommunications companies
2. **WebSockets** ("_channels_") are ***built-in*** to the framework
which means building apps with "real-time" communication and interaction
is _much_ easier than virtually _any_ other framework/platform!
(_no third-party `magic` module needed! **everything you need** is
already there ready for you to serve **millions** of people!!_)
see: http://www.phoenixframework.org/docs/channels
3. **Easy _asyncrhonisity_** because all programming
in Phoenix (_Elixir_) is ***Functional***!
This means it's _really_ simple to abstract useful functionality
like request authentication, logging and processing into "_piplines_"
that are easily ***human-readable***! (_no third-party `async` module required! no "promises", "generators" or "observables" to managed!!_)
4. ***Security & Resilience Mindset*** is the `default`.
**Encryption** (SSL) is ***easy*** in Phoenix/Elixir and
both ***mitigation*** of **SQL injection**,
***Cross-site Scripting*** (**XSS**)
and ***CSRF protection*** are **built-in** (_enabled by `default`_) so
it's virtually impossible for a "_novice_" programmer
to introduce this type of security bug.
5. ***Concise Code*** cannot be _understated_! We can write _way fewer_
lines than in the _equivalent_ Node.js/Java/Rails/Go app, this means
developers are more _productive_ and there is ***less code to maintain***!
5. ***Testability*** due to functional programming of all controllers!
6. **Easy Deployment**: https://hexdocs.pm/phoenix/heroku.html
7. ***Zero-downtime Deployment*** is ***free***! (_again because of Erlang_). Erlang manages transitioning "_live/active_" users from the old to new version of your app without them even _noticing_ that it was upgraded/updated!!
8. ***Built-in Monitoring/Managment*** of your app through Erlang supervisors
mean that you know _exactly_ how your app is performing, what parts have
crashed/restarted and why! This is a feature we _pay_ (_a lot_) for in other frameworks and here it's ***free***!!
Can _you_ think of _another_ reason
_why_ using Phoenix is ***awesome***?!
***Please Share your thoughts*** in this thread:
https://github.com/dwyl/learn-phoenix-framework/issues/13
# _Questions_?
### Do I _need_ to learn Elixir `before` trying/using Phoenix?
***Yes***. See: https://github.com/dwyl/learn-elixir
### Do I Need to _know_ Erlang to use Elixir & Phoenix...?
***No***. You can start learning/using Elixir _today_ and
call Erlang functions when required,
but you ***don't need*** to know Erlang
`before` you can use Phoenix!
### But Phoenix is _not_ "_Mainstream_" ... Should I/we _use_ it...?
There are _many_ web application frameworks you/we can choose from:
https://en.wikipedia.org/wiki/Comparison_of_web_frameworks
So _why_ would _anyone_ select a framework written in a programming language
that is not "_mainstream_"...?
### Why are we not using Hapi.js _anymore_...?
This is _missinformation_. We _are_ still using Hapi.js
for a _number_ of projects where it is _appropriate_.
This includes _several_ client projects and internal dwyl apps/tools.
We _decided_ to use Phoenix for our _new_ projects for these simple reasons:
+ Elixir is a _nicer_ language than JavaScript.
`#LessIsMore` `#LessButBetter` `#SmallIsBeautiful` `#SyntaxMatters`
+ JS _can_ be functional, whereas Elixir ***is*** (_always_) Functional!
The _distinction_ makes all the difference!
With "functional" programming,
the programs are a ***lot*** easier to think about
while you are writing/maintaining them!
+ Elixir uses the Erlang VM which is _way_ more efficient/powerful than "V8"
+ The Erlang VM scales _much easier_ to multi-core multi-server multi-data-center
than Node.js
(_or pretty much anything else for that matter!!_)
> _For our new projects we **need multi-data-center fault-tolerance**!
we get that "**for free**" by using **Erlang -> Elixir -> Phoenix**_!!
In our _opinion_ Hapi.js is still "_the best_" Node.js framework and
we will `continue` to use and _recommend_ it
to people that need _simple_ apps that scale and are easy to maintain.
see: https://github.com/dwyl/learn-hapi
Also we still use JavaScript for all our AWS Lambda Micro-Services,
that is not going to change.
They are simple, efficient and
scale really well!
see: https://github.com/dwyl/learn-aws-lambda
### What's "Wrong" with using Rails or Django?
The _original_ "_productive_" web frameworks
were "Ruby-on-Rails" and "Django" (_python_) back in 2005!
(We _used_ both of these for periods in our "_journey_" and
can speak on the _advantages_ of each of them!)
> There is "_nothing wrong_" with using Rails or Django.
> We think there are still plenty of use-cases for both frameworks.
> We just _know_ that it's (_a lot_) _easier_ to build "real-time"
> with Phoenix because "Channels" (_WebSockets_) are baked in,
> and the Elixir/Erlang concurrency is a whole different ballgame!
> Erlang (and thus Phoenix) can handle
***millions*** of _concurrent users_ on a single server,
> whereas a Rails/Django server can only handle a few thousand (_at best_!)
> if your app is only serving a few thousand people at once, then you're fine!!
We ***love*** the fact that Erlang uses "_lighweight long-lived_" processes,
which means we can connect _millions_ of (_IoT_) devices ...
For IoT Erlang is (_unquestionably_) the Answer!
For simpler web apps where you only expect a few users per day,
Rails/Django are still viable.
But **why _compromise_** if you **don't _have_ to**?
If you can have a [***Tesla***](http://www.cnbc.com/2015/08/27/teslas-p85d-is-the-best-car-consumer-reports-has-ever-tested.html) for the "price" of a Ford Focus,
why _wouldn't_ you?!?
Why _settle_ for _good_ when you can _easily_ have/use the ***best***?
### But GitHub Still Uses Rails ... Surely GitHub is "_Scalable_"?
***Yes***, GitHub is still using Rails for their Web App/Site.
But ask _any_ of the _core_ team at GitHub if (_given the chance to start over_)
they would _chose_ Rails
to build GitHub in 2017, and see how many of them say "_yes, of course_"
(_with a straight face..._)!
Also, GitHub does a _lot_ of things to Scale Rails in the background.
And _many_ of their _newer_ (_client-side_) features are written in JavaScript!
see: https://github.com/github
> Bottom line is: _anything_ can be _made_ to scale using "DevOps",
> but ***Phoenix*** is _made_ to **scale** by `default`
> because Erlang (was) _invented_ (to) scale!
### Why _NOT_ Use Go?
> "_There are two kinds of programming languages - those that nobody uses and those that everybody's bitching about_" ~ Bjarne Stroustrup
(_creator of_ [`C++`](https://www.youtube.com/watch?v=JBjjnqG0BP8))
Go is _very_ popular. Largely due to the fact that Google "_sponsors_" it.
It was meant to simplify (_replace_) `C++` and Java inside Google ...
and for the most part, it has succeeded!
We _really_ like Go. It was our "number two" choice when deciding
what programming language
(_after Elixir_) in our "post JS stack"...
The ***decision*** to _use_ `elixir` instead of _anything_ `else` was ***easy***:
+ Elixir is functional (_much simpler to read/write/maintain/extend_)
+ Elixir functions compose in a really elegant way as "plugs"/"***pipelines***"
+ Data is immutable which makes application state predictable (_no guessing_!)
+ Types are dynamic and inferred (_no need to manually declare them_)
but there are rules which simplify things and the compiler checks them
giving an appropriate warning.
+ Erlang makes distributed apps ***much easier*** and our _plan_ is to build
IoT systems that will mean connecting _many_ (*millions*) devices
with persistent connections, Erlang was ***made for this***!
+ Phoenix includes _many_ useful things out-of-the box including _several_
security features most people won't even think of.
Further Reading:
+ Why Go is Not Good: http://yager.io/programming/go.html
+ Go Web Frameworks: https://medium.com/code-zen/why-i-don-t-use-go-web-frameworks-1087e1facfa4
+ Why Everyone Hates Go: https://npf.io/2014/10/why-everyone-hates-go/
(_click-bait title, some valid points..._)
+ Discussion: https://www.reddit.com/r/elixir/comments/3c8yfz/how_does_go_compare_to_elixir
(`help wanted` expanding this answer...)
### Why _NOT_ Use Scala + `Play` Framework _instead_...?
If you are already used to writing Java or deploying to the JVM,
the Play Framework is a _superb_ choice: https://www.playframework.com
Scala is a _good_ programming language and everyone should learn it!
https://www.scala-lang.org/what-is-scala.html
> We have used Play a few times (_before we adopted Node.js_)
and _really_ liked it!
But Scala is a "kitchen sink" (_multi-paradigm_)
programming language that allows people to use "_all of Java_" ...
We think Scala's "Java Interoperability" means it's "too easy" to allow
***complexity*** into your codebase. Specifically ["OOP Mutation"](http://docs.scala-lang.org/overviews/collections/overview.html) ...
So why _aren't_ we (DWYL) using "Play" for _new_ projects any more?
Firstly, we transitioned to Hapi.js (_Node.js_) a _few_ years ago
because it was more "***lightweight***" and allowed us to write _tiny_ programs
that used only a few Megs of RAM
(_where our Play apps were very resource-hungry..!
have you ever tried running a Scala app
on a "basic" laptop like a Chromebook...?_)
Summary of "reasons" for Phoenix instead of Play:
+ We maintain that Play/Scala still has plenty of valid use-cases.
+ Elixir is _way_ simpler than Scala.
+ The Erlang VM is _way_ better at ***concurrency*** than the JVM.
+ We ***love*** the fact that all data is immutable in Elixir.
+ We ***love*** how few resources it takes to run a Phoenix app
(_e.g on a Raspberry Pi!!_)
> _We just think that for **our** project(s) ***Erlang's Concurrency model***
**works better** and **Functional code** transforming **Immutable data**
is **easier** to test and maintain_.
If you have _evidence_ that "_Scala is Simpler_"
we would _love_ to hear from you!
Tell us: https://github.com/dwyl/learn-phoenix-web-development/issues
### Why not use Haskell?
If you like ***Functional Programming*** (**FP**) so much, why not use Haskell?
#### _Please_ ask more questions: https://github.com/dwyl/learn-phoenix-framework/issues