Phoenix creator here. I would be happy to answer any questions. For those that want an overview of the framework, my ElixirConf talk would be a good start:
http://www.confreaks.com/videos/4132-elixirconf2014-rise-of-...
(I say this as a fan, btw! I just think that it's important to get the pros and cons out there. I also think that a lot of Ruby/Rails folks are VERY curious about Elixir generally and Phoenix specifically, lately...)
Pro - Concurrency: I really love Ruby/Rails, but what led me to Elixir in the first place was constantly dealing with lack of concurrency in Rails and being unable to do anything like websockets in a sane way. For example, in Rails we can't really block in the controller without killing throughput, so we go to great lengths to background everything. This makes simple problems like "Make a remote API request through a controller" way harder since we now have to throw it in a worker queue, then poll from the client on the status of the job, then finally return the result. In Elixir/Phoenix, we can block in controllers without a blip on throughput, do our work, and return the response.
Pro - Error Handling / Fault tolerance I won't go into too much details here, but the Erlang/OTP way of building applications around Supervisors and responding to failures has really blown me away. Erlangers have been sitting on this innovation for the last couple decades so it's battle tested and has proven its merits. Look at WhatsApp, 1-2 million connections per server, 400 million users ~ 30 engineers.
Pro - "Realtime" / pubsub: Phoenix also ships with a realtime layer that we call "Channels" for doing pubsub/realtime events to clients. Our goal is to make building realtime applications as straight forward as building REST endpoints. We include a `phoenix.js` browser client, but we are targeting multiplatorm support and have a working Swift client internally. So Phoenix aims to go beyond a typical "Web Framework". The Web is more than just html apps (but Phoenix excels as just that). Imagine a iOS game publishing on Phoenix channels to other iOS clients, and a Web front-end reporting world events, player lists, etc. Phoenix can power all of it. By virtue of the Erlang VM, we also get cluster support For Free. You can run multiple phoenix nodes on a cluster and PubSub Just Works. No need for redis in b/w or worrying about sticky sessions. Concurrency in Elixir is location transparent. A process is a process regardless of machine it runs on in a cluster.
Cons - Packages, Training: My goals are to wholesale replace all my Rails work with Phoenix, but obviously we have a ways to go. The main cons are lack of off-the-shelf community packages like in Rails land. We are also not yet at 1.0, so you have to be willing to put up with breaking changes until we're ready to brand a 1.0 release next year. I'm using it for prod systems, but this is an upfront reality as we march towards 1.0. Other cons would be having to train folks new to Elixir, which often means learning a number of new paradigms at the same time. There's a helpful Elixir community for newcomers, but it will take more upfront work to get up to speed if you're coming from an OO background.
Hope that helps. Ruby folks might find my RailsConf Elixir workshop helpful as a place to get started in Elixir: http://www.confreaks.com/videos/3488-railsconf-workshop-all-...
freenode #elixir-lang irc is also a great resource for questions.
I created a distributed PubSub for the Scala/Akka/Play toolchain a while ago so just wondering how it compares: https://github.com/alexanderjarvis/dubsub
I worked with the new Node.js framework called Koa.js. It has an interesting way of dealing with middlewares (would be Plug in Elixir world, I assume). Request and response are passed through the middleware chain downstream, and each of them can take the response from previous middleware(s), modify it if needed, and pass to the next.
Either the response reaches the last middleware, or one of middlewares returns immediately, the response goes back "upstream" through the middlewares again. Then it is replied to the client.
During the flow, each middleware can also yield to the next one, so that it can handle the updated response when it goes upstream.
Imagine the cache middleware. Request comes in, this middleware checks if there is a cache of that request. If not, it yields to the next middlewares that will retrieve and transform the data, then cache the response body before returning to client.
For me, this flow offers a lot of flexibility in request and response handling. Is there anything similar to Phoenix?
From what I understand, once a Plug chooses to reply, the response ends at that Plug.
> From what I understand, once a Plug chooses to reply, the response ends at that Plug.
In Phoenix, we halt the connection when you use most of our functions that send a response, because there is little you can do afterwards. The Plug response API itself never halts when a response is sent.
Secondly, I hope that the original dev team sticks around too. The Erlang web framework - ChicagoBoss - has had its development slowed down ever since Evan Miller stepped down.
The reason though is that Elixir 1.0.2 includes some bug fixes that affects Phoenix in development.
Is some form of hypermedia supported or built in? If not, is it planned?
These may be answered in the presentation. I hope to watch it soon.
Like Scala being on the JVM.
Web Framework is just that a web framework.
From what the creator have commented on, it seems like it will be influenced by Ruby on Rails framework.