![]() 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. That's where the world is heading and where Phoenix aims to excel. 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. Phoenix is also deviating on a the traditional "web framework" notion. 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. We are also taking a more explicit approach (thanks to FP). 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. To be clear, I'm not a Rails contributor, but I have done Ruby/Rails professionally for 6 years or so. > 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.) If you see my work on Sync, a gem for realtime rails partials, I explored things around these ideas. ![]() 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. We use their filesystem watching lib for our live-reload feature. I have no direct experience with n20, but some of our realtime goals overlap and they have done really great work. > Specifically, how would you compare Phoenix and N2O 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. So plugs released for framework X, phoenix, or "pure plug" usecases will just work across all codebases. This makes things less magical, simplifies the request lifecycle, but most importantly it allows easy interop with community libraries. So in Phoenix, Endpoints, Routers, and Controllers are Just Plugs. With Phoenix, Plug is core to the framework and we don't hide it like Rails does with Rack. One of my goals from the start was to rally around Plug ( ), which is our webserver abstraction and middleware lib (somewhat like Rack from Ruby, or Ring from Clojure). I'd be interested in your perspective on the current state of the elixir web framework scene and where you think it's going.
0 Comments
Leave a Reply. |