I'd be interested in your perspective on the current state of the elixir web framework scene and where you think it's going.
Specifically, how would you compare Phoenix and N2O?
Would you say the perception is correct that Phoenix is going very much into the direction of Ruby on Rails? (Generators, you and Jose are rails contributors, etc.)
I'm torn. On one hand Phoenix has the momentum, but on the other, I feel like it's making a lot of assumptions that don't hold in my situation. (EG: I'm doing routing at runtime because the routes change, I don't store anything on the local drive, so no static data there, I'm doing an unusual way of composition to produce what's sent to the browser. I haven't run into any blockers to using phoenix just feel like I'm fighting it sometimes.)
Yeah, sorry, vague question. :-)
> I'd be interested in your perspective on the current state of the elixir web framework scene and where you think it's going.
One of my goals from the start was to rally around Plug (https://github.com/elixir-lang/plug), which is our webserver abstraction and middleware lib (somewhat like Rack from Ruby, or Ring from Clojure). With Phoenix, Plug is core to the framework and we don't hide it like Rails does with Rack. So in Phoenix, Endpoints, Routers, and Controllers are Just Plugs. This makes things less magical, simplifies the request lifecycle, but most importantly it allows easy interop with community libraries. So plugs released for framework X, phoenix, or "pure plug" usecases will just work across all codebases. So the for "elixir web framework scene" I see a vibrant community around not only Phoenix, but Plug in general and other libs built on top of it.
> Specifically, how would you compare Phoenix and N2O
I have no direct experience with n20, but some of our realtime goals overlap and they have done really great work. We use their filesystem watching lib for our live-reload feature. We don't go to the level of writing html abstractions not the server to push updates over, but it's a really neat idea that I would like to explore doing over Phoenix channels after 1.0 is out. If you see my work on Sync, a gem for realtime rails partials, I explored things around these ideas.
> Would you say the perception is correct that Phoenix is going very much into the direction of Ruby on Rails? (Generators, you and Jose are rails contributors, etc.)
To be clear, I'm not a Rails contributor, but I have done Ruby/Rails professionally for 6 years or so. It depends what you mean by "direction". Rails set the bar for productivity and onboarding out of the box, so we aim to go this direction in spririt, but we aren't out to match feature to feature. We are also taking a more explicit approach (thanks to FP). I would say our goals for bootstrapping productive apps quickly with fast iteration is where we match Rails, but we are ready to take on the world out of the gate perf wise. Phoenix is also deviating on a the traditional "web framework" notion. Browsers aren't going anywhere, but we should have a framework that can hold persistent connection and broker messages across connected devices; many coming over browsers, but iOS, Andoid, et al as well. That's where the world is heading and where Phoenix aims to excel. So we should be great at the standard server rendered html, form builders, etc, but we're trying to take it to the next level with channels.
> ... I haven't run into any blockers to using phoenix just feel like I'm fighting it sometimes.)
I can't help if we don't have specific code examples. I always tell people we aim for the common 80% usecase that we all share. Special use-cases will always require deviations from any framework. Since our http stack is "just plugs" you should be able to easily get the best of both worlds with your needs while still using phoenix. Find me on IRC with some gists and we can see about making it work well :)
I am definitely not working on the %80 use case you're targeting, in fact, the best explanation of what I'm doing is I'm competing with you. I agree with you on the choice of elixir, and I agree with you about the direction of connected devices but we have some philosophical differences in solution. (One could say you're coming from the web world, and I am coming from the native world.)
But I will work on breaking out my solutions, as much as possible, into plugs so that people using phoenix can use them.... and if I end up pulling in some N2O I'll probably wrap it as a plug.
And since phoenix is based on plugs and lets you build a pipeline, this may be pretty convenient.
Thanks again for your work, contributions to making Elixir the Next Big Thing and your answers above!
wrt fast changeds, Elixir has been 1.0 stable for 7 months, and Phoenix is targeting a July 1.0 release. We are quite close to 1.0 as it is, so things should be much smoother now if you checked us out several months ago.
I was trying to search for API authentication.
How easy is it? And what protocol do phoenix have in place for authentication? Thanks.
Are you planning to have a vagrant box for Pheonix?
Laravel have this, named Homestead. I thought it was pretty easy and awesome.
I can not find anything about advanced security features in the docs (not only because the search on the site is broken).